Teste

PRODUTIVIDADE WEB 2
Como ser produtivo desenvolvendo para web

Para fazer o download completo, visite:
http://visie.com.br/treinamento/pdf 1

Produtividade Web 2.0
por Elcio Ferreira

Visie
visie.com.br


INTRODUÇÃO
A Visie sente-se honrada em recebê-lo. Esse PDF, como você vai
perceber, fala de coisas muito mais profundas do o simples uso de uma
ferramenta. Vamos falar sobre atitude e cultura. Nosso objetivo é que
você, ao terminar de ler, tenha a clara idéia de para onde ir e em que
investir para ter um time de desenvolvedores web muito produtivos.

Dúvidas, sugestões ou reclamações a respeito desse material podem
ser enviadas diretamente para pdfprodutividade@visie.com.br.

Bom estudo!


Índice
Introdução................................................................................................2
Web 2.0.......................................................................... ...................................5
A tal Web 2.0.............................................................................................................5
O conteúdo é o rei....................................................................................................7
Inteligência coletiva...................................................................................................7
A web como plataforma............................................................................................8
O fim do ciclo de releases de software.....................................................................8
Experiência do usuário rica.......................................................................................9
Produtividade............................................................................................................9
Padrões Web........................................................................... ........................11
O que são os padrões web.....................................................................................11
Padrões e Produtividade.........................................................................................12
Montagem rápida do layout....................................................................................12
Desenvolvimento simplificado................................................................................13
Independência entre layout e conteúdo.................................................................15
Manutenção Simplificadíssima.................................................................................17
Padrões Reaproveitáveis.........................................................................................19
Microformats...........................................................................................................20
Visão geral da programação pragmática.......................................... ..............21
Programadores que pensam sobre seu trabalho....................................................21
Canivete suíço de conhecimento............................................................................21
Responsabilidade.....................................................................................................22
O poder do plain text..............................................................................................23
Comunicação...........................................................................................................23
Consertando as janelas............................................................................................24
Lidando com a mudança.........................................................................................25
Editor de código e shell...........................................................................................26
Programação Pragmática 1: DRY e ortogonalidade......................................28
DRY, o princípio fundamental..................................................................................28
Ortogonalidade.......................................................................................................29


Combinando DRY e ortogonalidade.......................................................................30
Programação Pragmática 2: Projeto e Construção com Protótipos e Tracer
Code............................................................................... .................................32
Tracer Code............................................................................................................32
Desenvolvimento de resultados..............................................................................32
A diferença entre Tracer Code e Protótipos..........................................................33
Protótipos Post-it....................................................................................................34
Programação Pragmática 3: TDD e Version Control.................................... .36
O primeiro fantasma: conserta aqui, quebra lá.......................................................36
TDD e testes unitários............................................................................................37
testes unitários na prática........................................................................................38
O segundo fantasma: onde está seu código fonte?.................................................45
Controle de versão.................................................................................................45
Automatização.........................................................................................................54
Javascript, Ajax e JSON................................................................................... 56
A melhor experiência..............................................................................................56
Javascript do jeito certo..........................................................................................57
O tal do Ajax...........................................................................................................59
Quem inventou isso?................................................................................59
Agora é diferente......................................................................................60
A simplicidade dos padrões web..............................................................60
Javascript, DOM e XMLHttpRequest.....................................................60
Acessibilidade..........................................................................................60
Nomes são importantes............................................................................61
Um exemplo muito simples....................................................................................62
JSON, o magnífico...................................................................................................63
Para onde agora?............................................................................................. 65


Web 2.0
Este material foi planejado para guiá-lo rapidamente através das inovações no desenvolvimento
web que têm tornado os desenvolvedores da Web 2.0 tão produtivos.

Experiência do usuário rica
Lembra-se de como eram os webmails antes do Gmail? E dos sites de mapas antes do Google
Maps? Dos fotologs e assemelhados antes do Flickr?

As aplicações da Web 2.0 certamente podem ser chamadas de Rich Internet Applications.
Experiência rica não significa ver animações e ouvir sons. Experiência rica é oferecer o recurso
que for necessário para que seja mais fácil e rápido para o seu usuário completar a tarefa que lhe
interessa,

Esse recurso pode ser a interação Ajax, pode ser uma animação ou som, ou o conteúdo filtrado e
classificado pelos outros usuários, ou uma API que permita a criação de aplicações com seus
dados (mash-ups) ou, até mesmo, um layout simples, centrado na tarefa.

Produtividade
Todo mundo fala da Web 2.0. Certamente há muita coisa nova aqui, e muita coisa antiga feita de
um jeitinho melhor. Mas há também muito barulho, fumaça e exagero. E às vezes é difícil
separar uma coisa da outra. Mas alguns fatos são tão óbvios que é impossível negá-los ou
duvidar deles.

O Digg conseguiu meio milhão de usuários cadastrados em menos de dois anos. A primeira
versão do produto foi desenvolvida por quatro amigos em menos de dois meses.

A 37signals conta com hoje com uma equipe de oito pessoas. Eles iniciaram com cinco pessoas.
Criaram o Ruby-on-Rails, framework rápido de desenvolvimento em Ruby, extremamente
popular. Criararam o Ta-da List, o Writeboard, o Backpack, o Campfire e o Basecamp e têm mais
de 350 mil usuários cadastrados.


Pequenos estão assustando gigantes, e sendo comprados por eles, em todo o mundo. Times de
três ou quatro pessoas têm desenvolvido em dias ou semanas produtos que antes levariam
meses para serem feitos por grandes equipes.

A despeito das discussões sobre o valor real desses negócios, e se estamos vivendo uma janela de
oportunidade ou uma nova bolha, há um fato óbvio aqui: eles são muito produtivos.
Desenvolvem rápido, software de qualidade, e parecem não se prender em labirintos de
manutenção e atualização. Este PDF estudará um pouco sobre como o desenvolvimento pode ser
tão fácil e produtivo, e o que você pode fazer para ter uma equipe dessas.

Inteligência coletiva
Duas cabeças pensam melhor do que uma, diz o velho ditado. O que dizer então de milhares de
cabeças?

Milhares de voluntários, cada um contribuindo com o seu pouquinho, criaram o Linux.

Milhares tornaram a Wikipedia o que ela é. São milhares de usuários, cada um contribuindo
com seu pouquinho, que fizeram o del.icio.us, o Flickr, o Digg, o Orkut, o Slashdot e o Blogger.
Nenhum desses sites produz conteúdo próprio. O velho modelo do portal de informações, que
vende acesso ao conteúdo que contrata jornalistas para escrever, está em sérios apuros.

Cada novo usuário agrega valor. Cada vez que alguém adiciona uma url ao del.icio.us ou ao Digg,
está fazendo um voto, contribuindo com uma pequena unidade de informação. Cada vez que
alguém faz uma compra na Amazon, um post no Blogger ou um comentário no Slashdot, está
agregando valor. Não muito valor, é verdade. Mas milhares de usuários com suas pequenas
contribuições, multiplicadas uma pela outra, podem oferecer muito mais valor do que o dinheiro
pode comprar.

Programadores que pensam sobre seu trabalho
A primeira e mais importante característica de um programador pragmático é que ele pensa
sobre seu trabalho. Essa carcterística dá origem a todas as outras.

O programador pragmático é, antes de tudo, um inconformado e um otimista. Ele não consegue
repetir dezenas de vezes a mesma tarefa sem se perguntar se há uma maneira melhor. Ao
mesmo tempo, ele acredita que há maneiras melhores, e que ele pode desenvolver uma.

É por conta dessa postura que não se treinam programadores pragmáticos, se cultivam. Não se
ensina atitude num treinamento técnico de oito horas, isso depende de se criar uma cultura em
volta de seus objetivos.

Uma cultura de métrica de trabalho, de estudo e experimentação, de questionamento, otimismo
e entusiasmo. Uma cultura de paixão pelo desenvolvimento efetivo.


É um árduo trabalho, esse de criar uma cultura, e nós não podemos ensiná-lo a fazer isso. Você
vai ter que encontrar seu caminho. O que podemos dizer é que vale a pena.

Canivete suíço de conhecimento
O programador pragmático não se contenta em conhecer uma solução, uma linguagem e um
jeito de aprender a fazer as coisas.

Sua bagagem de conhecimentos é seu canivete suíco. Você consegue apertar parafusos,
descascar batatas e costurar sacos com um canivete de uma única lâmina, mas fará isso com
muito mais facilidade se seu canivete tiver uma costuradeira e uma chave de fendas. Cada
linguagem, ambiente e ferramenta de desenvolvimento que você aprende é uma nova lâmina em
seu canivete.

Aprenda uma nova linguagem e ambiente de programação por ano. Leia um livro técnico por
mês. E incentive os programadores de sua equipe a fazer o mesmo. Se você sempre trabalhou
com Linux, aprenda Windows Scripting Host, se sempre trabalhou com Windows, aprenda Shell
Script. Aprenda expressões regulares, sed e awk. Aprenda XPath e XSLT. Aprenda bem
Javascript, e SQL.

Há uma vantagem inusitada em conhecer linguagens de programação diferentes: você aumenta
seu repertório de soluções. Veja, por exemplo, que eu sempre usei um for em Javascript para
contar quantas vezes determinada string aparecia dentro de outra. Pode ser:

x="alfabeto animado anacleto acelerado"
alert(x.split("a").length-1)

Eu aprendi esse truque estudando Python. Embora seja uma idéia que possa ser usada em
qualquer linguagem, é muito comum ver programadores Python usando o recurso, enquanto eu
nunca tinha visto isso em outra linguagem.

Ao aprender uma linguagem nova, vocẽ entra em contato com o repertório de soluções
desenvolvido pela comunidade de programadores daquela linguagem, e isso o torna mais
produtivo em qualquer linguagem.


Programação Pragmática 2: Projeto e Construção
com Protótipos e Tracer Code
Vamos apresentar duas das ferramentas do programador pragmático que mudam radicalmente
a maneira de se desenvolver software: tracer code e protótipos. Tracer code é uma técnica que
responde racionalmente à tradicional pergunta "por onde eu começo?"

Tracer Code
Quando o programador pragmático vai começar o desenvolvimento de um sistema qualquer, no
momento de escrever código a primeira coisa que ele faz é escrever um conjunto completo de
código que atravesse todas as camadas do sistema. Assim, se ele está desenvolvendo código
MVC, ele não escreve todas as suas classes da camada Model para só depois partir para as
camadas Control e View. Antes, ele escreve um conjunto de classes, uma ou duas classes de cada
camada, que lhe permitam ter um fluxo de dados completo. Ele terá, depois desse pequeno ciclo,
uma ou duas telas, uma ou duas tabelas no banco de dados, e uma mini-aplicação que já grava
dados no banco e os exibe na tela. Isto tem algumas vantagens interessantes. A primeira delas, é
que ele pode saber se está acertando o alvo antes de disparar todos os seus cartuchos.

Como a artilharia militar sabe se está acertando o alvo em combates noturnos, quando não pode
ver a trajetória de suas balas? Eles intercalam em sua munição uma pequena quantidade de
tracer bullets, balas incadescentes, de poder de impacto muito menor, cuja função é iluminar a
trajetória. As tracer bullets tem o mesmo peso e formato das balas reais, de modo que o atirador
as usa para se guiar. Se as tracer bullets estão atingindo o alvo, então as outras balas também
estão. Tracer code é como tracer bullets, ele te mostra se você está atingindo o alvo.

Isto elimina o risco de que você desenvolva todo o seu código da camada Model para descobrir
em seguida que a versão do banco de dados que você está usando tem um bug quando exporta os
dados para sua linguagem, ou que escreva toda sua camada View, depois de já ter escrito as
outras duas, para descobrir que a plataforma em que está trabalhando não terá performance
suficiente para o sistema que você está desenvolvendo.


Javascript, Ajax e JSON
Está todo mundo falando sobre Javascript e Ajax por aí. Curiosamente, o Ajax se tornou popular
graças aos mesmos desenvolvedores que praticamente eliminaram o uso de javascript de seus
sites há seis ou sete anos, no início do movimento de padrões web. O que aconteceu? Qual a
diferença entre o desenvolvimento com Javascript hoje e há seis anos?

A resposta é: maturidade. Há seis anos atrás os padrões web estavam ainda engatinhando,
estávamos aprendendo os fundamentos da acessibilidade e começando a entender o impacto dos
padrões na produtividade.

Hoje já sabemos como funcionam os padrões, e como eles modificam nosso processo produtivo.
Já sabemos também um pouco mais sobre como trabalhar a acessibilidade e conhecemos melhor
o impacto do Javascript sobre esse processo todo.

Com esses anos de experiência, acabamos descobrindo algumas coisas muito interessantes,
como o fato de que o uso de HTML bem escrito simplifica muito o desenvolvimento de
Javascript e facilita a criação de scripts reutilizáveis e de que não dá muito trabalho escrever
Javascript de maneira a manter sua página acessível.

A melhor experiência
Há um princípio básico no desenvolvimento com padrões que tem grande impacto tanto na
acessibilidade quanto na produtividade. O desenvolvimento é feito em camadas, em cima do
HTML simples, de maneira a oferecer não a mesma experiência para todos os usuários, mas a
melhor experiência que for possível para o navegador e plataforma do usuário.

Assim, desenvolvimento pode ser feito na seguinte ordem:

1. HTML: você pode usar aqui XHTML ou HTML 4.01, à sua escolha. Bom HTML é
automaticamente acessível a celulares, leitores de tela e robôs de busca. Nesta etapa você já tem
um site funcional, embora bem feioso.

2. CSS: agora você deixa o site bonito. A fonte deixa de ser Times New Roman, os elementos


ocupam seu lugar, o layout é montado transformando aquele site, que já funcionava, num
produto que você tem orgulho de entregar. Para quem tem um leitor de tela ou um celular sem
suporte a CSS, essa etapa não faz diferença nenhuma. O site já estava pronto para eles na
primeira etapa.

3. Javascript: aqui você valida seus formulários antes de submetê-los. É bom lembrar que você
não deixa de validá-los no server-side, o que você já tinha feito no passo 1. Aqui você transforma
seu menu comum num menu dinâmico animado. Para quem, por qualquer motivo, não tiver
suporte a Javascript, esta etapa também não faz diferença nenhuma.

4. Ajax: mais Javascript. Agora você faz com que o formulário de busca não recarregue a tela. De
novo, o site já funcionava e vai continuar funcionando do mesmo jeito para quem não tem
suporte a Ajax.

JSON, o magnífico
Uma dica de programador agora: não use XML no Ajax. Embora pareça óbvio que Ajax precise
ser feito com XML, donde vem o X do nome Ajax, há algumas desvantagens em se usar Ajax com
XML. As duas principais desvantagens são o fato de que o XML é um formato relativamente
pesado para se transferir pela rede, e o fato de que interpretar XML no Javascript é uma tarefa
complicada e com um custo de processamento considerável.

No lugar de XML, use JSON. O formato JSON (JavaScript Object Notation) permite descrever
dados de maneira simples e flexível. Segue um trecho de dados em XMLRPC, um dos formatos
para troca de dados com XML mais populares:

<params>
<param>
<value>
<struct>
<member>
<name>nome</name>
<value><string>Antonio</string></value>
</member>
<member>
<name>sobrenome</name>
<value><string>Azevedo</string></value>
</member>
<member>
<name>email</name>
<value><string>aazevedo@cia.gov.br</string></value>
</member>
<member>


<name>idade</name>
<value><int>34</int></value>
</member>
<member>
<name>especial</name>
<value><boolean>1</boolean></value>
</member>
</struct>
</value>
</param>
</params>

Segue o mesmo conjunto de dados, em JSON:

{
nome: "Antonio",
sobrenome: "Azevedo",
email: "aazevedo@cia.gov.br",
idade: 34,
especial: true
}

Este trecho de código tem 109 bytes, contra 873 do equivalente XMLRPC. É mais fácil de
escrever, mais fácil de ler e mais rápido de transportar por uma conexão HTTP. Mas a principal
vantagem está no código Javascript. Ao invés de usar um pesado e complicado parser XML, que
não funciona em todos os navegadores, ou de fazer um lento e doloroso tratamento de string
para garantir a compatibilidade de seu código, usando JSON você pode converter seus dados
para dados nativos do Javascript com um único comando. Digamos que o retorno do Ajax esteja
na variável t, você pode convertê-la para um objeto contendo strings, números e booleans
nativos com:

t=eval(t)

Simples assim. E no site json.org há bibliotecas para ler e escrever JSON com uma linha de
código para Java, C#, Python, Ruby, PHP, C e uma série de outras linguagens. JSON é uma
daquelas ferramentas que podem tornar você mais rápido. Tornou para mim o desenvolvimento
de aplicações Ajax muitas vezes mais rápido, e muito mais divertido também.


Teste

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Teste

Teste