Adobe Flex e Ajax desmistificados
Publicado; 31/03/2006 Arquivado em: Adobe, Experiência do Usuário, Flex, Tecnologia 4 ComentáriosRecentemente eu e o Beck Novaes tivemos uma troca de idéias sobre o Flex e o Ajax, ao vermos mensagens em listas de discussão, artigos e no mercado sobre um possível embate entre essas tecnologias.
Eu já havia feitos comentários sobre esse assunto (na lista CF-Brasil e na lista Flex-Brasil por exemplo), mas esse artigo apresenta de maneira mais clara e concisa as minhas idéias sobre o assunto, com o o objetivo de desmistificar a concorrência entre Adobe Flex e Ajax através de sua possível complementação para desenvolvimento da nova geração de aplicativos: rich internet applications. O Beck também postou suas considerações sobre o assunto no blog da DClick.
Cairngorm – Parte 6
Publicado; 30/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 6Essa é a sexta e última parte (parte 1, parte 2, parte 3, parte 4 e parte 5) do conjunto de artigos sobre o Cairngorm. Essa última parte apresenta um resumo sobre o funcionamento da microatquitetura proposta, bem como um interessante exemplo de implementação de uma nova funcionalidade no Cairngorm Store (o Flex Store convertido para o Cairngorm).
Novamente, reitero que é interessante ler o artigo original de Steven Webster na íntegra para um melhor entendimento. Essas sínteses apresentadas aqui no blog são apenas como referência e fazem parte de um estudo que conduzi com minha equipe atual. E nem estes devem ser considerados únicas fontes de informação de arquiteturas de aplicação – aspecto vital para um bom produto final.
Cairngorm – Parte 5
Publicado; 29/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 5Dando seqüência à quarta parte, esta quinta e penúltima discute as implementações do Service Locator e do Business Delegate. Um dos principais pontos é que cada Command é de um use case, e ainda assim pode chamar o mesmo método no servidor, o que justifica o delegate (veja mais sobre as responsabilidade de cada pattern do Cairngorm nesse post. Também é comentado sobre o desenvolvedor responsável pela integração com o server-side e o desenvolvedor do cliente.
Novamente, recomendo que o artigo original seja lido na íntegra para um melhor aproveitamento. Esse conjunto de posts é referente a um estudo realizado e não deve ser considerado única fonte de referência no assunto.
Cairngorm – Parte 4
Publicado; 28/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 4Essa é a parte 4 do artigo (que contém exemplos práticos, baseados no Cairngorn Store). Este é referente a microarquitetura Service to Worker, que envolve os design patterns Front Controller, Event Broadcaster e Command, que em conjunto integram-se com o Model Locator e o Value Object. O original em inglês está disponível aqui.
Um dos maiores paradigmas desse estilo de desenvolvimento está nesse trecho do artigo: “No more scattering of business logic across an ever-growing ecosystem of MXML components. No more monolithic classes that state ‘if the application just did this, then do that; but if it did this, then do the next thing…’”
Cairngorm – Parte 3
Publicado; 27/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 3Dando continuidade da série (parte 1, parte 2) esta terceira parte é referente à view. O original, de Steven Webster, no qual baseio esse estudo que conduzi com minha equipe, está aqui.
Os pontos mais interessante foram as best practices sugeridas, dentre elas uma que sempre sugeri: nomes semânticos para os elementos (componentes, telas e afins) – não me venha com nomes em código!; e a questão de disparar eventos, muito mais utilizado agora no Cairngorm 2 (e reformulado no Flex 2).
Cairngorm – Parte 2
Publicado; 26/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 2Na seqüência do primeiro artigo, essa segunda parte discute os desafios do desenvolvimento das RIAs, e foca no primeiro deles: manter o estado no cliente, e discute a solução desses problemas com os patterns VO (ou DTO, Data Transfer Object) e ModelLocator.
O original no qual esse estudo é baseado está disponível do Developer Center.
Cairngorm – Parte 1
Publicado; 25/03/2006 Arquivado em: Cairngorm, Flex Comentários desativados em Cairngorm – Parte 1O Cairngorm é uma micro-arquitetura de desenvolvimento para RIAs em Flex, e um projeto opensource e tem sido considerado pela comunidade uma excelente solução para os problemas recorrentes de desenho de RIAs.
Essa é a primeira parte é de um conjunto de seis posts baseados nos artigos do Steven Webster no Flex Developer Center.
Procurando orientar a comunidade sobre as melhores práticas do uso do Cairngorm, Steven Webster escreveu um conjunto de seis artigos no Flex Developer Center sobre o Cairngorm, projeto do qual ele faz parte.
Esse post é referente à primeira parte do artigo, com os principais pontos traduzidos de forma livre, a fim de conduzir a equipe com quem trabalho hoje sobre as melhores práticas de desenvolvimento de RIAs.
Ou seja, aqui estão apenas alguns dos pontos que eu anotei como sendo importantes na hora de transmitir essa informação à equipe, de modo que a leitura completa dos artigos (bem mais completo do que as sínteses que irei apresentar) é bastante proveitosa.
Um dos pontos chaves dessa primeira parte é no final, em que ele discute que o Cairngorm não é a solução de todos os problemas, embora por experiência ele tem atendido muito bem.Frequentemente me perguntam qual o melhor framework para ColdFusion: Mach II, FuseBox, ModelGlue, Tartan, etc. Não há um melhor, claro, pois cada um deles pretende resolver problemas específicos de arquitetura, desenho e eventualmente de camadas.
Frase do dia
Publicado; 24/03/2006 Arquivado em: Frase do dia 1 comentárioLive as if you will die tomorrow, and learn as if you will live for ever.
– Mahatma Gandhi
Frase do dia
Publicado; 21/03/2006 Arquivado em: Frase do dia 2 Comentários“Se eu tivesse mais tempo, eu teria escrito menos”
– Mark Twain, escrito estadunidense
Quem contou-me esta frase foi o Beck. Aliás, uma outra história que soube sobre Mark Twain é que certa vez ele recebeu um telegrama de um editor com que trabalhava:
“Preciso história curta duas páginas dois dias”
Mark Twain, que possuia o dom (até demais!) de escrever, respondeu:
“Não dá duas páginas dois dias. Faço trinta páginas dois dias. Preciso trinta dias para duas páginas”
Quebrando padrões de interação
Publicado; 18/03/2006 Arquivado em: Experiência do Usuário, Mundinho corporativo Comentários desativados em Quebrando padrões de interaçãoImagine que você é um experiente arquiteto, e está participando da construção de mais um prédio, e o seu cliente pede que o painel de “chamar” elevador no hall dos andares seja feito assim:
Você, curioso e incomodado, pergunta o porque. Ele diz que esse painel deve ser utilizado apenas em alguns andares, pois os usuários desse andares vão utilizar mais vezes a função de descer (portanto deve ser a primeira!) do que a de subir.
O prédio portanto terá os dois tipos de painel. Em alguns dos andares será o modelo padrão (incluindo o térreo, por onde todos os usuários têm de passar para entrar no prédio), com o qual todos os usuários do prédio já estão acostumados (em todos os outros prédios da cidade), e apenas em 2 andares você terá que utilizar esse modelo invertido.
Você explica que isso, embora possível, será um incômodo para a maioria dos usuários (mostrando uma pesquisa de preferência de ordem de botões em elevadores) e que ainda vai custar mais, pois a engenharia terá de trabalhar nessa peça.
O cliente mostra-se indiferente com sua opinião (o que é estranho já que ele além de sua experiência de arquiteto também está pagando por seu julgamento), e repete que o funcionamento deve ser assim para esses andares. “Não importa como funciona os outros elevedores. O funcionamento desses andares deve ser assim”.
Você diz que vai checar, já pensando em um jeito de se livrar dessa tarefa e idéia absurda, mas que não dá o seu aval para que seja feito dessa maneira, e que não assinará a obra pois não quer associar uma obra com defeitos e elementos contra seus princípios a seu nome. Afinal, você também foi pago para que o prédio não tivesse esse tipo de problema.
Sigh…
Não, eu não desenho prédios. E sim, recentente passei por um problema desses envolvendo o desenvolvimento de aplicações e desenho de interface, onde o cliente pediu insistentemente que eu quebrasse um padrão de interação (e não vem ao caso qual era).
Eu já ouvi algumas vezes a horrível frase: “Manda quem pode, obedece quem tem juízo”, o qual eu desconsidero totalmente! Se o cidadão me contratou por minha experiência em algo, o mínimo que eu posso fazer é não deixar que as coisas sejam feitas do modo errado!
Demonstrei e comprovei por “a mais b” que o que estavam me pedindo era errado como padrão de interação de interface, e que não iria deixar um membro da minha equipe implementar “aquilo” na aplicação.
O cliente não se preocupou muito com a minha argumentação e repentinamente o assunto morreu em nossa conversa. Ufa!
Bem, o recurso em questão não foi implementado, e nenhum usuário reclamou, afinal, a aplicação comporta-se como eles esperam (já que as demais com as quais eles estão acostumados funcionam do mesmo modo).
Nessa linha de recomendo o site This is Broken.