Fazer parsing de uma estrutura de dados como o XML é muito comum no desenvolvimento de aplicativos web, a maior parte dos sistemas desenvolvidos com o conceito de Web 2.0 implementam uma api de serviços para que o desenvolvedor possa utilizar e criar novos aplicativos, sub programas, relatórios e etc.

Estas API’s de serviços trabalham na maioria das vezes com formato de dados universais, como por ex, o JSON e XML. Portanto uma terefa comum quando estamos desenvolvendo um aplicativo “client” para estes serviços é interpretar estes dados para utilizar do modo desejado no software.

Existem diferentes modos de trabalhar com documentos XML’s e diferentes ferramentas para isso. Neste post vamos ver como isso funciona no desenvolvimento para IPhone.

Como funciona o parsing de XML?

Existem dois modos para fazer parsing de um documento XML, e muita diferença entre eles. Entender como cada modo funciona é fundamental para que esta tarefa não se torne um problema no seu projeto.

SAX ( Sequencial Access Parser )

Como o nome sugere, o parser que implementa o SAX irá fazer uma analise sequencial na estrutura do xml, o que isso quer dizer? Cada elemento do XML será analisado individualmente e em sequencia. Ele é baseado em um fluxo de eventos que são disparados para cada elemento do XML.

Exemplo

Dado o XML abaixo:

A sequência que o parser irá fazer é a seguinte:

• Começo de um novo elemento, chamado RootElement, com o atributo param = “value”
• Começo de um novo elemento, chamado FirstElement
• Um nó de texto com o data igual a “Some Text”
• Final do elemento chamado FirstElement

Quando utilizar?
Este tipo de parser é recomendado quando o tamanho do documento é muito grande ( algo em torno de 10MB ) e você pretende utilizar somente uma pequena parte do XML, pois ele não carrega o conteúdo do documento em memória ( isso acontece com os parser que implementam DOM ), porém o trabalho de desenvolvimento é maior.

DOM ( Document Object Model )
O parser que implementa o XML DOM, possibilita você acesse qualquer elemento diretamente sem a restrição de seguir uma seqüência baseado na hierarquia do XML.

Normalmente os parsers que implementam o modelo DOM também permitem que você defina a consulta no xml através de XPath. Isso torna muito mais fácil a maneira de filtrar ou agrupar os elementos do XML.

Para aqueles que estão acostumados a trabalhar com o flex, a maneira como o sdk lida com XML é através da implementação DOM, e a linguagem de busca dentro do XML é o E4X, portanto a curva de aprendizagem para aprender XPath será menor.

Para que o parser possa interpretar as consultas XPath e navegar de modo trasnversal entre os elementos para encontrar o critério de busca, o XML é carregado em memoria e transformado em uma estrutura de dados que facilita este tipo de tarefa. O ponto ruim disso é que em documentos grandes esta abordagem pode ocasionar problemas.

Exemplo

Dado o xml abaixo:

E o seguinte trecho de código:

O exemplo de código abaixo utiliza a biblioteca GDataXML para manipulação DOM do XML, está biblioteca é distribuida pela Google.

O método [doc nodesForXPath:@"//item":nil] irá percorrer todos os elementos do XML procurando pelos nós do tipo .

Quando utilizar?
O parser que implementa o XML DOM deve ser utilizado em documentos que não irão comprometer a memória ( algo menor que 10MB ), já que o gerenciamento de memoria no desenvolvimento de IPhone é um ponto que deve ser considerado. A manipulação de XML com DOM é muito mais fácil do que com SAX, uma vez que o acesso é direto.

Quais bibliotecas utilizar?

Existem várias bibliotecas que fazem parsing de XML, as mais conhecidas são:

• NSXMLParser É um SAX parser incluido por padrão no SDK do IPhone.
• libxml2 Este é um projeto Open Source que também é incluido por padrão no SDK do IPhone, ele é baseado na linguagem C, portanto é um pouco mais complicado de usar se comparado com o NSXMLParser. Esta biblioteca suporta tanto o modo SAX quanto DOM. O processamento SAX desta biblioteca é muito interessante pois permite que você faça a leitura/manipulação do XML durante o download, evitando o tempo que demoraria para baixar o documento todo.
• TBXML é um parser DOM XML muito leve desenvolvido para ser  muito rapido e consumir o minimo de memoria possível. Ele ganha tempo pois não faz validação, não da suporte ao XPath e possibilita somente acesso de leitura ao conteúdo do XML.
• TouchXML é um parser com mesmo estilo do NSMXL porem com DOM XML. Do mesmo modo que o TBXML ele permite acesso somente de leitura, entretanto possui suporte para XPath.
• KissXML muito similar ao TouchXML, inclusive foi feito com base no mesmo, entretanto possibilita edição do conteúdo do XML.
• GDataXML este parser é desenvolvido pela  Google como part de sua biblioteca Objectve-c. Ele suporta leitura e escrita , e também da suporte a XPath

Conclusão

O importante é ter em mente quais são as opções e modos de fazer o parcing do XML na sua aplicação, entender quais são as métricas que o ambiente da aplicação possui e leva-las em conta na decisão de como fazer o parsing. Estas métricas irão te encaminhar a uma das opções.

O link a seguir possui um conteudo complementar ao tema, e também apresenta uma comparação entre todas as ferramentas analisando performace e utilização de memória, vale a pena dar uma olhada: link

Referencias:

http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project
http://stackoverflow.com/questions/406811/iphone-development-xmlparser-vs-libxml2-vs-touchxml
http://www.saxproject.org/
http://en.wikipedia.org/wiki/Simple_API_for_XML
http://www.w3schools.com/Dom/dom_parser.asp
http://www.w3schools.com/XPath/default.asp

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!

Twitter!

Talvez você já tenha visto a sigla IxD e ficou sem entender do que se trata, pois bem, ela significa Interaction Design, ou Design de Interação (DxI), não gosto da sigla em português, seria o mesmo que utilizar uma sigla EU ou XU (Experiência do Usuário) para definir UX (User Experience), portanto vamos utilizar a sigla correta, IxD.

Mas afinal, o que é IxD? Design de Interação é a mesma coisa que UX? Certamente não.
Ao passo que a UX é a experiência final sentida pelo usuário, o IxD é a matéria que trabalha os melhores aspectos do desenvolvimento de uma boa UX, pois visa entender e compreender o usuário para criar os bons métodos na criação de um produto, no nosso caso, de uma aplicação usável, funcional e satisfatória.

Certamente são muitas as matérias da área de design, mas faço questão de trazer a vocês as mais significativas, as que mais estão agregando valor aos projetos voltados a aplicações, temas que de fato estão no auge e que constroem a melhor UX possível. Temas que foram ignorados a tempos e hoje se está dando o real valor pelas grandes empresas. E um desses temas certamente é IxD.

Como IxD é uma abordagem também conceitual, ainda há divergências sobre sua definição, você encontrará muitas idéias diferentes a respeito do mesmo tema, e se por um lado isso pode ser ruim por outro a discussão é boa, já que começa a definir um pouco mais algo que no meu ponto de vista sequer pode estar engessado, ficou confuso? Você vai entender.
Acredito que IxD estará sempre em mutação, e o motivo é simples, tudo está em mutação, vejamos abaixo o que é IxD.

Design de Interação, o nome praticamente diz tudo, ou não, depende muito do seu repertório. Interação para algumas pessoas pode ser a relação entre uma pessoa e outra, mas também é no caso do nosso tema a relação entre um usuário e um produto.
O que temos de interativo quando pensamos em relação a interfaces?
Games talvez seja a sua primeira opção, e é um dos melhores exemplos, foi lá que essa matéria se desenvolveu bastante, pois era necessário entender a relação entre o usuário e o game, seu grau de satisfação.
Quem é que nunca jogou um game e teve altos graus de felicidade mas também altos graus de fúria…  essa fúria (sentida pelo usuário) foi amplamente estudada e amenizada ao longo dos anos da história dos games, podemos dizer que a cada ano diminui a quantidade de gamers que destroem seus consoles, é fato. Isso porque houve o estudo da interação entre a relação do gamer com o jogo em si, para minizar a sensação de frustração e aumentar a sensação de satisfação.
Até aí simples, mas não é só o game que é interativo, existem diversas aplicações que são interativas e a cada dia mais e mais produtos estão se tornando interativos, em breve sua TV será interativa se já não for, interativa totalmente, com uso de recursos como Google TV ou Apple TV. Mas em breve sua geladeira ora tão pacata será interativa, e quem sabe até mesmo o seu sofá. Portanto, essa não é uma matéria que deve ser ignorada por um designer, e muito menos por alguém que desenvolve aplicações.

Lembra-se que falei que essa é uma matéria mutável? Porque? Porque a cada dia surgem novas mídias ou áreas físicas onde possa existir uma aplicação interativa, portanto a cada dia o IxD ganhará novo estudo conforme o próprio desenvolvimento da humanidade.

Mas o que de fato é interação nesse tema?
Entende-se interação a relação com o usuário, e que deve ser funcional a fim de proporcionar uma boa UX.

Portanto eu entendo (devido a minha experiência como designer) o IxD como principal intermediário entre a idéia (Conceito inicial do projeto) e a UX, ele é praticamente a ferramenta de trabalho que leva o conceito a realidade, fazendo a ponte desde a concepção da idéia do projeto até a sua realização e o contato com o usuário.

Um bom IxD tem por objetivo conseguir comunicar com eficácia a informação de uma aplicação até seu usuário, definindo o comportamento da aplicação, e claro, as interações que essa tem com o mesmo.

Você se recorda do texto que eu postei sobre a visão de UX de Shane Morris? (Desenvolvimento da UX)?

Vamos concluir a idéia, Morris fala que para se conseguir uma boa UX é necessário seguir 4 etapas:
1. Projeto Conceitual (aquilo que chamei nesse artigo de ‘idéia’)
2. Design de Informação  (não confundir como arquitetura da informação)
3. Design de Interação
4. Apresentação do Design (Criação do projeto em si)

Perceba que essas matérias se misturam um pouco no seu conceito mas são distintas pode acreditar, acontece que a fronteira entre uma e outra se mistura, ou seja, quando você estuda Design de informação perceberá que esse tema é parte de Design de Interação, e quando estuda Design de Interação perceberá que ele é a estrutura de desenvolvimento da UX.

Essa é uma parte que discordo do Morris, as estruturas por ele apresentadas tratam da relação de interação com o usuário, portanto é o próprio IxD.

O IxD estuda muita coisa, desde o ambiente onde a aplicação será apresentada (computador, totem, telão, se é dia, noite, espaço aberto, fechado, etc) até o tipo de usuário que estará utilizando.

Se eu fosse abordar o IxD em todo o seu aspecto seria muito mais que um post, aqui me reservo a tratar do tema naquilo que mais nos interessa, aplicações.

Vou ao melhor exemplo que conheço de IxD, o Agon.

O Agon é  uma rede social corporativa, no qual as pessoas de uma empresa fazem pontos ao compartilhar conhecimento, tal como faço nesse momento ao escrever esse post, portanto o que foi estudado para se chegar na sua criação?

Objetivo:
- Como motivar o compartilhamento de conhecimento

Estudo:
- Relação das pessoas com os games
- Relação do funcionário com a empresa e entre si
- Relação dos usuários com redes sociais
- Interatividade com a aplicação sem alterar a rotina (curva de aprendizado) dos seus participantes

A solução você já conhece, uma rede social corporativa que utiliza a rede social Twitter para alterar sua interface (através de tweets com hashtags específicas), que atingiu o seu objetivo de incentivar as pessoas a compartilhar conhecimento. (Perceba que antes do Agon eu sequer tinha postado nada nesse blog e você talvez nem soubesse o nome do atual designer da DClick).

Então é muito simples, não é somente o estudo típico de transições em uma aplicação (consistência e inconsistência), cores, tipografia, etc, ainda que isso seja parte e é muito significativo, o IxD vê a relação entre pessoa e aplicação, analisa o aspecto humano, social e histórico.

E o que seria isso? Como no caso do Agon foi avaliado a idade do usuário, quais ferramentas ele já utilizava, foi visto o que não deu certo nas corporações para estimular o compartilhamento do conhecimento, e como fazer de uma disputa algo lúdico.
Então a criação de um tipo de game foi algo natural, afinal, estamos todos acostumados a disputar nos games com nossos amigos, parentes etc e nem por isso ao término do mesmo ficamos rancorosos com os adversários virtuais (pelo menos não a maioria de nós). A relação de disputa no bom estilo dos games foi explendidamente bem aplicada no Agon, ainda com pontuações e interatividade via rede social, eu disse interatividade? Pois bem, é essa interação o estudo de IxD, prever como o usuário irá se comportar, procurando com isso atingir uma boa UX.

Então percebemos que para se saber aplicar o IxD é necessário um conhecimento vasto da área de sua atuação, da aplicação em si, o bom designer de interação é aquele que está profundamente alimentado de informações antigas (conhecimento histórico) e novas, dos diversos segmentos possíveis, ou seja, é alguém de fato muito, mas muito bem informado e com poder de comunicação. Sem isso ele não conseguirá facilmente aplicar um IxD.

Ainda que existam IxD mais modestos, ou seja, estudos mais simples, IxD é o estudo amplo e vasto de tudo que envolve a interação com o usuário por parte de uma aplicação.

O IxD acima de tudo se preocupa com o aspecto emocional de uma aplicação, se ela é útil ou inútil isso não diz nada, um game é inútil, mas tem valor emocional muito amplo, portanto Design de Interação visa entender a relação da aplicação (ou produto) na vida do usuário, como isso se reflete e repercute no dia a dia do mesmo.

Se através desse texto você se sentiu atraído a saber mais sobre esse tema pouco explorado ainda no Brasil, resta dizer que existem algumas poucas faculdades voltadas ao assunto, existindo inclusive uma pós-graduação, já no exterior diversas universidades abordam o tema, e existem mestrados inclusive. Porém lhe aconselho a visitar a associação IxDA (Interaction Design Association), da qual sou membro atualmente, uma boa oportunidade para você ficar antenado sobre o assunto.

Eu poderia colocar os passos do que é a profissão de Design de Interação, o que faz ou deixa de fazer, ou como se tornar um designer de interação e quais passos exatos tem essa matéria, existem diversos autores do assunto, mas meu objetivo aqui era passar toda a idéia conceitual  para que você se municie de informação interativa, sim, aquela que se liga a outras áreas do seu cérebro, pois garanto, que tópicos e passos determinados não serão facilmente lembrados, mas um texto que interage com demais informações, ou seja, com seu repertório, ficará enraizado e você se lembrará do que é IxD com facilidade. Portanto espero com isso ter interagido com demais conhecimentos que você possui fazendo que tenha tido uma boa UX ao término da leitura…

Até a próxima.

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Existem mais de 100 temas à escolha no WordPress.com, muitos deles com fundos, menus, layouts de conteúdo e cabeçalhos que pode personalizar a seu gosto (como o novo tema padrão Twenty Ten, por exemplo), e temos muitos mais em desenvolvimento ainda.

Pode também levar a personalização do seu site um passo mais à frente e definir totalmente o estilo de qualquer tema, alterando as fontes, cores, bordas, fundos e até mesmo o layout do site usando a opção de CSS Personalizado.

Muitos utilizadores fizeram belos sites para o seu conteúdo usando um dos nossos temas como base, juntando-lhe o seu próprio CSS .

Se não sabe por onde começar com o CSS (que necessita um pouco de experiência com HTML e vontade de aprender, é verdade), visite os links para a ajuda com CSS na página de suporte respectiva, que o levarão a tutoriais e explicações na web. Se tem um amigo que é bom em CSS, pode ser que seja um bom momento para lhe oferecer uma pizza e pedir uma lição!

Tal como acontece com todas as opções pagas do WordPress.com (excepto o registo de domínio), pode experimentar CSS Personalizado gratuitamente durante 30 dias e cancelar se não gostar.

Aqui estão alguns sites em WordPress.com que usam CSS Personalizado e que chamaram a nossa atenção:

Whole Lotta Lovely

 

Visite: http://wholelottalovely.wordpress.com/

Rafael Alburquerque, Vice-President da República Dominicana

 

Visite: http://rafaelalburquerque.com/

Kiss My Spatula

 

Visite: http://kissmyspatula.com

Things We Make

 

Visite: http://thingswemake.wordpress.com/

Fig & Fennel

 

Visite: http://figandfennel.wordpress.com/

Journey Photographic

 

Visite: http://journeyphotographic.com/

Foody Two Shoes

 

Visite: http://foodytwoshoes.com/

Adoramos ver a sua obra de arte em WordPress.com!

Algo legal no Flex é que eles nos disponibiliza gráficos, porém, sinceramente o estilo padrão dos gráficos com cores sólidas não me agrada muito, ao meu ver cansa os olhos, então resolvi mudar as cores solidas para um padrão em degrade, para suavizar as cores…

 

Obs.: tendo em mente que os componentes dos gráficos ainda são os mesmos no Flex 3 e 4 os códigos mxml a seguir serão do Flex 3.

 

Começando pelo gráfico de barras, para ter o seguinte resultado precisei:

Código MXML:

^?View Code ACTIONSCRIPT3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" verticalAlign="middle" backgroundColor="white">   <mx:Script> <![CDATA[ import code.StyleColumnChart;   import mx.charts.chartClasses.IAxis;   private function linearAxis_labelFunc(item:Object, prevValue:Object, axis:IAxis):String { return currencyFormatter.format(item); }   private function categoryAxis_labelFunc(item:Object, prevValue:Object, axis:CategoryAxis, categoryItem:Object):String { var datNum:Number = Date.parse(item); var tempDate:Date = new Date(datNum); return dateFormatter.format(tempDate).toUpperCase(); } ]]> </mx:Script>   <mx:DateFormatter id="dateFormatter" formatString="DD" /> <mx:CurrencyFormatter id="currencyFormatter" precision="2" />   <mx:XMLListCollection id="dp"> <mx:source> <mx:XMLList> <quote date="8/1/2007" open="40.29" close="39.58" /> <quote date="8/2/2007" open="39.4" close="39.52" /> <quote date="8/3/2007" open="39.47" close="38.75" /> <quote date="8/6/2007" open="38.71" close="39.38" /> <quote date="8/7/2007" open="39.08" close="39.42" /> <quote date="8/8/2007" open="39.61" close="40.23" /> <quote date="8/9/2007" open="39.9" close="40.75" /> <quote date="8/10/2007" open="41.3" close="41.06" /> <quote date="8/13/2007" open="41" close="40.83" /> <quote date="8/14/2007" open="41.01" close="40.41" /> <quote date="8/15/2007" open="40.22" close="40.18" /> <quote date="8/16/2007" open="39.83" close="39.96" /> <quote date="8/17/2007" open="40.18" close="40.32" /> <quote date="8/20/2007" open="40.55" close="40.74" /> <quote date="8/21/2007" open="40.41" close="40.13" /> <quote date="8/22/2007" open="40.4" close="40.77" /> <quote date="8/23/2007" open="40.82" close="40.6" /> <quote date="8/24/2007" open="40.5" close="40.41" /> <quote date="8/27/2007" open="40.38" close="40.81" /> </mx:XMLList> </mx:source> </mx:XMLListCollection>   <mx:ColumnChart id="columnChart" showDataTips="true" dataProvider="{dp}" width="100%" height="100%">   <!-- vertical axis --> <mx:verticalAxis> <mx:LinearAxis baseAtZero="false" labelFunction="linearAxis_labelFunc" /> </mx:verticalAxis>   <!-- horizontal axis --> <mx:horizontalAxis> <mx:CategoryAxis id="ca" categoryField="@date" title="August 2007" labelFunction="categoryAxis_labelFunc" /> </mx:horizontalAxis>   <!-- horizontal axis renderer --> <mx:horizontalAxisRenderers> <mx:AxisRenderer axis="{ca}" canDropLabels="true" /> </mx:horizontalAxisRenderers>   <!-- series --> <mx:series> <mx:ColumnSeries displayName="Open" xField="@date" yField="@open" fill="{StyleColumnChart.orangeLinearGradient}" stroke="{StyleColumnChart.orangeStroke}"> </mx:ColumnSeries> <mx:ColumnSeries displayName="Close" xField="@date" yField="@close" fill="{StyleColumnChart.blueLinearGradient}" stroke="{StyleColumnChart.blueStroke}"> </mx:ColumnSeries> </mx:series>   <!-- series filters --> <mx:seriesFilters> <mx:Array /> </mx:seriesFilters> </mx:ColumnChart> </mx:Application>

Obs.: esse código acima reaproveitei do respectivo post do blog.flexexamples.com

Código da classe AS3 para gerar o efeito visual:

^?View Code ACTIONSCRIPT3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75

package code { import mx.graphics.GradientEntry; import mx.graphics.LinearGradient; import mx.graphics.Stroke;   [Bindable] public class StyleColumnChart { public function StyleColumnChart() {}   //---------------------------------------------------------------------- // @BEGIN: LinearGradient color   public static function linearGradientColor(colorDark:uint, colorLight:uint):LinearGradient { var linearGradient:LinearGradient = new LinearGradient(); var arr:Array = []; arr.push(new GradientEntry(colorDark, 0.0, 0.8)); arr.push(new GradientEntry(colorLight, 1.0, 0.6)); linearGradient.entries = arr; return linearGradient; }   public static function get redLinearGradient():LinearGradient { return linearGradientColor(0x990000,0xEE0000); }   public static function get greenLinearGradient():LinearGradient { return linearGradientColor(0x008B00,0x00FF00); }   public static function get blueLinearGradient():LinearGradient { return linearGradientColor(0x0066FF,0x00CCFF); }   public static function get yellowLinearGradient():LinearGradient { return linearGradientColor(0xCAC333, 0xF5F30E); }   public static function get orangeLinearGradient():LinearGradient { return linearGradientColor(0xFC9C00, 0xFCC048); }   // @END: LinearGradient color //---------------------------------------------------------------------- // @BEGIN: stroke color   public static function strokeColor(color:uint):Stroke { return new Stroke(color,1); }   public static function get redStroke():Stroke { return strokeColor(0x990000); }   public static function get greenStroke():Stroke { return strokeColor(0x008B00); }   public static function get blueStroke():Stroke { return strokeColor(0x0066FF); }   public static function get yellowStroke():Stroke { return strokeColor(0xCAC333); }   public static function get orangeStroke():Stroke { return strokeColor(0xFC9C00); }   // @END: stroke color //---------------------------------------------------------------------- } }

A seguir segue um exemplo para gráfico de pizza:

Código MXML:

^?View Code ACTIONSCRIPT3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

<?xml version="1.0"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"> <mx:Script> <![CDATA[ import mx.collections.ArrayCollection;   import code.StylePieChart;   [Bindable] public var expenses:ArrayCollection = new ArrayCollection([ {Data:"IN", Value:2000}, {Data:"OUT", Value:1000} ]);   ]]> </mx:Script>   <mx:Panel title="Pie Chart">   <mx:PieChart id="myChart" dataProvider="{expenses}" showDataTips="true"> <mx:series> <mx:PieSeries field="Value" nameField="Data" labelPosition="callout" fills="{StylePieChart.inOutFills}"/> </mx:series> </mx:PieChart>   <mx:Legend dataProvider="{myChart}"/>   </mx:Panel>   </mx:Application>

Código da classe AS3 para gerar o efeito visual:

^?View Code ACTIONSCRIPT3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

package code { import mx.graphics.GradientEntry; import mx.graphics.RadialGradient; import mx.graphics.SolidColor;   [Bindable] public class StylePieChart { public function StylePieChart() {}   //----------------------------------------------------------------------   public static function get inOutFills():Array { var gradients:Array = new Array();   var fill:RadialGradient = null; var g1:GradientEntry = null; var g2:GradientEntry = null;   fill = new RadialGradient(); g1 = new GradientEntry(0xCC3640); g2 = new GradientEntry(0x990000); fill.entries = [g1,g2]; gradients.splice(-1,0,fill);   fill = new RadialGradient(); g1 = new GradientEntry(0x30BB32); g2 = new GradientEntry(0x009900); fill.entries = [g1,g2]; gradients.splice(-1,0,fill);   return gradients; }   //---------------------------------------------------------------------- } }

Para achar as cores utilizei os itens descritos neste post: [Adobe AIR] Color Browser

Veja também:

• [Flex & AIR] Swiz Framework – meus primeiros passos
• Java Magazine 68 : Artigo sobre Adobe Flex e AIR
• s:TextArea – recuperando um texto selecionado
• [Flex & AIR] Swiz Framework + Presentation Model : Exemplo de Projeto
• FlexMania 2010 – Adobe Flex + Oracle WebLogic 10.x

Twitter!

Abaixo seguem os piores mitos sobre User Experience mais populares que separamos para comentá-los.

Você talvez se pergunte a respeito de alguns deles questionando o fato de serem mitos, acontece que os mesmos são frases ditas pelas pessoas dos 3 segmentos abaixo e que representam um grau de importância significativo para a User Experience, por isso consideramos como mitos de UX.

- Mitos entre os Desenvolvedores

#1  O cliente não repara se o campo está  1px para a direita ou se está muito amarelo, o cliente quer saber se o aplicativo funciona.

Comentário:
Iniciamos com um dos mais clássicos mitos, o desalinhamento, o campo, box, imagem, ou outro objeto que está desalinhado ou mesmo em cor diferente dos demais objetos da “cena”.
É fato, como comentado no texto sobre UX (What the Hell is UX?) o ser humano gosta do belo, e gosta do simétrico.
Você certamente nunca se perguntou porque uma pessoa é bonita, e porque há gostos diferentes. Mas algo é importante comentar, uma pessoa bonita é algo inquestionável, ela pode não ser atrativa para você, ela pode não ter nenhuma característica que você ache interessante, mas você não pode negar que aquela pessoa é ou não é bonita. Mas afinal, o que torna uma pessoa bonita? São as proporções e a simetria, existem gordos bonitos, magros, altos, baixos, das diversas cores, então não se trata puramente de gosto, e sim de algo a mais que existe ali, e isso é exatamente o simétrico e o proporcional.
Simetria, é tudo aquilo que é igual de ambos os lados, um rosto simétrico bem conhecido, Tom Cruise, ele vai ficar velho, e cada vez mais velho, mas vai continuar (acredita-se se nada lhe acontecer) simétrico, e continuará a ser o galã dos cinemas. A culpa é só da simetria? Não, ele também é proporcional, de nada adiantaria ele ter simetria se fosse barrigudo e tivesse as pernas finas, ele é esteticamente proporcional, isso lhe daria o status de beleza mesmo se ele não fosse famoso, afinal fama é outra história.
O que estamos dizendo com isso é que a simetria e a proporção são importantes, você não se interessaria (talvez não) por alguém cujo nariz estivesse uns pixels a direita, e que tivesse um olho com a cor diferente do outro…  certamente não, e se lhe interessar alguém assim com certeza serão outros fatores que não somente os já citados.
As primeiras coisas que são observadas por nós seres humanos é a simetria e proporção, as demais qualidades são observadas depois.

Mas e quando falamos em aplicativos? A princípio só lhe resta simetria,  proporção,constraste e cores, o aplicativo pode ser bonito, pode ser funcional, pode ser fantástico, mas se tiver campos desalinhados certamente  não irá agradar, e não pense que o usuário irá saber o que lhe incomoda, ou mesmo seu cliente, ele não vai saber, ele só vai olhar e dizer… “Hummmm, não sei… algo não está legal.”

E logo mais começam as alterações, e tudo isso porque você desenvolvedor muitas vezes não se preocupou com o pixel de diferença ou mesmo com uma cor, tudo porque pensou que poderia acertar depois.

#2 Não faz diferença se o canto é arredondado ou se não é, ninguém vai reparar nisto.

Comentário:
Será mesmo? Mas é claro que não, cantos arrendados tem os seus motivos, e os cantos duros também.
Se a aplicação possui uma identidade visual arredondada, certamente os campos, boxes ou imagens que tiverem cantos duros vão se sobressair de todo o resto, as vezes será bom e as vezes não. E isso deve ser feito de forma consciente e não desproposital.

#3 A aplicação está lenta mas está funcionando, é isso que importa.

Comentário:
Realmente, importa que esteja funcionando, mas e a experiência será boa? Quem de nós gosta de esperar? Quem de nós está disposto a aguardar um carregamento?
Muitas vezes a demora de uma aplicação não está associada ao tipo de linguagem usada, servidor, vídeos etc, muitas vezes é o próprio código que tem um algorítimo não muito inteligente, fazendo que haja demora na resposta de uma determinada requisição.
Certamente não importando de onde vem a demora, ela oferece uma péssima experiência a qualquer usuário, e muitos de nós (como usuários) por vezes fechamos uma aplicação e desistimos por conta da impaciência.

.

- Mitos entre os Designers

#4 O Cliente deve ser ouvido

Comentário:
Ele deve, sim deve, mas não é ao pé da letra. O cliente não é responsável por saber do seu próprio problema, e na maioria das vezes ele não sabe. Acredite, o cliente vem até nós para procurar uma solução de um problema, mas se você estudar o seu cliente por vezes vai encontrar que o problema demonstrado por ele não é exatamente um problema, e que o que realmente está causando transtorno é outra coisa, portanto ouça o cliente, mas tente entender toda a mecânica do processo do projeto para que descubra o real problema e possa oferecer uma boa solução.

#5 O Cliente é quem define as cores

Comentário:

O cliente não pode definir por exemplo como cores devem ser aplicadas, ele pode sim oferecer uma paleta de cores que corresponde a uma identidade visual da empresa, mas definir onde essas cores serão aplicadas é algo para um profissional que estudou semiótica, teoria das cores e afins…  que sabe como e porque aplicar determinada cor e que resultado isso irá trazer.
Portanto é obrigação do designer conversar com o cliente e demonstrar o que é melhor e mais viável para determinado tipo de aplicação e interação com o usuário.

#6 O usuário deve ser ouvido

Comentário:
Não, esse é o último que deve ser ouvido, se ele for ouvido você realmente irá criar um monstro. Existem técnicas para se ouvir um usuário e é através de feedback de algo já realizado, mas nunca antes do layout estar feito, você deve sondar gostos, estilos e tudo o mais para o público que irá utilizar a aplicação mas nunca chegar em um usuário e perguntar “qual cor acha que deveria ser a aplicação?” ele lhe dirá uma, e certamente outro usuário lhe dirá outra, e gosto pessoal de cor não é sequer a cor que ele de fato gostaria de ver na aplicação.
Estou dando o exemplo de cor pois é o mais fácil de ser entendido mas você pode imaginar um usuário pedindo que seja inserido milhares de ferramentas, no qual talvez um dia, quem sabe, sejam utilizadas…

#7 O layout é que faz vender o produto

Comentário:
Mito, é claro que é mito, o layout é que faz vender o projeto muitas vezes mas não o produto, ninguém compra um aplicativo unicamente porque seu layout é bonito, ele ajuda e muito a fazer a publicidade de um produto, ele faz parte do conjunto. Mas não se deixe enganar por designers que se auto valorizam ao extremo dizendo que tal e tal aplicação só vendeu por conta do design. Isso não acontece, o design ajuda, ele faz parte da Experiência do Usuário, mas não é por si só toda a experiência, não sendo portanto unicamente o responsável pela venda de um produto, é sim, o carro chefe, o cartão de visitas, mas não pode se atribuir toda a glória a ele.
.

- Mitos entre os Arquitetos de Informação

#8 Site acessível tem que ser “feio”

Comentário:

É comum, mais do que deveria, vermos arquitetos de informação dizer que site acessível e funcional geralmente é feio, porque é difícil adequar funcionalidade com beleza, que ter um site funcional é mais importante que ter um site bonitinho, é verdade, mas é mito achar que beleza e funcionalidade não possam andarem juntas.

#9 Todas as páginas devem ser acessíveis em 3 Cliques

Comentário:
Esse é sem dúvida o maior mito entre os arquitetos, há discussões, brigas absurdas entre arquitetos e designers por conta desse tema. 3 cliques é bom, mas não pode ser a regra, 3 cliques para se chegar a qualquer lugar em uma aplicação é importante, mas nem sempre deve ser assim, a Amazon que o diga, com uma interface wizard para as compras, bem como outros e-commerces, porque deve então haver imposição em todas as demais aplicações com sistema em Hub?
Todas as páginas no sistema em Hub deve ser acessada em 3 cliques? Infelizmente isso as vezes causa é uma experiência ruim, uma determinada informação que poderia estar separada em uma outra página está jogada nas mesma página juntamente com outra que não lhe tem qualquer parentesco somente porque o arquiteto queria ter 3 cliques.
É importante organizar a informação o máximo possível, sem se prender a esse tipo de mito, a informação deve estar associada a seus parentes, a sua hierarquia, entre outras técnicas da arquitetura de informação, mas se você se limitar as regras sem pensar no benefício do usuário, sem pensar na experiência que ele vai ter, certamente você não estará fazendo da arquitetura uma parte do processo de UX.

#10 Seu usuário é como você

Comentário:
E deixamos o melhor mito para o final, seu usuário é como você.
Esse mito é mais comum entre os arquitetos, mas é também bastante difundido entre os designers.. Todos querem impor seus gostos na hora de fazer uma aplicação, achando que se é bom para mim então será bom para o usuário… Esse é o pior erro que alguém que está em um projeto de uma aplicação pode cometer, você deve pensar no usuário de forma diferente, você deve se imaginar como ele, mas não pensar que ele deve ser como você.
Criar uma aplicação para o segmento infantil é um bom exemplo, você não é criança, mas consegue imaginar o que agrada uma criança, consegue através de pesquisas e pela sua própria experiência que teve pois um dia já foi uma, enfim, há sem dúvida inúmeras formas para você se colocar na posição do usuário, mas nunca, nunca mesmo coloque o usuário na sua posição, acreditando que ele gosta das mesmas coisas que você.

Por fim, como conclusão desses mitos, não se iluda, se um número X de pessoas viu a sua aplicação e não tiveram uma boa experiência, não pense que elas estão erradas e você é que está certo, se aquelas pessoas são do mesmo segmento que seu público, então algo está errado na sua aplicação, não insista no erro, se preciso, jogue tudo fora e volte a “ponta do lápis”, não se satisfaça com o bom se você pode ter o ótimo.

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Ferramenta de diagramação bem legal. Cheguei nessa ferramenta quando estava pesquisando sobre a lib ObjectHandles (provável que escreva um post futuramente sobre). Acabei testando e gostei.

O SimpleDiagrams, é uma ferramenta para desenhar (como o nome ja diz, diagramas) o que gostei foi esse formato onde parece que você está desenhando sua idéia em um quadro negro, apesar de que a ferramenta te disponibiliza + 2 outros estilos visuais.

Bom caso você conheça o Balsamiq, que também é uma ferramenta de diagramas, e pense que ambas são parecidas, já lhe adiando que o foco de ambas são diferentes, o Balsamiq foca em prototipação de interface. Já o SimpleDiagrams foca em desenho/rascunho de idéias.

Características:

• Drag, drop e redimencionar os símbolos das respectivas bibliotedas definidas no menu a direita. Outro ponto legal, a ferramenta possui mais bibliotecas que podem ser adicionadas.
• Adicionar fotos e anotações
• Vários estilos de funto
• Salvar o diagrama no seu computador
• Exportar para PNG

Preço:

- Versão completa U$ 19,00

- Porém existe uma versão gratúita, com algumas restrições

- Existe também uma opção de compra de uma versão para uso online (web)

Veja também:

• Adobe AIR e SQLite
• GAT-X105 Strike Gundam desenhado no MS Excel
• Tuberadio.fm : ferramenta para localizar música no Youtube
• Colabo – Ferramenta colaborativa

Twitter!

Objetivo:

Olá pessoal, neste poste eu pretendo falar um pouco mais sobre o Spring Roo e como criar um modelo de entidades complexo.
Pretendo falar da configurar o banco de dados até a criação de relacionamentos, também vou explicar
cada um dos comando utilizado na criação de entidades e configuração de banco de dados.

Abaixo segue uma lista dos principais comando, e seus parâmetros, utilizados na criação de entidades pelo Spring Roo. Procurei colocar todos os parâmetros de cada comando, mas como alguns parâmetros são utilizados em vários comandos vou colocar a descrição deles apenas uma vez.

Persistence setup:

–provider: Utilizado para configurar o provaider do JPA, os possíveis valores para esse parâmetro são:
Hibernate,
EclipseLink,
OpenJPA
DataNucleus

–database: Utilizado para configurar qual o bando de dados será utilizado na aplicação, os possíveis valores são:
HSQL(em memória),
HSQL,
H2(em memória),
MySql,
Postgres,
MS SQL Server,
Sysbase,
Oracle,
DB2,
Google App Engine,
Derby

–applicationId: Identificador de aplicativo do Google App
–databaseName: Utilizado para configurar o nome do banco de
–jndiDataSource: Utilizado para referênciar um DataSource configurado na árvore
–password: Utilizado para configurar a senha do usuário do banco de dados
–userName: Utilizado parar configurar o usuário do banco de dados

Os parâmetros (databaseName, password, userName) podem ser configurados diretamente no arquivo “database.properties”.
Este arquivo se encontra em src/main/resources/META-INF/spring/database.properties.
O comando persistence setup pode ser utilizado mais de uma vez. Você pode, por exemplo, utilizar HSQL e Hibernate em desenvolvimento e depois trocar para Oracle
e EclipseLink quando for colocar em produção.

Resumo:
Quando rodamos o comando “persistence setup” o Spring Roo se encarrega das seguintes configurações
1 – Configuração de dependência de JPA, ORM provaider, Drivers, Spring ORM, Spring JDBC, Commons DBCP, Commons Pool no arquivo pom.xml
2 – Configuração do arquivo “persistence.xml”
3 – Arquivo de configuração para o banco de dados “database.properties”
4 – Configuração de DataSource e Transação no arquivo de configuração do Spring

Entity:

–class: Nome da classe
–abstract: Configura a entidade como abstrata
–extends: Identifica qual classe a entidade extende
–identifierColumn: Nome da coluna que é a chave primário da tabela
–identifierField: Nome do field que será mapeado para o campo de chave primária da tabela
–identifierType: Tipo do field que será utilizado como chave primária
–inheritanceType: Utilizado para configurar a annotation “@Inheritance”
–mappedSuperclass: Indica se a entidade deve ter a annotation “@MappedSuperclass”
–permitReservedWords: Indica se o Roo deve ignorar palavras reservadas
–serializable: Indica se a entidade deve implementar a interface “java.io.Serializable;”
–table: Nome da tabela que será mapeada pela Entidade.
–testAutomatically: Indica se deve ser criado testes unitários para a Entidade

field boolean:

–fieldName: Nome do field
–class: Classe onde o field será criado
–assertFalse: Configura o field com o annotation “@AssertFalse” da especificação Bean Validation
–assertTrue: Configura o field com o annotation “@AssertTrue” da especificação Bean Validation
–class: Nome da entidade onde o field vai ser criado.
–column: Nome da coluna da tabela do banco de dados
–comment: Comentário
–notNull: Não permite valor null
–nullRequired: Configura o field para ser null.
–permitReservedWords: Permite utilizar palavras reservadas no nome dos fields
–primitive: Indica se o typo do field vai ser “boolean” ou “”Boolean
–transient:

field date

–fieldName:
–class:
–type: Configura o tipo do field Date ou Calendar;
–column:
–comment:
–dateFormat: Indica o estilo de formatação da data;
–future: Indica que a data deve ser sempre no futuro
–notNull:
–nullRequired:
–past: Indica que a data deve ser sempre no passado
–permitReservedWords:
–persistenceType: Configura como a data vai ser salva no banco de dados (DATE, TIME, TIMESTANP)
–timeFormat: Configura o tipo de formatação do field
–transient:

field enum:

–fieldName:
–class:
–type:
–column:
–comment:
–enumType: Indica como o field será persistido no banco (ORDINAL, STRING)
–notNull:
–nullRequired:
–permitReservedWords:
–transient:

field number

–fieldName:
–class:
–type:
–column:
–comment:
–decimalMax: Valor máximo
–decimalMin: Valor máximo
–digitsFraction: Quantidade máxima de números depois da virgula
–digitsInteger: Quantidade máxima de dígitos inteiros
–max: Valor máximo
–min: Valor minimo
–notNull:
–nullRequired:
–permitReservedWords:
–primitive: Indica que o field deve ser primitivo
–transient:

field reference:

–fieldName:
–class:
–type:
–comment:
–cardinality:Cardinalidade do relacionamento, default MANY_TO_ONE
–fetch: Configuracao de fetch (EAGER, LAZY)
–joinColumnName: Nome da coluna que será utilizada no relacionamento
–notNull:
–nullRequired:
–permitReservedWords:
–transient:

field set:

–fieldName:
–class:
–element: Tipo da entidade do relacionamento
–cardinality:Cardinalidade do relacionamento, default MANY_TO_MANY
–comment:
–fetch:
–mappedBy: Nome do field na entidade de referência que é dono do relacionamento
–notNull:
–nullRequired:
–permitReservedWords
–sizeMax: Numero máximo de elementos que pode existir no relacionamento
–sizeMin: Número mínimo de elementos que pode existir no relacionamento
–transient:

field string:

–fieldName:
–class:
–column:
–comment:
–decimalMax:
–decimalMin:
–notNull:
–nullRequired:
–permitReservedWords:
–regexp: Obriga o valor do field ser compatível com a expressão regular
–sizeMax: Tamanho máximo da string
–sizeMin: Tamanho mínimo da string
–transient

Segue também um screencast com exemplos de criação de entidades.

Twitter!

Boas práticas e testes no nosso dia-a-dia de desenvolvimento

Testes unitários já foram vistos com maus olhos pela comunidade de desenvolvimento de software quando surgiram, e hoje em dia é uma das práticas obrigatórias no desenvolvimento da maioria dos sistemas. Mas afinal o que fez todo mundo mudar a maneira de pensar e trabalhar? O que motiva um desenvolvedor a “perder tempo” escrevendo testes unitários?

As respostas hoje em dia são bem claras na cabeça de muitos desenvolvedores, por isso vamos passar por temas que vão além dos testes unitários e abordar como nos beneficiamos a longo prazo com uma política de testes e boas práticas bem definida.

Testando sempre, corrigindo sempre

Já que todos concordam (a grande maioria pelo menos) que testes nos beneficiam, porque não testar em todo o processo de desenvolvimento? Uma dúvida que surge assim que a equipe resolve testar suas classes: devemos estimar também o tempo que levaremos para escrever os testes? A resposta é simples, sim e não. Sim porque com certeza o tempo para executar a tarefa será diferente quando resolvemos escrever testes para nossas classes, e não porque não devemos separar a estimativa, como se escrever testes fossem uma tarefa diferente. Inclusive deveríamos considerar que uma tarefa só é concluída se existem testes unitários que garantem o funcionamento da mesma, e que tais testes estejam passando.

Podemos pensar que se para cada funcionalidade que implementamos garantimos o funcionamento da mesma, estamos seguros para implementar uma nova funcionalidade sem interferir no progresso do sistema até então. A única maneira de garantirmos que toda funcionalidade nova estará de acordo com as já existentes é testando ao longo de todo o projeto. O mesmo vale para testes de uso, feitos por uma equipe de testes, pois se pensarmos que os testes unitários nos protegem de nossos próprios erros, ainda assim não estamos protegidos de erros de sistemas externos que serão usados par integração com o nosso projeto.

O fator mais crítico em se testar sempre, é que quando nos deparamos com um determinado erro, nossa cabeça ainda está no contexto da tarefa ao qual o teste falhou, e portanto está mais claro em nossas mentes como corrigi-la, acelerando a correção de erros e o desenvolvimento de novas tarefas mais futuramente.

Relatórios de Cobertura

Os relatórios de cobertura de testes a primeira vista parecem um ferramenta de controle sobre como estamos desenvolvendo. Muito pelo contrário, porque os relatórios de cobertura apenas expoem as linhas e blocos do código que são executados durante os testes, escondendo muitos outros fatores relevantes no desenvolvimento, além do que é bem fácil “roubar” no teste para obter uma cobertura alta.

O relatório de cobertura serve como ferramenta de alerta para a equipe como um todo, para que a qualquer momento, qualquer membro da equipe possa consultar o relatório e se certificar que dado a cobertura de testes, ele pode continuar o desenvolvimento de suas tarefas ou então, notificar toda a equipe que existem partes do código não testadas e que devem receber mais atenção para garantir uma evolução contínua do sistema.

FindBugs e PMD

O FindBugs é uma ferramenta que nos auxilia no desenvolvimento prevendo possíveis pontos problemáticos do sistema. O FindBugs funciona com o Java mas existem versões para diversas plataformas.

No mesmo espírito do relatório de cobertura, os possíveis bugs apontados pelo FindBugs servem como alerta para a equipe para pontos do sistema que talvez mereçam mais atenção, e da mesma forma é possível “roubar” e sempre deixar o FindBugs “contente”, por isso é essencial a consciência da equipe para manter o FindBugs dentro da linha.

O relatório gerado pelo PMD é mais um guia de boas práticas que deveriam ser seguidas durante a implementação do código. O PMD é bem menos intrusivo que o FindBugs no sentido de que a análise feita por ele é mais voltada a estilo de programação, e pode ser configurada e ajustada de acordo com o projeto e a equipe. O ideal seria que conseguíssemos estabelecer uma configuração do PMD e do FindBugs para a DClick, garantindo que se mudarmos algum desenvolvedor de equipe, o desenvolvedor iria estar familiarizado com as práticas e padrões do novo projeto, afinal seriam os mesmos padrões exigidos no projeto em que o desenvolvedor estava.

Site do FindBugs

Site do PMD

Checkstyle

Um dos principais objetivos de se empregar boas práticas de programação, é garantir uma linguagem comum entre equipes de desenvolvimento. Para facilitar tal compreensão, seria interessante que o código implementado independente da equipe, seguisse uma mesma identação e organização. Dessa forma um desenvolvedor novo no projeto consegueria “se encontrar” no código de maneira mais rápida, porque a estrutura adotada seria a mesma em todos os projetos.

Para facilitar e garantir que o padrão está sendo seguido, existe por exemplo, o plugin de ‘checkstyle’ do eclipse. O plugin nada mais faz do que colocar warnings no código, nos trechos em que o padrão de identação e organização definido não está sendo seguido. O plugin consegue ir um pouco mais longe do que meramente validar formatação de código, e consegue “cobrar” o emprego de algumas boas práticas mais básicas, como por exemplo encapsulamento e gerenciamento de variáveis.

Site Oficial do Checkstyle

Documentação

Se escrever código de maneira padronizada, organizada e compreensível é essencial para comunicação, o mesmo se aplica para a documentação das classes.

Por isso que existem ferramentas como o javadoc, que é uma das ferramentas mais difundidas na comunidade. Isso porque garante a geração de uma documentação livre de código de maneira automática e simples. O que deveríamos ter em nossas classes, é uma documentação na qual não seja necessário ler o código para entender o funcionamento da classe. A única maneira de garantir um nível de documentação desses, é sempre manter a documentação atualizada e constantemente mudá-la conforme desenvolvemos o sistema.

No Java existe o Javadoc que é tão difundido que já vem integrado com o Eclipse IDE, e existem versões disponíveis para todas as grandes plataformas, inclusive Flex.

De modo geral

Apesar de citar algumas tecnologias usadas no Java, o objetivo principal do post é mostrar que o emprego de tais ferramentas nos ajuda no dia-a-dia de desenvolvimento em geral, não importando a tecnologia utilizada. A idéia é atingir um nível de qualidade geral, independente de plataforma. Se atingirmos um nível aceitável e conseguirmos seguir um padrão, conseguiremos migrar entre projetos tendo que apenas entender a regra de negócio do projeto, já estando familiarizado com as práticas de desenvolvimento.