Durante o ando de 2010 diversos leitores me escreveram solicitando alguma forma de “receita de bolo” para a criação de projetos em Flex. Estavam buscando uma maneira de criar uma aplicação de forma que fosse mais correta e mais fácil, baseada em padrões de projeto e definida através de uma estrutura que facilitasse o desenvolvimento.

No início de 2011 comecei a pensar mais no assunto, pois irei implementar estas regras nos próximos livros, chegando a uma série de “regras” das quais estarei apresentando neste artigo. Inicialmente, queria dizer que eu não sou o dono da verdade, e estou longe de criar alguma regra que se não usada irá causar o seu insucesso. Estou disposto a receber críticas que sejam construtivas, com o intuito de melhorar o sistema cada vez mais, possibilitando assim que a comunidade tenha em mãos um bom documento para consulta.

PHP ou Java?

Uma das perguntas que mais recebi ao longo de 2010, por isso estarei discutindo um pouco sobre qual linguagem de servidor usar. Inicialmente você deve saber que não é a linguagem que vai fazer você ter sucesso ou não em um sistema, e sim o quanto você conhece a mesma. Por exemplo, se você conhece muito bem PHP, porque aventurar-se em Java se dá conta do recado? O mesmo vale para o Java, mas não recebi emails de nenhum programador Java querendo mudar para php… (sic.. hehe).

O que? é fato nesta “briguinha” é que, não existe melhor ou pior. Java é mais complexo que php, exige mais atenção mas traz muitos benefícios, até financeiros (sim você ganha mais). PHP é mais fácil, você cria tudo mais rápido e com isso fica mais feliz Qual você vai escolher? Escolha a que te faz mais feliz.

Zend_AMF ou AMFPHP ?

Outra dúvida muito comum entre os programadores PHP. Eu costumo selecionar um ou outro dependendo do projeto em sí. Se o seu projeto vai usar alguns recursos do Zend Framework, e são muitos, utilize o Zend_AMF. Caso contrário, use AMFPHP.? Aqui chegamos a um impasse do qual julgo ser mais importante do que a briga entre Zend e AMFPHP: você ainda pensa em criar um projeto sem o Zend Framework? Você irá criar tudo que precisa “na mão” ou vai usar componentes de terceiros? Falo isso porque se um projeto em PHP é iniciado, o uso do Zend Framework irá acelerar muito o processo do mesmo. Rotinas como enviar email, acessar a sessão do php, gerenciar usuários com ACL, persistência de dados, acesso ao twitter… são todos muito bem implementados com o Zend e o Zend Framework é mantido pela mesma empresa que mantém o PHP, então não existe biblioteca mais segura em termos de continuidade do que esta.

E quais tecnologias vamos usar nas “melhores práticas” ?

Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:

No cliente:

• Adobe Flash Burrito e Flex SDK 4.5 (Basta baixar e instalar o Flash Burrito: http://labs.adobe.com/technologies/flashbuilder_burrito/).
• SWIZ Framework (http://swizframework.org/)

No servidor:

• PHP
• Zend Framework (http://www.zend.com/community/downloads)
• WAMP Server (para rodar o PHP na própria máquina – http://www.wampserver.com/en/download.php)
• Netbeans ou Eclipse PDT – Eu estou gostando mais do Netbeans, então vou usá-lo.? (http://netbeans.org/downloads/index.html? – Versão PHP)

?

Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.

Estrutura de pastas e projetos

Outra dúvida comum dos usuários, é definir a estrutura de pastas do projeto. Como instalamos o WAMP Server, ele nos fornece uma pasta onde é possível ter acesso pelo nacegador, através do endereço “localhost”. Isto é, ao acessarmos http://localhost/ o WAMP Server cuida de apontar para o diretório c:wampwww (que é o que chamamos de “document root”). Para que possamos entender a estrutura do projeto, é necessário compreender uma particularidade do Flex. Diferentemente do PHP, os arquivos que estão dentro do projeto Flex não precisam ser enviados ao servidor (os arquivos mxml, as, etc). veja que o Flex compila todos os mxml/as do projeto e gera um único arquivo swf. Este arquivo sim DEVE estar no diretório web do projeto!

Vamos então criar o projeto “melhoresPraticas” da seguinte forma:

1. Crie a pasta c:wampwwwmelhoresPraticas Este é o diretório público do projeto, acessado através de http://localhost/melhoresPraticas?????????
2. Crie a pasta c:wampwwwmelhoresPraticasclasses Este é o diretório onde iremos criar as nossas classes PHP
3. Crie a pasta c:wampwwwmelhoresPraticasvos Este é o diretório onde as classes VOs serão criadas
4. Crie a pasta c:wampwwwmelhoresPraticasZend Aqui você copia/cola o Zend framework, de forma que o arquivo melhoresPraticasZendLoader.php esteja acessível
5. No Flash Builder, crie o projeto “melhoresPraticas”. Você pode deixar o DefaultLocation como está. Não clique em Finish, clique em Next, até chegar na configuração do “Compiled Flex application location”. Ou seja, aqui você irá informar para onde os aquivos compilados do flex irão ficar. Coloque o seguinte caminho: c:wampwwwmelhoresPraticasbin-debug. Não clique em Finish, clique em Next, e em Library Path, adicione a biblioteca swiz (o arquivo swc). Em “Output folder URL”, coloque: http://localhost/melhoresPraticas/bin-debug
6. Com o projeto pronto, clique no botão RUN. Deve então surgir uma página em branco no endereço: http://localhost/melhoresPraticas/bin-debug/melhoresPraticas.html
7. No Netbenas ou no eclipse, crie o projeto php apontando para c:wampwwwmelhoresPraticas

Testando a conexão

Com os projetos prontos, iremos inicialmente realizar uma simples conexão entre o Flex e o PHP. Isso é útil para que possamos começar com trabalho “pesado”. Para conectarmos o Flex no PHP, preciamos criar uma classe de conexão no Flex, que iremos chamar de ServiceBase, e um arquivo que recebe esta conexão no PHP, que chamaremos de gateway.php.

Para criar a classe ServiceBase, use o Flash Builder e acione o menu File > New > ActionScript Class e crie a classe de acordo com a imagem a seguir:

Classe ServiceBase:

package services
{
??? import mx.controls.Alert;
??? import mx.rpc.events.FaultEvent;
??? import mx.rpc.remoting.RemoteObject;
???
??? public dynamic class ServiceBase extends RemoteObject
??? {
??????? public function ServiceBase(classe:String)
??????? {
??????????? super(“zend”);
???????????
??????????? /*
???????????? * Como o arquivo swf está na pasta bin-debug,?
???????????? * precisamos subir um nível para chegarmos ao
???????????? * arquivo gateway.php
???????????? */
??????????? this.endpoint = “../gateway.php”;
???????????
??????????? this.source = classe;
??????????? this.addEventListener(FaultEvent.FAULT,OnFault);
??????? }
???????
??????? protected function OnFault(e:FaultEvent):void
??????? {
??????????? Alert.show(e.fault.faultString,”Erro” );
??????? }
??? }
}

Esta classe tem como principal objetivo estabelecer o endpoint, que é o gateway.php que ainda vamos criar. O atributo source define qual a classe que iremos acessar na pasta classes. Também adicionamos um listener genérico caso haja alguma falha na conexão. Veja que a classe é dinâmica (dynamic), ou seja, podemos chamar métodos da classe sem que eles estejam implementados na classe. Isso é útil pois os métodos chamados nesta classe serão os métodos remotos do PHP.

No servidor, temos que criar o arquivo gateway.php, com o seguinte código:

//Adiciona o autoloader do Zend Framework
// Assim todas as classes do framework
//? serão carregadas quando precisarem
require_once “Zend/Loader/Autoloader.php”;
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);

//Instancia o servidor Zend_AMF
$server = new Zend_Amf_Server();

//Habilita o modo de desenvolvimento, retornando
// mensagens de erro. Comente esta linha quando
//?? estiver em modo de produção
$server->setProduction(false);

//Adiciona este diretorio como um diretorio de
// classes que podem ser usadas pelo Flex
$server->addDirectory(dirname(__FILE__).”/classes”);
set_include_path(dirname(__FILE__).”/vos”);

//TODO: Adicionar VOs

//Dependendo da requisição do Flex, irá
// chamar a classe correspondente, respondendo
//?? em formato AMF o que a classe responder.
echo $server->handle();

//Não fechar a tag PHP, nunca !!

?

O arquivo gateway.php é o ponto de entrada para as classes em PHP. Veja que inicialmente fazemos um include do Autoloader.php para que todas as classes do Zend Framework sejam instanciadas sem a necessidade de realizar requeires. Criamos então a instância do Zend_AMF_Server, que irá cuidar para que o flex consiga conversar com o PHP via AMF. Adicionamos o diretório classes como um diretório do AMF, onde as classes serão expostas ao flex e usamos o set_include_path para adicionar as classes que estão na pasta “vos” no path global do php, para que não precisamos fazer include das mesmas. Depois adicionaremos mais código sobre as classes VOs.

Na pasta “classes”, criamos a classe Teste, e o método sayHelloWorld. O nome do arquivo tem que ser o mesmo nome da classe, ou seja, Teste.php.

class Teste {
??? public function sayHelloWorld($name)
??? {
??????? return “Hello World $name”;
??? }
}

//Não feche a tag PHP!

?

Agora voltaremos ao Flex para que ele possa acessar a classe teste. No arquivo melhoresPraticas.mxml, adicionamos o seguinte código:

?

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”955″ minHeight=”600″>
???
??????? ??????????? import mx.controls.Alert;
??????????? import mx.rpc.events.ResultEvent;
???????????
??????????? import org.swizframework.utils.services.ServiceHelper;
???????????
??????????? import services.ServiceBase;
??????? ]]>
???
???
???
??????? ???????????
??????????? var testeService:ServiceBase = new ServiceBase(“Teste”);
??????????? var serviceHelper:ServiceHelper = new ServiceHelper();
???????
??????? serviceHelper.executeServiceCall(
??????????? testeService.sayHelloWorld(“Daniel”),
??????????? function(e:ResultEvent):void{
??????????????? Alert.show(e.result.toString());
??????????? });
???????
??????? ]]>
???
???

?

Como estamos realizando um teste, fazemos o acesso ao PHP no evento creationComplete da aplicação. Criamos a variável testeService que é do tipo ServiceBase, repassando o parâmetro que é o nome da classe no PHP, ou seja, “Teste”. Também criamos a variável serviceHelper que pertence ao Swiz e é um facilitador de acessos ao PHP. Usamos no serviceHelper? o método executeServiceCall, que irá chamar remotamente o método sayHelloWorld repassando o parâmetro “Daniel” e quando concluído, executará a função que está no segundo parâmetro, realizando um Alert.

Ao executar esta aplicação, quando é carregada surgirá a mensagem de retorno do PHP:

?

Criando as classes em Service

Com o teste de conexão realizado, podemos avançar mais no código! A primeira refatoração que faremos é em relação as classes que estão na pasta service. Até agora criamos o seguinte código:

??? var testeService:ServiceBase = new ServiceBase(“Teste”);

Ao invés de criar a instância de ServiceBase repassando uma string que é o nome da classe, iremos criar a classe TesteService, da seguinte forma:

package services
{
??? public dynamic class TesteService extends ServiceBase
??? {
??????? public function TesteService()
??????? {
??????????? super(“Teste”);
??????? }
??? }
}

Veja que, ao criarmos a classe TesteService, podemos alterar o código da aplicação principal da seguinte forma:

var testeService:TesteService = new TesteService();

Implementando o SWIZ

Um dos melhores benefícios que o SWIZ traz é a possibilidade de separar todo o código Flex em camadas, assim como é feito no padrão MVC. Se você ainda não conhece SWIZ, é melhor conhecer, pois se está lendo este artigo está procurando criar aplicações com uma qualidade melhor e não há como chegar a esse nível sem um framework. O Swiz é o o melhor em termos de custo/benefício, porque nao é o mais fácil de aprender nem o mais complicado, e nao é o mais simples e nem o mais completo. É o meio termo em tudo.

Para usarmos o SWIZ, preciamos estabelecer algumas pastas dentro do projeto Flex, que serão nossas camadas. São elas:

• config: contém os arquivos que chamamos de “bean”, que são os arquivos que fornecem informações para serem injetadas em outras classes
• controllers: contém os arquivos que “ditam” a dinamica da camada de visualização
• services: contém os arquivos que fazem o acesso ao PHP
• events: contém eventos que podem ser disparados e mediados pelo flex
• valueObjects: são os VOs que iremos usar na aplicação
• views: contém os formúlários, é a camada de visão

Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:

??? xmlns:fx=”http://ns.adobe.com/mxml/2009″
??? xmlns:s=”library://ns.adobe.com/flex/spark”
??? xmlns:swiz=”http://swiz.swizframework.org”
??? xmlns:services=”services.*”
??? >
???
???
???

?

Neste bean, criamos a variável “testeService”, que é o tipo TesteService. Atenção quando ao uso de letras maiúsculas e minúsculas.? Sempre voltaremos no Bean.mxml para adicionar mais variáveis e com isso, injetá-las nos formulários e controllers da aplicação. Precisamos ainda configurar o Swiz no projeto principal da aplicação (melhoresPraticas.mxml):

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx”
?????????????? xmlns:swiz=”http://swiz.swizframework.org”
?????????????? minWidth=”955″ minHeight=”600″ xmlns:config=”config.*”>
???
???
???????
???????????
???????????????
???????????
???????????
???????????
??????????????? ??????????????????? eventPackages=”events.*”
??????????????????? viewPackages=”views.*”
??????????????????? />
???????????
???????????
???????????
???????????????
???????????
???????????
???????
???

???

?

Esta configuração, adicionada dentro do fx:Declarations, realiza uma configuração padrão no SWIZ. Basicamente adicionamos o Bean que criamos e definimos onde as classes relacionadas a eventos e formulários ficarão. Também definimos um LOG que será apresentado na aba Console do Flex se estiver rodando em modo de Debug.

Após a configuração

Podemos por exemplo criar a tela de login, e outras telas do sistema. Deixarei o código fonte da aplicação para que você possa olhar com calma.

Pegue o código fonte aqui

Conclusão

A lista a seguir é um resumo de melhores práticas que julgo importantes

• Use módulos/sub applications somente se precisar mesmo. Não comece um projeto de 10 telas querendo usar módulos para cada tela.
• Separe sua aplicação em camadas. Você escreve mais e cria mais artigos, mas o projeto fica mais consistente.
• Você não precisa criar o arquivo services-config.xml para conectar sua app no servidor. Pode-se criar uma classe cujo o endpoint é um caminho RELATIVO ao gateway.
• Use o caminho RELATIVO sempre, para faclitar o deploy da sua app. Isto é, use “../gateway.php” ao invés de “http://localhost/gateway.php”.
• Injete o controller na view, para passar dados à ela. Se deseja enviar mensagens para a view, então use eventos
• Não injete a view no controller.
• Use o dispatcher do SWIZ.
• Use o serviceHelper do SWIZ.
• Quando criar um formulário na view, faça o databind com uma variável do controller.
• Use eventos com moderação. Particularmente eu uso os eventos para notificar a view de alguma mudança, nunca para passar dados, que é função do controller.
• Se você quer chamar um método da view pelo controller, use eventos.
• Mais?

Chaus Report 2009 – Standish Group

Pesquisas como as realizadas pelo Standish Group apresentadas no Chaus Report 2009 demonstram que grande parte dos projetos de software falham ou são desafiados, seja porque não cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades não atendem às necessidades dos usuários ou porque todos estes fatores estão presentes em conjunto. Para o Standish Group um projeto de software é considerado um Sucesso quando todas a funcionalidades do escopo inicial são entregues no orçamento e cronograma planejado. O projeto é Desafiado quando ele sofre com atrasos, não cumpre o orçamento inicial e/ou é entregue com menos recursos e funções do que o definido no escopo inicial. E finalmente, o projeto é considerado Falho quando ele é cancelado antes da conclusão ou o produto da sua entrega nunca é utilizado.

Há algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. A referida constatação não é recente. Já em em 1968 houve um evento denominado conferência de NATO, que, entre outras coisas, tentou entender e discutir o porquê que a maioria dos projetos de software falham ou são desafiados. De lá para cá, a indústria de software vem evoluindo e a partir dos anos 90 surgiram várias propostas como o desenvolvimento de processos formais como RUP, pautados sobre modelos de maturidade como CMMI e a evolução de autores consagrados como Coad & Yourdon, Pressman, Sommerville, Rumbaugh, Booch, Jacobson, etc.

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas”: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software de maneiras bem peculiares, apesar dos objetivos finais serem os mesmos. Na escola tradicional o conceito de processo de desenvolvimento de software se assemelha ao usado em processos de produção industrial: um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações usadas para atingir uma meta, centrado em documentação e controle operacional. Já os adeptos das metodologias ágeis não estão presos a processos rígidos; o que interessa é aquilo que de fato agrega valor ao usuário, não que a escola tradicional não pense assim, como entregas rápidas ou como já diria um dos princípios ágeis: “Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de software de valor.”

Não obstante, a indústria de software é bastante dinâmica, novas idéias, tendências e tecnologias surgem a todo instante e em todas as partes do mundo. Acompanhar essa dinâmica é fator crítico de sucesso para profissionais e empresas que pretendem adquirir um diferencial no mercado. Um ponto fundamental para acompanhar o dinamismo do mercado está na habilidade de lidar de forma mais eficiente com as mudanças de requisitos, aumentar a motivação da equipe e melhorar comunicação com o cliente do projeto, e, para isso, será necessário estar pronto para introduzir uma nova cultura de liderança que irá alterar os papeis e trará uma nova forma de trabalhar transferindo parte da responsabilidade do gerente do projeto para a equipe.

A adaptação às mudanças decorrentes de fatores externos são uns dos conceitos centrais dos métodos ágeis. Onde os métodos mais formalizados e centrados em planejamento e documentação são preditivos na tentativa de prever as necessidades futuras, em contrapartida, os métodos ágeis são adaptativos e rapidamente se adaptam às novas exigências, aderindo ao lema “abrace as mudanças!”. A única medida de sucesso é a de produto funcionando.

Outro princípio importante é a simplicidade e pensamento enxuto. De acordo com o conceito de pensamento ágil, projetos de grande escala, por exemplo, não são desejáveis. Pelo contrário, é preferível minimizar a quantidade de trabalho daquilo que não precisa ser feito. Isto inclui, por exemplo, não gastar tempo escrevendo documentação desnecessária.

Cada vez mais a abordagem ágil de desenvolvimento de software vem se popularizando entre grandes empresas de sucesso como: google, yahoo, amazom.com, globo.com entre outras. No entanto, nem sempre as empresas que tentam adotar a filosofia ágil têm obtido o mesmo sucesso. Várias discussões tem se formado para entender o motivo do referido insucesso, e as conclusões estão convergindo para fatores como: falta de treinamento dos colaboradores; equipes hierarquizadas, e, sobretudo, resistência de mudança cultural.

Desenvolver software é uma tarefa que exige técnicas de engenharia e arte. Se uma empresa ou profissional não absorver a filosofia ágil dificilmente se manterá competitiva no cenário atual do mercado de software por mais que se implemente uma metodologia.

Nesse sentido, cabe a nós profissionais críticos, formadores de opinião, termos a a clara consciência de adotar processos tradicionais ou processo ágeis, ou no melhor dos casos, como integrar os dois para tirar o maior proveito.

Pouco mais de 1 mês atrás, no dia 20 de dezembro de 2010, eu peguei o meu Windows Phone 7. Venho acompanhando a história do sistema operacional desde? quando as primeiras informações foram divulgadas e confesso que fiquei empolgado e frustrado no MIX de 2010 por ver tantas informações e novidades legais e não ter ganhado nenhum aparelho, como todos estavam suspeitando na época.

Como o Windows Phone 7 não está disponível no Brasil ainda, tive que procurar uma forma de comprar um no exterior e trazer pra cá. Para complicar ainda mais as coisas, o aparelho que eu queria (LG Optimus 7) não é vendido nos Estados Unidos. Por sorte, tenho um grande amigo que estava morando na França e iria voltar ao Brasil pouco antes do Natal. Fiz algumas pesquisas e encontrei o aparelho que eu queria, desbloqueado, a venda na Amazon França. A parte mais difícil foi fazer a compra no site em francês sem entender uma palavra (3 vivas para os tradutores online).

Pronto, estava tudo certo. Em 1 mês o meu novo celular com WP7 estaria em minhas mãos. Eu só teria que fazer backup dos dados do meu MotoQ e migrar o que fosse possível para o novo aparelho. 2 dias depois de fazer a compra, fui vítma de um sequestro relâmpago e levaram meu celular (é claro que eu não tinha feito o backup ainda né….) junto com um monte de outras coisas. Fui obrigado a comprar outro aparelho para usar nesse meio tempo. Acabei pegando o seu irmão menor, LG Optimus One, com Android 2.2 (saiu super barato graças ao programa de pontos da minha operadora). Devo confessar que fiquei bastante satisfeito com a aquisição, pelo menos até a chegada do novo aparelho.

Agora vamos à parte que interessa, o review do meu LG Optimus 7 com Windows Phone 7.

O aparelho é muito bonito e passa uma sensação de ser bem sólido quando você o segura. Ele é extremamente bem construído, não tendo nenhuma falha de encaixe ou desajuste de nenhum tipo.

Os botões são fáceis de pressionar, sendo que o único que me desagradou foi o botão de ligar, que também serve para travar e destravar o aparelho, mas explicarei melhor mais adiante. Aliás, por falar em botões, esse é o ÚNICO aparelho com Windows Phone 7 lançado até agora em que os 3 botões frontais (voltar, home e busca) são físicos ao invés de touch. Em alguns dos outros aparelhos o botão “home” também é físico, mas o voltar e busca de todos os outros é touch, facilitando que você acidentalmente os toque enquanto usa uma aplicação ou jogo e acabe saindo da aplicação ou da tela em que estava.

Os aparelhos com Windows Phone 7 lançados até agora se diferenciam bem pouco, pois os fabricantes estão todos seguindo praticamente ao pé da letra as especificações mínimas de hardware impostas pela Microsoft para a plataforma. Os diferenciais desse aparelho são:

• Os 3 botões físicos para voltar, home e busca, ao invés de botões touch.
• Memória de 16 GB (a maioria dos aparelhos tem memória de “apenas” 8 GB)
• Recurso DLNA, que permite executar mídia do aparelho em dispositivos compatíveis, como TVs, home theathers, etc.
• Tela Gorilla Glass, praticamente impossível de riscar (descobri isso com quanse um mês de uso).

O aparelho encaixa bem na mão e é fácil de manusear com apenas 1 das mãos, mas eu acho que a LG fez algumas escolhas equivocadas no posicionamento de alguns ítens.

• Os botões de volume ficam do lado esquerdo do aparelho, quando na maioria dos outros telefones ele é do lado direto. Isso por si só não é um problema, mas fez com que houvesse botões em todos os lados do aparelho. Seria melhor se pelo menos um lado do aparelho não tivesse botões para que pudessemos segurá-lo ou apoiá-lo sem que nada fosse pressionado.
• O plug micro-usb que serve para sincronismo e carregar o aparelho fica do lado direto, onde normalmente ficam os botões de volume e ainda por cima é coberto por uma lingueta que deve ser removida com a unha e virada de lado para conectar o cabo (já que ela fica presa para não se perder). Para mim isso são 2 erros consecutivos: O primeiro foi colocar o plug de carregador/dados na lateral do aparelho e o segundo colocar essa tampinha safada que serve mais para irritar do que para proteger.
• O botão de ligar o aparelho, que também serve para bloquear e desbloquear, fica na parte superior, do lado direito. Ele é propositalmente pequeno e mais firme ao toque para que não seja pressionado acidentalmente, mas como os lados superior e inferior do aparelho são ligeiramente inclinados para frente, é difícil pressioná-lo com o indicador, o que torna necessário deslisar o telefone um pouco na mão para pressionar com o polegar (correndo o risco de derrubar o aparelho no processo), ou pressionar o botão com a outra mão.

Fora os detalhes acima, todos os botões são muito bem feitos e trabalham sobre uma pressão perfeita: nem duros demais, nem leves demais. Você difícilmente pressionará um deles acidentalmente.

Ele pesa 157 gramas, ou seja, é 30g mais pesado do que o LG Optimus One que eu havia acabado de comprar e 20g mais pesado do que o iPhone 4. Mas para ser justo, devo dizer que sua tela é de 3,8 polegadas, em comparação à de 3,2 do Optimus One e à de 3,5 do iPhone 4.

Ao contrário do que aconteceu com o Android, não tive nenhum problema para digitar no teclado virtual dele, tanto pelo tamanho da tela ser bom para minha mão, quanto pela qualidade e precisão do teclado virtual do WP7. A única reclamação que tenho do teclado é que não é possível digitar alguns caracteres acentuados se o teclado estiver configurado para inglês, então é necessário mudar para espanhol. Por outro lado, o telefone suporta mais de um perfil de teclado simultâneamente, tornando possível que você escolha se quer teclado em inglês ou espanhol enquanto digita. Se você escreve bastante em português vai achar melhor desabilitar o corretor do teclado com sugestão de palavras pois esse idioma ainda não é suportado (mas está previsto para o update do segundo semestre, junto com outras línguas e novas funcionalidades).

O sistema operacional é excelente, mesmo se tratando de uma primeira versão. Nesse tempo de uso eu não sofri nenhum travamento e ele responde extremamente rápido a todos os seus comandos (principalmente nas aplicações nativas, como o email ou navegador de internet). Há algumas coisas que precisam ser melhoradas e algumas funcionalidades que ainda não estão presentes, mas acho melhor deixar isso para um outro post.

Para quem pretende usar um aparelho desses no Brasil, é necessário saber de algumas coisas:

• Compre um aparelho que esteja sem bloqueio de operadora. A maioria dos aparelhos estão sendo vendidos bloqueados para as operadoras e vinculados à contratos de fidelidade. Os aparelhos desbloqueados são um pouco mais caros e difíceis de encontrar.
• É necessário um Windows Live ID para acessar o Market Place e sincronizar contatos. O seu Live ID deve estar vinculado à um dos países onde o aparelho já foi lançado. Você pode vincular mais de um Live ID ao aparelho, mas apenas o primeiro será usado para acessar o Market Place ou Xbox Live, no caso dos jogos. Esse Live ID primário só pode ser trocado fazendo um soft reset no aparelho. Se você já tem um gamertag do Xbox vinculado ao seu Live ID, ele será utilizado pelo jogos do aparelho também. Se o seu gamertag for da Xbox Live Brasil, não vai funcionar, e você terá que criar um novo Live ID com endereço americano ou de outro país onde o aparelho já tenha sido lançado para poder usar no aparelho.
• O WP7 sincroniza a lista de contatos e agenda de todos os Live IDs, contas do Google e Facebook que você cadastrar. Você pode mudar as opções de sincronismo dessas contas, exceto do Live ID principal. Todos os seus contatos terão uma cópia online, que será facilmente baixada para um outro WP7, caso você o vincule ao mesmo Live ID. Isso é ótimo para quando você decidir trocar de aparelho daqui a algum tempo.
• Para desbloquear o aparelho para desenvolvimento, é necessário que o regional settings do computador, do telefone e da sua Live ID estejam iguais. O desbloqueio é feito usando um aplicativo que vem junto com o SDK de desenvolvimento. Para poder desbloquear, é necessário também que você tenha se cadastrado como desenvolvedor e pago a taxa de US$ 99,00 + impostos (que vale por 1 ano). Esse cadastro ficará vinculado ao seu Live ID (pode ser um live ID brasileiro), que é o que deve ser utilizado para desboquear o aparelho. Cada cadastro desses dá direito a desbloquear 3 aparelhos. Se for uma empresa e precisar desbloquear mais aparelhos, deve entrar em contato com a Microsoft.

Por enquanto é só. Em breve publicarei mais informações sobre o sitema operacional e sobre a plataforma de desenvolvimento.

Já?

Chegou aquela altura do ano em que do lado do WordPress.org se começam a dar os retoques finais na próxima versão do WordPress (a 3.1, neste caso). Os utilizadores do WordPress.com são automaticamente incluídos na versão beta, dando-lhe todo o acesso a novas funcionalidades, um mês antes de estas serem lançadas oficialmente. Isto é bom, não só porque lhe dá um acesso antecipado ao que aí vem, mas como também a sua opinião nos ajuda a melhorar ainda mais. Estou muito animada, tanto pelos os novos recursos que acabámos de implementar, como por serem adições que já desejava há muito tempo. Aqui estão as novas funcionalidades que já pode ver no seu painel:

Criação mais fácil de links internos

Fi.nal.mente.

Está a escrever um post (ou uma página) no WordPress. Menciona algo que tenha escrito antes, e pensa: “Já sei, vou criar uma ligação para esse post!” O que é que fazia? Pode ser que abrisse um novo separador ou janela e que procurasse no seu conteúdo na sua lista de posts, ou ainda que visitasse o seu blog e procurasse esse post. Seja como for, teria que encontrar esse conteúdo, obter a respectiva URL, de modo a ao clicar no botão de link no editor de posts, poderia colá-la. Certo? Isso são o quê? Entre 5 a 8 passos, dependendo de como o fazia? Não mais!

Posts e páginas existentes podem ser encontrados e ligados com uma pesquisa dinâmica.

Com a nova funcionalidade de links internos, pode agora indicar qualquer URL para criar um link, como costumava fazer, ou então procurar nos seus posts e páginas existentes logo ali, na janela de inserção de links. Uma combinação de pré-carregamento, preenchimento previsivo e alguma magia Ajax tornam o uso da ferramenta de criação de links numa alegria (e confira quão mais rápida está a janela!). Esperamos que isto o incite a fazer mais conexões entre o conteúdo do seu site, o que tornará mais fácil para os seus visitantes encontrar mais conteúdo relacionado. Agora todos juntos: Viva! (Certo?)

Ordem por colunas

Quando visita a página de Posts (ou de Páginas, ou de Media ou de qualquer outra informação em lista), alguma vez desejou poder clicar no nome da coluna para alterar a visualização, ordenando por exemplo a informação por data, por ordem alfabética, por autor ou por outro critério? Eu sei que eu quis, desde sempre. Já temos! Este recurso é o resultado de um bem-sucedido projecto de um aluno do Google Summer of Code, demonstrando ainda que o programa é uma ótima maneira de se envolver com o desenvolvimento do WordPress. A pequena seta ao lado do título da coluna (na minha imagem de exemplo, a coluna Data) mostra a coluna pela qual a informação está ordenada, e se a ordenação é ascendente ou descendente. Basta clicar no cabeçalho de qualquer coluna para ordenar por essa coluna ou para inverter a ordem.

Paginação melhorada

Se tem muito conteúdo, pode ser que tenha tido uma experiência levemente irritante ao navegar as páginas posts, media ou outros. Clicar para a frente e para trás é fácil, tal como saltar para a primeira ou última página, mas então e o meio? Imaginemos que tem 23 páginas de posts; está na página 6 e, com base nas datas, acha que o que está à procura deve estar por volta da página 15. Teria que clicar várias vezes para avançar algumas páginas, até chegar à página desejada. Não mais! Com o novo estilo de paginação, os botões para a frente/fim e para trás/início continuam lá, mas agora pode ir directamente para qualquer página, alterando apenas o número editável mostrado na área de paginação (e carregar em Enter).

Pesquisas com Ajax

Os resultados de pesquisas são agora mais rápidos e não requerem actualizações do painel no seu browser graças à adição de Ajax. Rápido!

Esquema de cores revisto

Nas opções do seu perfil, tem uma escolha de esquemas de cores do painel, cinza ou azul (o padrão é cinza). Actualizamos o esquema de cores cinza há algum tempo, mas não actualizamos o azul. (Lembra-se quando mudamos do cabeçalho do escuro para o mais claro? Bons velhos tempos.) O novo esquema de cores azul é mais leve, mais limpo e com base nos mesmos tons que o esquema de cor cinza, mas com uma tonalidade azul, para que o foco possa permanecer firmemente na criação de conteúdo, sem distrações. Se você nunca experimentou o esquema de cor azul, agora seria um óptimo para experimentar e ver se gosta! Existem outras cores que gostaria de ter como opções? Diga-nos nos comentários!

Suporte melhorado para IE9

Para aqueles que têm tido problemas em usar arrastar e largar no painel ou ainda algum problema com o editor visual na criação de posts, com o Internet Explorer 9, foram feitas melhorias para funcionem agora sem problemas no mais recente browser da Microsoft.

A ter em conta: estas funcionalidades são novas e embora tenhamos trabalhado nelas durante bastante tempo, poderá encontrar um erro que nos tenha escapado. Se alguma delas lhe estiver a causar problemas, pode deixar um comentário neste post durante as próximas duas semanas, falar sobre isso nos fóruns, ou contactar o suporte através dos canais habituais.

Espero que apreciem estas notícias, tanto quanto nós gostamos de as desenvolver. Bom blogging!

Actualização

Graças aos vossos comentários, conseguimos já detectar e corrigir alguns erros que escaparam nos nossos testes.

• Corrigimos um conflito com o plugin de CSS usado no WordPress.com (a incompatibilidade causava comportamentos estranhos no editor). Assim, se tinha problemas tais como ver texto a ser sublinhado ou em negrito inesperadamente, isto não deve acontecer mais.
• Corrigimos uma falha do IE8 com a janela de inserção de links, mas ainda estamos a trabalhar em alguns problemas no IE7. (Agora a sério, usar browser antigos não é uma boa ideia. Actualize-o!)

Se mesmo assim continuar com problemas com as novas funcionalidades, quando deixar um comentário ou contactar o suporte, por favor indique o sistema operativo e browser que está a usar, para nos ajudar a resolver o problema mais depressa. Exemplos: “Estou a usar Firefox 3.9 com Mac OSX 10.5.”  ”Estou a usar Google Chrome em Windows 7.”

Obrigado!

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

O grande e mais que antecipado FlashCamp Portugal 2010 foi realizado no passado Sábado, em Lisboa.

Para já, fiquem aqui com o brilhante vídeo criado pelo Márcio Bonus Pité para a introdução do FlashCamp Portugal 2010:

Flash Camp Portugal – Open titles from Márcio Bonus Pité on Vimeo.

Para as pessoas que vieram do Norte, como eu, o dia foi longo! Começou com a entrada no comboio às 05:47 da manhã (ouch!) e seguiram-se duas horas e meia a falar de tudo e mais alguma coisa. Obviamente a tecnologia foi o tema dominante assim como praticamente todos os software da Adobe. À chegada à capital, fomos de Metro até à Universidade Lusófona onde já estavam muitas pessoas à entrada.

Fica aqui um “relato” sobre o evento:

AUGPT Presentation and FlashCamp2010 - Como não podia deixar de ser, o Paulo Moreira e o João Fernandes foram os primeiros a falar. Apresentaram o Adobe User Group Portugal, mostraram a agenda do dia e que planos tinham para o grupo. É sempre bom ouvi-los dizer que querem sempre mais e mais e mesmo com uma fasquia tão alta, prometem para o ano voltar a surpreender-nos. Aqui estamos nós para ajudar e participar!

Mike Jones – Designing Flex Components - Depois de aberto o evento por parte dos organizadores, foi a vez do Mike Jones, Platform Evangelist do Flex fazer a sua apresentação sobre como customizar componentes em Flex.

O Mike falou sobre como podemos integrar o Flash CS5 e o Flash Builder para podermos criar componentes e integrar os mesmos nas nossas soluções. Foi uma sessão interessante uma vez que explicou como podemos facilmente atingir um resultado bastante interessante recorrendo a estas duas ferramentas.

Coffee Break (manhã) – Coffee Break e muito network. A maior parte dos participantes aproveitaram para conversar um pouco, beber um café e foi porreiro rever muita malta que já encontrei nos eventos de Lisboa e também nos eventos aqui do Porto. Estes trinta minutos também foram agitados devido ao pequeno jogo de networking que estava preparado para os participantes. A ideia era trocar pins uns com os outros de forma a termos quatro cores diferentes para podermos participar nos sorteios ao fim do dia.

Paulo Fierro - Mobile projects - Notava-se perfeitamente que o Paulo Fierro estava totalmente à vontade na sua apresentação. Foram umas dezenas de minutos em que se falou de oportunidades de negócio resultantes de nichos de mercado que são encontradas quase ao acaso e para satisfazer as nossas necessidades pessoais. Falou também que, por vezes, não basta saltar de cabeça para um projecto e que convém estarmos com os pés na terra porque podemos sempre ter alguns dissabores ao longo do tempo. É bom ver este tipo de abordagem que quase nunca é falada em eventos tecnológicos e de certeza que colocou ali muitas cabeças cheias de vontade para pegarem nos seus projectos e alcançar os seus objectivos.

AUGPT Community Showcase - Jorge Varandas/Paulo Afonso, Nuno Morgadinho, Nuno Ribeiro, João Gonçalves - Como é óbvio, uma das mais-valias destes eventos é promover, e bem, o que se faz em Portugal. Foi este o caso. A qualidade estava bastante elevada nos projectos que foram apresentados. O João Gonçalves mostrou o seu último trabalho para a Audi que era bastante interactivo e que, pelos vistos, foi um sucesso para a marca fazendo esgotar as datas dos test-drives para os carros em questão! O Jorge Varandas e o Paulo Afonso (quem diria que ele era nortenho? Uma surpresa!) monstraram alguns truques bem interessantes para elevar o nível dos sites feitos em Flash a um patamar superior não descurando os factores de SEO que tanto importam às marcas. O Nuno Morgadinho também demonstrou projectos muito interessantes nos quais tinha trabalhado. Por fim o Nuno Ribeiro que, depois um showcase dos seus trabalhos, resolveu falar sobre o que está mal no mercado português a nível de web design, empresas, projectos para a web, etc. Foi a apresentação que causou mais controvérsia e discussão. No entanto, como tinha chegado a altura de almoçar e a malta tinha de ir embora para cumprir os prazos do evento, tivemos todos de sair da sala, porque era garantido que havia ali pano para mangas…

Almoço – Almoço com os estrangeiros a gostarem da dobrada que serviram na cantiga da faculdade! Aproveitou-se a oportunidade para se falar sobre as apresentações que ocorreram de manhã e também sobre tudo e mais alguma coisa

João Saleiro – Skin Flex 4 apps with Spark – O João Saleiro brindou-nos, como é habitual, com uma apresentação muito hands-on que nos demonstra como os profissionais trabalham no mercado actual. Confesso que gostei bastante do conteúdo se bem que entendo que, com um plateia muito preenchida de designers, foi um assunto que colocou algumas pessoas confusas. Acho que o problema aqui foi não passar a informação que os designers não precisavam de escrever uma linha de código para poder criar so componentes para os developers trabalharem.

Niqui Merret – Bugs Catch’em All – Uma apresentação super divertida mas ao mesmo tempo muito séria sobre um assunto que nos deve preocupar a todos… Os bugs! Foram mostradas diversas plataformas e software que nos ajuda na exterminação destes pequenos problemas que fazem a nossa vida um inferno! Quando abordado com uma precisão quase matemática, a forma de analisar um bug pode tornar-se um processo interessante! Confesso que não conhecia o “Charles” visto que sempre utilizei o Service Capture, mas vou, com certeza, testar!

Coffee-Break (tarde) – Foi uma surpresa encontrar pessoas que estão em Lisboa a trabalhar e que já trabalharam aqui no Porto comigo. Depois de colocar a informação up-to-date, foi a vez de falar com mais malta que não conseguia e falar sobre o Adobe User Group Porto.

Rui Silva – Internationalization in the Flash Platform – Depois do descanso da tarde, foi a vez do Manager do Adobe User Group Porto, o Rui Silva, falar sobre um tema que tendemos a esquecer mas que é de importância extrema quando pensamos em internacionalizar o nosso produto, as línguas! Foram dadas várias dicas e mostradas várias soluções que a plataforma Flash já possui para facilitar esta implementação de múltiplas línguas nos nossos produtos e que, colocar o nosso software em outra língua não é só a “bandeirinha” e os textos.

Lee Brimelow – My Head Hurts – Por fim… Um senhor que é quase a estrela de rock da plataforma Flash mundial (muito por culpa do seu site, gotoandlearn que deverá ter sido o primeiro sítio onde as pessoas aprenderam a programar em Flash, e ao seu blog de referência, theflashblog). Nota-se perfeitamente que o Lee Brimelow é um senhor a fazer apresentações. Já muito habituado a estas andanças, tratou de um assunto sério, que nos preocupa a todos (Flash, HTML5, onde estamos, onde vamos, etc.) mas de uma forma extremamente interessante e que gerou muitos comentários da parte dos presentes.

As críticas, todas as que pensei ter foram apontadas noutros blog, mas aqui ficam:

- Os microfones. Como a sala era grande, não se ouvia muito bem o que as pessoas diziam;

- O microfone do speaker. Como era estático, obrigava-os a ficarem quietos, o que para alguns, foi uma tensão extra (ou no caso de serem altos, como o João Saleiro, que se tinha de curvar para que se fizesse ouvir bem);

- Acho que não haver uma indicação que havia wireless, e uma hashtag para o twitter, foi uma falha, porque a malta queria era comunicar e expressar o que ouvia;

- O jogo dos pins podia ser mais difícil, vi alguma malta a aldrabar aquilo eheh;

Tirando estas pequenas falahas, foi um dia muito bem passado, com muito conteúdo para digerir e só posso dizer… Venha o próximo!

Um muito obrigado ao Paulo, ao João e a muitos outros que fizessem com que o evento fosse um sucesso e parabéns à malta que criou o logótipo, o site, e tudo o resto!

PS :Aqui fica uma grande recordação deste dia (obrigado ao Francisco Costa pela foto!):

Twitter!

Objetivo: Este post tem como objetivo dar início a discussão de um tema complexo e extenso, a Gestão da Qualidade. Nesse primeiro texto eu vou falar sobre como se iniciou o conceito de Qualidade, como as empresas dão início a busca por qualidade e como dar o “start” na conscientização sobre qualidade.

Gestão de Qualidade – Round 1

Quando tudo começou

A definição de Gestão de Qualidade é mais antiga do que muitos imaginam. Um dos nomes mais conhecido nesse meio é o de Joseph Moses Juran, que publicou seu primeiro artigo sobre qualidade relacionada à engenharia mecânica em 1935 e seu livro Quality Control Handbook, publicado em 1951, ainda é referência na área.

Um exemplo de como a Gestão de Qualidade foi de grande importância é o Japão. Após a 2ª guerra, ele chamou Juran para palestrar à grandes empresários japoneses e ajudou o Japão a conseguir produzir produtos de qualidade e a construir a reputação “made in japan”.

Hoje em dia…

Hoje a maioria das empresas, indiferente do segmento, possuem uma área de qualidade e se dizem conscientes da importância de gerir a qualidade do que é produzido. Mas o que acontece na prática é a burocratização do processo ou seu total abandono e, seja qual for o extremo que a empresa esteja, ela está longe de estar consciente da importância da gestão de qualidade. O ideal, para qualquer empresa, é um processo condizente com sua maturidade e realidade e esse é o ponto onde a maioria das empresas acabam errando.

O mercado possui diversas opções de processos de gestão de qualidade, uns mais detalhados do que outros, uns mais engessados que outros, mas todos focados na busca pela qualidade. Mas como saber qual é o melhor processo para a minha empresa? Antes de responder essa pergunta é preciso responder a: Como está a minha empresa? Sem saber a resposta dessa pergunta fica muito difícil saber qual processo se adequará melhor ao processo já vigente, pois a Gestão de Qualidade não é apenas a verificação do produto final, ela faz parte de cada etapa e processo da empresa pois tudo que acontece pode e vai causar algum impacto naquilo que está sendo produzido ou oferecido.

O primeiro passo a ser dado é se conscientizar do que é qualidade, pois é algo muito subjetivo e diretamente ligado aos conceitos individuais de cada um. O interessante é começar a entender os conceitos de qualidade já divulgados, como o livro Quality Control Handbook do Juran (http://www.juran.com/blog/) ou os conceitos da FNQ – Fundação Nacional da Qualidade (https://www.fnq.org.br/site/376/default.aspx) para ter uma base para construir o próprio conceito de qualidade e começar a moldar a Gestão de Qualidade ideal.

Abaixo seguem alguns pensamentos sobre Qualidade para reflexão:

“Qualidade não é uma idéia ou uma coisa concreta, mas uma terceira entidade independente das duas…embora não se possa definir qualidade, sabe-se o que ela é.” (Pirsig, 1974:185)

“Qualidade consiste na capacidade de satisfazer desejos” (Edwards, 1968:37)

“Na análise final de mercado, a qualidade de um produto depende de até que ponto ele se ajusta aos padrões das preferências do consumidor.” (Kuehn & Day, 1962:101)

“Qualidade é a adequação ao uso” (Juran, 1974:2)

Se você parar e refletir sobre cada um desses pensamentos citados, vai perceber que um complementa o outro e que em determinados momentos um se encaixa melhor que o outro a uma determinada situação. Esse é um dos pontos chave da qualidade, saber aplicá-la da forma certa no momento certo.

Na prática, a qualidade é muito mais fácil de ser compreendida do que na teoria, então vamos supor que você tenha que definir qual o padrão de qualidade a ser adotado para se produzir uma corda. Simples, certo? Mas e se eu te falar que essa corda tem que suportar o peso de um corpo humano pois ela será usada por alpinistas…o que muda? O padrão de qualidade agora tem que levar em consideração que uma falha na corda pode matar uma pessoa, ou seja, não pode haver falhas. Se fosse uma corda para fazer laços em embalagens comuns as falhas seriam aceitáveis, mas não no caso de cordas usadas para alpinismo!

Tente, da próxima vez que for fazer algo, pensar se você realmente tem consciência do padrão de qualidade necessário para executar essa atividade e, se estiver certo que sabe, pergunte à pessoa ao lado se ela concorda com o que você acredita ser o padrão de qualidade ideal…você pode se surpreender com o quanto distorcemos a qualidade ideal para continuarmos na nossa zona de conforto.

Twitter!

Entendendo melhor Maven 2

O objetivo deste post é entender um pouco melhor o que é o Maven e como que o Maven lida com as fases do build, além de entender um pouco de como funciona a resolução de dependências.

O que é o Maven?

Um dos principais problemas desenvolvendo sistemas é como fazer com que toda a equipe construa o artefato final da mesma maneira com as bibliotecas e configurações corretas. Existem várias maneiras de tratar esse tipo de problema. Uma das maneiras mais comuns é usar alguma ferramenta que entenda alguma linguagem de script e copie as dependências e configurações para os lugares corretos e gere um pacote com a aplicação. Uma ferramenta comum muito usada no mundo Java é o Ant (http://ant.apache.org/). Com o Ant é possível escrever scripts de ‘build‘ para copiar bibliotecas de lugares específicos, arquivos de configurações e qualquer outro tipo de recurso para o artefato da aplicação. Com isso garantimos que qualquer desenvolvedor consiga gerar o artefato da aplicação localmente, sabendo que este artefato gerado é o mesmo que o resto da equipe irá usar e que possivelmente será usado em produção. Porém existem alguns problemas com essa abordagem. O primeiro problema que vem a cabeça é, onde guardamos as bibliotecas externas ao nosso projeto para que o Ant as encontre? A solução mais comum é guardá-las no repositório junto com o código fonte, assim todos os desenvolvedores compartilharão as mesmas dependências e os caminhos das pastas são mantidos.

Esse tipo de organização é muito adotada e funciona muito bem para projetos pequenos e com equipes bem pequenas. Quando começamos a prolongar um pouco a vida do projeto percebemos que o overhead de manutenção do mesmo começa a interferir no andamento do desenvolvimento. Isso porque o número de dependências começa a aumentar e com o tempo vão saindo versões novas de algumas dependências antigas(podemos entender dependências como sendo bibliotecas). Se todas as dependêcias estão na mesma pasta, fica muito difícil fazer o controle de versão e de transitividade das mesmas. Agora pense em um caso mais complicado: decidimos criar um novo módulo para o projeto. Nesse caso, todas as dependências que este novo módulo necessita e estão no módulo já existente, devem ser duplicadas no repositório. Deve-se fazer isso pois já que estamos falando de módulo, devemos ser capazes de construir o tal módulo independente da existência dos outros. Ou seja, duplicamos também o esforço para manter a organização das dependências.

Essa é uma das motivações pricipais pela qual a apache criou o Maven (http://maven.apache.org/).

O Maven é uma ferramenta de integração de projetos. É responsável por gerenciar dependências, controlar versão de artefatos, gerar relatórios de produtividade, garantir execução de testes, manter nível de qualidade do código dentre outras. Muitas pessoas confundem o maven como sendo uma alternativa para o Ant, ou para o Ivy (http://ant.apache.org/ivy/) o que não é verdade. O Maven inclusive disponibiliza a funcionalidade de rodar arquivos do Ant durante o build.

Voltando ao nosso problema citado anteriormente, com o Maven consiguimos isolar as bibliotecas usadas no projeto em um ‘repositório‘ compartilhado pela equipe, ou por toda internet no caso do repositório central do Maven. Dessa forma não nos preocupamos com duplicidade de dependências entre módulos do projeto e nem em disponibilidade das mesmas no repositório de código. Quanto a versão das dependências, estas ficam centralizadas em arquivos de configuração dos projetos de forma explícita e hierarquisada pelos módulos (POM). Com isso o Maven consegue se encarregar de fazer as devidas substituições de bibliotecas e identificar possíveis falhas no grafo de dependências.

O que torna o Maven muito poderoso é a facilidade que ele fornece para se trabalhar com vários módulos de um mesmo sistema e sua extensibilidade para novas funcionalidades com o uso de ‘plugins‘. Existem plugins de geração de código, de integração com plataformas de teste e inclusive suporte a IDEs como Eclipse e NetBeans. Isso torna o projeto muito mais flexível dentro da equipe, pois cada desenvolvedor pode escolher a IDE com que vai trabalhar sem se preocupar em atrapalhar o resto da equipe. Um outro plugin que será visto no post sobre Flex + Maven, é o flexmojos (http://flexmojos.sonatype.org/). Esse plugin é responável por integrar o Flex aos projetos do Maven de maneira transparente, executando o build da mesma forma que nos projetos Java. O plugin também disponibiliza a funcionalidade de preparar o projeto Flex para ser importado no FlexBuilder.

Vamos começar a entender melhor o Maven estudando seu funcionamento.

Fases do build

Algo interessante sobre este post é que o que será abordado é sempre referente a ‘um pouco’, ou ‘um pouco melhor’. Isso porque o maven é uma ferramenta bastante complexa dependendo do nível de customização e da necessidade que se tenha. A primeira parte do post cobre as fases executadas durante o build.

Uma fase nada mais é do que um estágio onde são executadas algumas regras sobre o projeto e se obtem algum resultado no final. Por exemplo, a fase de testes roda os testes da aplicação e obtém um ‘OK’ ou um ‘FAIL’, no segundo caso o build é interrompido. Tais fases são executadas dentro do ‘lifecycle‘ do build. O ‘lifecycle‘ é composto de ‘goals‘ e são estes:

• Validate
• Compile
• Test
• Package
• Verify
• Install
• Deploy

Se você está lembrado do post anterior, usamos o comando do maven com os goals ‘clean‘ ‘install‘. Note que o goal ‘clean‘ não está presente no lifecycle do build, por isso tivemos que invocá-lo na linha de comando além do goal ‘install‘. O ‘clean‘ apenas apaga a pasta target, que como visto no post anterior contém os ‘.class‘ e os artefatos gerados pelo build. Os goals do lifecycle são executados nessa ordem mostrada acima. Um pouco sobre cada goal:

• validate: valida que os ‘poms‘ dos projetos involvidos estão corretamente escritos e que todas as informações necessárias para o build estão presentes;
• compile: compila todos os códigos do projeto, inclusive os códigos das classes de teste;
• test: roda os testes que estão em ‘src/test/java‘, e certifica-se que todos estão passando, caso contrário o build é interrompido;
• package: usa o código compilado e testado que está em ‘src/main/java‘ e cria um arquivo reusável, por exemplo jar;
• integration-test: nesta fase serão rodados os testes que necessitam do jar do projeto ‘deploiado‘ para serem rodados;
• verify: roda as verificações necessárias para se certificar que os pacotes gerados estão corretos e passam nos critérios de qualidade;
• install: copia o arquivo gerado para o repositório local para que esteja disponível localmente para outros projetos;
• deploy: copia o arquivo gerado para um repositório na rede ou remoto, para que esteja disponível para outros desenvolvedores.

Ainda lembrando o exemplo anterior, em um dos comandos executados possuia um goal que não está no lifecycle e que não foi citado: ‘eclipse:eclipse‘. Neste caso não se trata de um goal, mas sim da execução de um ‘plugin‘. ‘Plugins‘ no maven alteram o lifecycle adicionando novos goals em determinadas fases. No caso do ‘eclipse:eclipse‘, estamos invocando o método ‘eclipse‘ no plugin ‘eclipse‘, para isso usamos os ‘:‘. Esse plugin é responsável por criar os arquivos que o Eclipse entende e dessa forma consiga importar o projeto. Não está no objetivo deste post tratar de plugins, por isso se você se interessar pelo assunto existe uma boa documentação no site do próprio maven: http://mojo.codehaus.org/. Plugins do maven são chamados de ‘Mojos‘. Trataremos de ‘plugins‘ em um post futuro.

POM

Project Object Model – se trata do ponto de partida para o maven executar seu lifecycle. Nada mais é do que um arquivo XML que descreve propriedades e características do projeto, como por exemplo a versão do compilador que será usada (exemplo no post anterior):

Repare que todas as propriedades que foram escolhidas no momento em que geramos o projeto estão definidas aqui, por isso se for preciso editar alguma delas, podemos fazer direto aqui no XML. Lembrando que para as modificações surtirem efeito, temos que executar ‘$ mvn install‘ e ‘$ mvn eclipse:eclipse‘ para refletir os resultados no Eclipse.
Além de guardar as informações mínimas necessárias para se executar o build, no pom definimos também os plugins que serão utilizados, os repositórios de artefatos que serão buscados, os relatórios que serão gerados, o pom que servirá como ‘parent‘, as dependências do projeto, dentre outras coisas.

Nesse post trataremos das dependências, as outras funcionalidades serão abordadas em outros posts.

Para definir um pom que servirá como ‘parent‘ de seu projeto, basta adicionar no pom de seu projeto o ‘groupId‘, ‘artifactId‘ e ‘version‘ do parent:

Nesse caso estamos falando que o pom do projeto ‘tec-versions‘ que pertence ao grupo ‘br.com.dclick.framework‘ na versão 1.0.4-SNAPSHOT será o parent do nosso pom, portanto nosso pom herdará todas as configurações, dependências e propriedades definidas no pom do ‘tec-versions’.

Dependências

Uma das funcionalidades mais poderosas do maven é a resolução de dependências. Não é uma funcionalidade exclusiva, mas a maneira com que é feita resolve muito bem a maioria dos problemas. Existem algumas outras ferramentas com o mesmo intuito, como por exemplo o Ivy da própria Apache, mas vimos que o maven é muito mais do que apenas uma ferramenta de resolução de dependências.

A definição das dependências do seu projeto é feita inteiramente no pom. Para isso usamos a tag <dependencies/> e dentro definimos cada dependência individualmente. Por exemplo, para definirmos a dependência do JUnit 4.8.1 basta adicionar o seguinte trecho no lugar do que já existe:

Repare que está definida uma tag que ainda não foi mencionada: ‘scope‘. ‘Scope‘ explicita o escopo em que o artefato definido será usado, nesse caso estamos dizendo para o maven adicionar a dependência do JUnit apenas no momento em que os testes forem executados, garantindo assim que a dependência não seja adicionada no artefato que será gerado. Alguns outros escopos:

• compile: escopo padrão do maven para o momento em que o código é compilado e vai junto com o artefato;
• provided: adicionado no momento da compilação, mas não vai junto com o artefato. Dessa forma você está dizendo que a dependência virá de maneira transitiva de alguma outra dependência;
• runtime: não inclui no artefato, pois estará disponível em tempo de execução;
• test: inclui apenas no escopo de testes;
• system: não inclui no artefato, pois estará disponível no ambiente;
• import: incluirá TODAS as dependências do ‘depencyManagement‘ que está definido no pom ‘parent’.

Não falamos ainda de ‘depencyManagement‘, mas será tratado mais a frente.

Toda dependência no maven é transitiva, ou seja, se alguma dependência precisa de uma outra não especificada no seu projeto, o seu projeto passará a depender dela também, e será incluida no artefato gerado. A única exigência do maven é que as dependências não sejam cíclicas, e não existe restrição quanto ao número de níveis de dependências.

Dependency Management

O dependency management é responsável por controlar as versões das dependências definidas no projeto. Por exemplo podemos definir a dependência do JUnit no dependency management, e apenas referenciar a dependência na tag depencies do projeto:

Uma boa prática é definir todas as versões das dependências em um dependency management do pom parent do seu projeto. Dessa forma todo projeto novo que surgir, basta herdar desse parent que as versões já estarão compartilhadas e continuarão centralizadas em um único projeto. Mesmo com a dependência definida no management, os projetos ainda podem definir suas próprias versões de artefatos e o maven dará prioridade para os mais próximos do projeto.

Nos próximos posts veremos como usar alguns plugins úteis para o ambiente de desenvolvimento. Também falaremos de outras funcionalidades como por exemplo geração de relatórios, ‘release‘ de projetos, entre outras.

A eXtreme Programmig (XP) proposta por Kent Beck [BECK, 2004] tem o objetivo de propor uma metodologia ágil para equipes de tamanho pequeno a médio, onde o desenvolvendo de software está inserido em um contexto de requerimentos vagos ou que mudam rapidamente.  O próprio autor descreve a Programação eXtrema como: “A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”. [BECK, 2004].  Ainda segundo [BECK, 2004], a XP reconhece que os projetos precisam dedicar-se à obtenção da redução dos custos e tirar vantagem daquilo que foi economizado. Além disso, defende a não especialização dos membros do time, ou seja, todos participam de todas as atividades, em pares e com sistema de rodízio dos pares o desenvolvimento de infra-estrutura e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.

Segundo [BECK, 2004], a XP se distingue das outras metodologias por:

• Seu feedback antecipado;
• O planejamento incremental, que gera rapidamente um plano geral que evolui com o decorrer do projeto;
• Sua habilidade de implementar as funcionalidades de forma flexível considerando as necessidades mutáveis do negócio;
• Sua confiança nos testes automatizados;
• Sua confiança em comunicação oral;
• Sua confiança em um processo de projeto evolutivo que dura tanto quanto o sistema;

Risco: O Problema Básico

A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de software tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-se software de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do software, como: (i) cronograma irreal; (ii) cancelamento do projeto por vários atrasos no cronograma; (iii) o sistema é descontinuado pelo alto custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído; (iv) o negócio é mal compreendido e o software desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o software seja finalizado; (vi) funcionalidades inúteis. A missão da XP é aceitar o risco como problema a ser resolvido, onde o objetivo é encontrar a solução. Nesse sentido, a necessidade é criar um modelo de desenvolvimento de software que trate desses riscos.

Além de mitigar ao máximo os riscos, a metodologia XP advoga que quatro variáveis têm de ser controladas no projeto – custo, tempo, qualidade e escopo. Dessa forma, o modelo desenvolvimento de software é dirigido sob a perspectiva de controlar as referidas variáveis. Em um projeto, as referidas variáveis são restrições inerentes ao produto final. Eventualmente se o custo e/ou o tempo forem escassos, é muito provável que a qualidade do produto entregue possa estar muito inferior àquela esperada no escopo do projeto.  A XP cria valores, princípios de atividades básicas e práticas para tentar conduzir bem os problemas correlacionados à efetivação dos riscos do projeto. Esses valores podem ser caracterizados em:

1. Comunicação: deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto de um projeto. Segundo [BECK, 2004], “Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
2. Simplicidade: é representada na XP pela busca pela “coisa mais simples que possa funcionar” [BECK, 2004]. O propósito é construir algo simples e direto que solucione problemas de hoje e ter certeza de que isso seja suficientemente flexível para ser refinado e expandido de modo a solucionar os problemas de amanhã, mas fundamentalmente não se preocupa hoje com os problemas de amanhã.
3. Feedback: seu objetivo é criar ciclos de realimentação que atuam em intervalos de tempos pequenos como dias e minutos, em relação aos testes de unidade, e, grandes semanas (dias, semanas) em associação a teste de aceitação de usuário, e,  planejamento e cronograma de projeto.
4. Coragem: é o valor que permite aos participantes da XP se aventurarem em projetos de alto risco e alta recompensa nas tarefas de desenvolvimento. Isso muitas vezes se manifesta na forma de desenvolvedores que constroem protótipos descartáveis durante a codificação.

Princípios Fundamentais da XP

De acordo com [BECK, 2004] os princípios fundamentais da XP são:

1. Feedback rápido: o princípio é obter o feedback, interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível, realimentando o que foi aprendido em dias ou semanas, em vez de meses ou de anos.
2. Simplicidade presumida: este princípio dita que a equipe deve pressupor que todo problema tem uma solução razoavelmente simples. Como conseqüência, o tempo poupado na maioria dos problemas para os quais isso é válido pode ser usado para abordar problemas que realmente necessitem de soluções complexas.
3. Mudanças incrementais: parte do princípio que grandes modificações feitas de uma só vez têm grandes chances de não dar certo. Assim, qualquer problema é resolvido por meio de uma série de mudanças menores.
4. Aceitação das mudanças: este princípio se apóia na premissa da XP que de desenvolver software no contexto de requerimentos vagos ou que mudam rapidamente. As idéias é que os membros da equipe devem simplesmente aceitar as mudanças como algo natural, diário, em vez de algo que ocorre eventualmente.
5. Alta qualidade: ninguém gosta de fazer um trabalho de baixa qualidade. Todos gostam de fazer um bom trabalho. A XP defende que se você não vai fazer algo bem, então não faça independentemente das restrições de cronograma e orçamento.

Atividades Básicas do Desenvolvimento

[BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de software utilizando XP, sendo elas:

1. Codificar: as práticas da XP utilizam o código como um mecanismo para atingir objetivos secundários incluindo o aprendizado rápido e uma melhor comunicação. Algumas das práticas citadas no tópico a seguir estão ligadas à codificação: refatoração, programação em pares e integração continua.
2. Testar: está fortemente relacionada à codificação. Os desenvolvedores devem escrever códigos de teste de unidade antes escrever o código e verificar se o código passa por todos esses testes antes de se tornar um sistema. O cliente também é envolvido nos testes funcionais, onde os mesmos devem confirmar se o sistema satisfaz as regras de negócio.
3. Escutar: refere-se à necessidade de estruturar a comunicação de modo que as conversas, sempre que possível, envolvam os problemas de hoje, não os de amanha, em um nível de detalhe apropriado.
4. Projetar: está associado a necessidade de criar uma estrutura que organiza a lógica dentro do sistema de modo a torná-lo robusto e possível de manter. Nesse contexto, a prática utilizada é projetar simples.

Práticas do XP

[BECK, 2004] lista algumas práticas que devem ser seguidas pela equipe de desenvolvimento para que os valores, princípios e atividades básicas da metodologia sejam alcançados, são elas:

1. O jogo do planejamento: determinar o escopo da próxima versão de forma que os requisitos mais importantes sejam contemplados e a entrega possa ser um praza não muito longo. Quando o planejado fugir do realizado, então o plano deve ser reajustado.
2. Entregas freqüentes: dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
3. Metáfora: conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
4. Projeto Simples: o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
5. Testes: os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
6. Refatoração: os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
7. Programação em pares: todo o desenvolvimento é realizado por programadores trabalhando em pares.
8. Propriedade coletiva: todos podem alterar o código em qualquer trecho e em qualquer momento.
9. Integração contínua: integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
10. Semana de 40 horas: como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
11. Cliente presente: mantenha o cliente o mais próximo possível para responder a questões.
12. Padrões de codificação: os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.

Referência:  BECK, Kent (2004). Programação eXtrema explicada: escolha as mudanças, Bookman, 2004.

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.