segunda-feira, fevereiro 25, 2008

Google Web Toolkit Applications - Livro sobre aplicações Ajax e RIA usando GWT

Google Web Toolkit (GWT) é um framework Java que facilita a construção de aplicações AJAX no modelo RIA (Rich Internet Applications). Codificar em JavaScript para múltiplos browsers, com o intuito de conseguir efeitos AJAX, é extremamente complexo e pouco produtivo. O GWT elimina muitos desses problemas de uma maneira extremamente poderosa: ele permite que o programador Java escreva código utilizando uma API similar ao Swing (API de criação de interfaces gráficas desktop) e depois use um compilador especial para converter essas classes Java em HTML e JavaScript adaptado aos principais browsers de mercado.

Diferentemente de outras opções RIA como o Silverlight da Microsoft e o Flex da Adobe, o produto gerado pelo GWT não precisa de plugins ou componentes especiais para executar nos browsers.

O livro em questão, Google Web Toolkit Applications de Ryan Dewsbury, assume conhecimento de Java. Conhecimento básico das APIs Swing, AWT ou SWT (para criação de interfaces gráficas desktop) com certeza agiliza a absorção do conteúdo do livro e da API do GWT.

O livro aborda os seguintes assuntos:

Parte I: Entendendo GWT

1. Primeiros passos com o Google Web Toolkit.
2. Visão Geral da Biblioteca de Interface do Usuário
3. Técnicas de Integração com Servidor
4. Engenharia de Software para Ajax.
5. Usando o kit efetivamente.

Parte II: Aplicações RIA exemplificadas - Essa parte apresenta aplicações reais desenvolvidas pelo autor e que demonstram diversas abordagens diferentes para a programação GWT.

6. Gadget Desktop Application.
7. Multi-search application.
8. Blog Editor Application.
9. Instant Messenger Application.
10.Database Editor Application - A que eu achei mais interessante. Cria um gerenciador de banco de dados pela Web. A aplicação inclui idéias de como ler e gerenciar estruturas de dados complexas acessando o servidor usando Data Access Objects, geração de código XML e JSON e integração com PHP, Ruby on Rails e Java com Hibernate.

Recomendo fortemente o livro para quem tiver necessidade de usar essa tecnologia na prática. Também acho interessante para todos aqueles que desejam explorar o mundo das Rich Internet Applications!

Marcadores:

quinta-feira, fevereiro 14, 2008

Planejamento ágil - reuniões para definição de releases e iterações

Na lista de discussões scrum-brasil surgiram algumas dúvidas relativas a aspectos do processo de planejamento de releases (versões) e sprints (ou iterações).

Dúvidas:

1 - Na reunião de planejamento de um release, se o time não se sentir confortável com suas estimativas em pontos, o time pode já quebrar as estórias em tarefas - e estimar essas tarefas em horas ?

2 - Na reunião de planejamento de sprints ou iterações, é necessário que todas as tarefas sejam atribuídas a algum membro já na ? Ou podemos apenas atribuir um conjunto inicial pequeno de tarefas e depois a medida que as tarefas forem sendo encerradas, o membro escolhe qualquer tarefa que ainda não tenha "dono"?

Minhas respostas (lembrando que essas dicas valem para os principais processos ágeis como Scrum, Extreme Programming, Crystal Clear e OpenUP):

1 - A estimativa em pontos é feita no Release Planning. Se no Release Planning eles não se sentem confortáveis para estimar uma estória ou item isso pode significar que: 1 - a estória é muito grande; 2 - Há muitas dúvidas e pontos nebulosos.

2 - As tarefas (tasks) não precisam ser TODAS distribuídas nessa reunião. Elas precisam ser estimadas, mas não alocadas a desenvolvedores específicos. Usualmente os desenvolvedores selecionam uma ou, no máximo, duas tarefas para iniciar a iteração. Essa alocação de tarefas continua ocorrendo, usualmente nos daily stand-up meetings (reuniões diárias em pé). Lembrando que são os desenvolvedores que se alocam nas tarefas. Eles não são alocados por alguém de nível gerencial.

As tarefas não devem ser distribuídas pela equipe durante a reunião de planejamento do sprint por um simples motivo: fazendo isso você está achando que identificou todas as tarefas da iteração e isso não será nunca realidade. Novas tarefas aparecem. Tarefas existentes precisam se dividir em duas ou mais, etc. O modelo comando e controle não ocorrerá porque os próprios desenvolvedores escolherão quais tarefas farão durante os daily stand-up meetings e APENAS após terem completado uma tarefa anterior.

Para corroborar ainda mais minha afirmação cito o excelente e crucial livro "Agile Estimating and Planning" (recomendo a todos que estejam usando Scrum, XP, OpenUP ou outro processo ágil que contenha Release Planning e Iteration Plannings que leiam o livro. Diria até que é leitura obrigatória!!!) do Mike Cohn:

Subtítulo "Tasks are not allocated during iteration planning" na página 147 capítulo 14: "Enquanto se planeja a iteração, tarefas não são alocadas a indivíduos específicos. No início da iteração, pode parecer óbvio quem irá trabalhar em uma tarefa específica. Porém, baseado no progresso de todo o time no conjunto das tarefas, o que é óbvio no início pode não ser o que acontece durante a iteração. Indivíduos não escolhem as tarefas em que vão trabalhar até que a iteração inicie e geralmente só escolhem uma ou duas tarefas relacionadas por vez. Novas tarefas não são iniciadas até que as previamente selecionadas sejam completadas. Não há nada a ganhar e muito a perder ao alocar indivíduos a tarefas específicas durante o planejamento da iteração."

Marcadores: ,

terça-feira, fevereiro 12, 2008

Resenha do livro Head First Software Development da O'Reilly

O livro Head First Software Development, da O'Reilly, segue o mesmo padrão de conteúdo da série Head First: uso de imagens, análise de exemplos reais e simulados para ajudar no entendimento dos tópicos considerados, utilização de exercícios como: palavras cruzadas, preenchimento de lacunas, sessões de perguntas e respostas. Tudo com o intuito de reforçar conceitos estudados em um capítulo.

O livro possui uma meta ousada: Ensinar melhores práticas, técnicas e princípios para um ótimo processo de desenvolvimento de software e mostrar como é o ciclo de vida do desenvolvimento de software.

Os autores optaram claramente por demonstrar neste livro uma abordagem ágil para o desenvolvimento de software. O grande diferencial do livro é seu aspecto lúdico e divertido, o que facilita a leitura.

A seguir o conteúdo de cada capítulo:

1. Great Software Development
2. Gathering Requirements
3. Project Planning
4. User Stories and Tasks
5. Good-enough Design
6. Version Control
7. Testing and Continuous Integration
8. Test-Driven Development
9. Ending an Iteration
10. The Next Iteration
11. Bugs
12. The Real World
Appendix A. Leftovers
Section A.1. #1. UML class diagrams
Section A.2. #2. Sequence diagrams
Section A.3. #3. User stories and use cases
Section A.4. #4. System tests vs. unit tests
Section A.5. #5. Refactoring
Appendix B. techniques and principles
Section B.1. Development Techniques
Section B.2. Development Principles

É interessante notar que também existe um bom tratamento sobre as ferramentas básicas para a montagem de um bom ambiente colaborativo de desenvolvimento nos capítulos 6 e 7. No capítulo 5 encontramos uma breve exploração de conceitos relacionados a design (projeto) e refactoring de software.

Eu, particularmente, já conhecia todas as técnicas mostradas por eles e que são tratadas em diversos outros livros sobre processos ágeis. Recomendo fortemente para pessoas que querem conhecer mais sobre desenvolvimento ágil (e ainda possuem muitas dúvidas) e também para profissionais experientes que desejam ler um livro com uma abordagem mais interessante e diferenciada.

O livro também é muito recomendável para uso em disciplinas de Engenharia de Software, Processos de Desenvolvimento de Software e em treinamentos de métodos ágeis. Seus fortes aspectos didáticos auxiliam no entendimento de todos os tópicos abordados, seus relacionamentos e sua importância para o desenvolvimento de softwares.

Marcadores: ,

sexta-feira, fevereiro 08, 2008

Otimização para sites de busca (SEO) - Erros arquiteturais

Conforme prometido no artigo , vou comentar sobre erros arquiteturais comuns que podem afetar uma estratégia de Search Engine Optimization (Otimização para sites de busca) eficaz.

Os mais importantes erros cometidos (especialmente e com frequência por web designers):

- Criar sites inteiros em Flash ou outra tecnologia RIA (Rich Internet Application).

- Criar a página Home em Flash.

- Criar páginas com o texto sendo uma figura (sim, isso existe!) ao invés de HTML, pdf ou um doc.

- Criar um menu de navegação de páginas do site em Flash ou apenas com JavaScript ou apenas usando figuras como botões.

Os pontos acima são os mais básicos, pois o seu site ou muitas páginas dele podem simplesmente não constar do google devido aos pontos acima relatados. O Google e outras ferramentas de busca indexam HTML. Elas não indexam (ainda não... pelo menos!) aplicações RIA como Flash, Flex, Silverlight, Google Web Toolkit, etc ou menus dinâmicos escritos apenas em JavaScript ou com figuras e botões ao invés de links. Nós, seres humanos, adoramos esse contexto visual e essas aplicações mais amigáveis. Porém e, infelizmente, os robôs de busca ainda não conseguem compreender esses formatos. Os spiders de busca amam mesmo é texto HTML!

Caro web designer ou desenvolvedor web: isso não significa que você não deve nunca mais usar Flash ou RIA na sua vida ou fazer algum efeito legal em JavaScript. Você deve apenas controlar com parcimônia seu uso. Crie a home page do site, seus menus e seu conteúdo escrito usando HTML e trate um Flash como uma aplicação interna ao site. Lembre-se: conteúdo escrito deve sempre e preferencialmente estar em formato HTML, para que possa ser lido perfeitamente pelos robôs de busca.

Outro erro arquitetural grave é o formato das URLs dinâmicas de um site. Esse é um erro causado especialmente pelos arquitetos e programadores web. URLs dinâmicas, dependendo de como são formadas, podem causar problemas para a leitura dos robôs de busca. Mesmo quando não trazem problemas elas reduzem as chances de um bom posicionamento na busca orgânica. Isso ocorre porque as máquinas de busca procuram as palavras-chave especialmente no título da página, na URL e no corpo do texto. Nesse artigo não vou falar sobre estratégias de como encontrar boas palavras-chave e como usá-las dentro de uma página de site (quem sabe outro dia!). O importante é que se saiba que a URL de uma página ajuda a dar mais relevância às palavras-chave. Uma boa URL também ajuda na leitura dos seres humanos que a estão acessando. Portanto há ótimos motivos para que a URL seja amigável!

Portanto, uma URL ruim pode fazer com que a página tenha um rank menor ou, pior ainda, nem seja listada no mecanismo de busca.

Exemplos de URLs ruins:

http://yourdomain.com/index.html&DID=18&CATID=13

http://yourdomain.com/buyAHome.do;jsessionid=07D3CCD

http://www.yourdomain.edu/racing/scores.php?prg=1

As três URLs acima são ruins pois não especificam do que exatamente se trata a página e ainda podem gerar problemas de acesso aos robôs.

Note agora como são URLs bem formuladas:

http://josepaulopapo.blogspot.com/2008/01/introducao-openup.html

http://josepaulopapo.blogspot.com/2008/01/bibliografia-marketing-otimizacao-sites.html

http://www.amazon.com/Enterprise-Scrum-Ken-Schwaber/dp/0735623376

Nas duas primeiras URLs (do meu site. É claro que eu uso técnicas de SEO!!!) é possível verificar que o primeiro artigo trata de uma introdução ao OpenUP e o segundo é uma bibliografia sobre otimização de sites. Ambos são de janeiro de 2008 (2008/01). No terceiro link vemos como a Amazon também usa de forma correta as URLs: a URL contém as palavras-chave do livro (que se chama "The Enterprise and Scrum"), bem como o ISBN (caso o usuário faça uma busca pelo ISBN no google também achará logo nos primeiros resultados a página da Amazon).

Não vou citar nomes (e nem URLs!), mas procure os principais sites brasileiros de vendas de livros e outros produtos aqui do Brasil e vocês notarão que eles ainda não possuem URLs boas (provavelmente devido a um problema arquitetural no desenvolvimento e falta de conhecimento de técnicas de otimização para sites de busca).

Falamos então de alguns erros básicos e principais (há mais! mas não os tratamos nesse artigo) na construção de sites e que podem torná-lo praticamente invisível nos sites de busca como Yahoo, Google, etc. Mais uma vez recomendo que clientes peçam claramente que seus sites sejam Search Engine Friendlies - isto é amigáveis a sites de busca - se acharem necessário e que os analistas de requisitos perguntem isso claramente a seus clientes (trate como um requisito não funcional do site).

Se sua empresa (ou a empresa contratada para construir seu site) não conhece as técnicas de SEO, contrate um especialista para ajudá-lo. Nada pior do que não conseguir um marketing de busca orgânico bom (e ainda por cima gratuito!!!) devido a erros arquiteturais de construção do site e por não saber como as máquinas de busca indexam as páginas!

Marcadores: , ,


Veja as Estatísticas