Recentemente um amigo e ex aluno Rafael Daron? me pediu indicações de User Interfaces para inspirá-lo em seu novo projeto para a nuvem, citou-me que estava observando o Windows 8 e aplicações como Prezi para ter referências. E a pergunta dele me chamou bastante atenção, e a resposta me inspirou esse post. O motivo é bem…
Olá a todos!
A Adobe lançou hoje o Adobe Mobile Challenge que te permite ganhar um bilhete para a MAX 2011!
O desafio consiste em desenvolver uma aplicação usando apenas ActionScript 3.0 ou usando a framework de Flex. Pode ser qualquer tipo de aplicação!
Coloca a aplicação nos três marketplaces (Android Marketplace, Apple Store e BlackBerry App World) antes de 1 de Setembro, e regista-te para te habilitares a ganhar o bilhete!
Para mais informação:
http://www.adobemobilechallenge.com/
Olá a todos!
Tem sido difícil arranjar tempo para escrever alguma coisa aqui para o blog. O meu tempo tem sido quase totalmente dedicado ao Adobe User Group Porto. Desde arranjar autores para escrever para o blog, a arranjar novos patrocinadores, a tentar descobrir sítios para novos eventos e manter a marca nas redes sociais, o tempo que me resta é pouco para poder dedicá-lo a outra coisa qualquer.
No entanto, venho aqui deixar uma notícia que alegra, de certeza, todos os designers, web designers, e pessoa que procuram inspiração em Portugal!
A Computer Arts Portugal nasceu!
Para quem nunca ouviu falar da Computer Arts, esta é uma revista muito conceituada no Reino Unido que nos dá a conhecer excelentes artistas e mostra-nos sempre grandes trabalhos com conteúdos de grande qualidade.
O site já está online e, em breve, a revista vai ser lançada na rua para todos comprarmos.
Podem já ver a capa aqui e ver todo o portfólio no behance:
Enfim, resta-me dar os parabéns à equipa e dar força para tudo o que possa vir aí!
PS: Aguardem, porque, em princípio, haverá notícias sobre novas parcerias do Adobe User Group Porto com estes “senhores”.
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.
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
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/
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.
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.
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 
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.
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.
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).
Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.
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 
).
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.
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.
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.
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 
Apesar de ter mais de onze meses, esta é dos melhores trinta minutos que se podem ouvir na net sobre o poder dos sites da web social (Twitter, Facebook, Digg).
Kevin Rose, co-founder do Digg, WeFollow e Revision3, fala-nos sobre o que fazer para tornar o nosso site popular e que tipo de funcionalidades são necessárias para um site que queira ter sucesso hoje em dia.
Um verdadeiro must!
Taking your Site from One to One Million Users by Kevin Rose from Carsonified on Vimeo.
Se é em 2014 não sei, mas lá que é interessante é!
Se calhar ainda vai demorar algum tempo para este tipo de tecnologia estar disponível para todos, mas entretanto sonhemos um pouco com estas possibilidades:
Há uns tempos atrás, a Adobe, no Flash Summit, convidou várias pessoas a darem uma vista de olhos ao seu Flash Player 10.1 a funcionar 100% numa Google TV e a demonstrar como será a experiência do browser (Chrome).
Fica aqui o vídeo dessa demonstração:
A Adobe e outras empresas do ramo da multimédia, plataformas web, etc. andam a tentar alcançar o novo mercado emergente das tablets desde que o novo iPad, da Apple, foi lançado para o mercado.
Se bem se lembram, antes da mediática alteração à EULA, por parte da Apple em relação ao export do Flash, a Adobe tinha-se juntado à revista Wired para lançar as suas publicações em um formato digital. Depois de muita controvérsia parecia que a discussão ia ficar por aí…
No entanto parece que o esforço está a ser feito de novo para produzir uma forma simples de exportar as revistas feitas para impressão através do InDesign directamente para um formato que possa ser interpretado tanto pelo iPad como por outras tablets que possivelmente irão correr a plataforma da Google, o Android.
Aqui fica um exemplo do que se pode conseguir com a nova ferramenta de workflow da Adobe:
O Lee Brimelow colocou um vídeo no seu blog sobre uma nova API de Flash que permite interpretar múltiplos gestos em computadores que utilizem o Windows 7. Muito interessante, uma vez que é notória a fluidez e a framerate a que corre o exemplo no vídeo seguinte:
Sequence 01 from Lee Brimelow on Vimeo.
Já faz algum tempo desde que escrevo no blog! Tenho estado com muitos problemas e a estudar não tanto a plataforma Flash mas sim arquitecturas de aplicações, modelos de programação etc.
Deixo aqui um vídeo que vi e que achei extremamente interessante sobre as novas capacidades do Flash 10.1 e a sua capacidade multitouch. Não é nada de novo, uma vez que já tínhamos visto várias bibliotecas escritas em ActionScript 3.0 para este efeito. No entanto, desta vez, o novo motor já vem inserido no player e não é necessário nada exterior às bibliotecas core.
Isto vem após uma brilhante (mais uma) infundada acusação do Steve Jobs “Flash was designed for PCs using mice, not for touch screens using fingers.”
É esta a melhor forma dos programadores de Flash defenderem a sua plataforma! Mostrando que 90% das acusações que andam a ser atribuidas à plataforma são, de facto, de pessoas que estão mal informadas.
Sim, Steve, o Flash TEM multitouch!
PepsiCo Social Media Visualization from StruckAxiom on Vimeo.
