Em um dos dias do passeio, resolvi jantar com a minha esposa e um casal de amigos numa pizzaria famosa da região. A pizzaria era bem indicada, tem um website bem legal e tudo que tem direito. Com uma estrutura linda, uma faixada de dar inveja, toda em madeira, com um lugar bem estilizado e com direito a música ao vivo. Para minha surpresa, a pizza não era a das melhores. Eu até sai satisfeito, mas a minha esposa não gostou e acabou nem comendo tudo. De fato a pizza não era tão boa.

No dia seguinte, saímos novamente para comer a noite, mas dessa vez tinha que ser algo rápido, pois era necessário dormir cedo devido ao voo ser as 5 da manhã do dia seguinte. Perguntamos ao recepcionista da pousada se havia algum lugar por perto onde tinha lanche e ele nos indicou comer uma Pizza (novamente ?!?) ali bem próximo, no quarteirão seguinte. Ele também disse que os donos da pousada eram frequentadores. Depois que ele nos explicou onde ficava a pizzaria, saímos a pé mesmo pois era muito perto. Chegando em frente ao local, percebemos ser um lugar bem simples, ao ponto de nos fazer pensar se era aquele realmente o lugar que os donos da pousada frequentavam. Para ter uma idéia, nem lembro de como era a fachada/letreiro/etc. O recepcionista do hotel havia dito que esse lugar servia apenas pizzas individuais (um pouco maior que uma pizza brotinho) e confirmamos isso, tenho assim certeza que estávamos no lugar certo. Olhei o cardápio e vi que tudo era bem barato. Fizemos o pedido e aguardamos. A pizza era simplesmente muito gostosa. Muito mesmo. Em poucos lugares eu comi uma pizza tão gostosa por um preço tão barato. E olha que não é questão de custo/benefício. Se a pizza fosse mais cara que na outra pizzaria eu pagaria certamente, mesmo sendo uma pizza menor. Saímos dali muito satisfeitos e entendi o motivo que fazia os donos da pousada frequentarem aquele local. Por sinal, nem lembro o nome do lugar, mas lembro exatamente onde fica e se eu voltar algum dia a Natal certamente irei nessa pizzaria. E o que raios essa pizza tem a ver com experiência do usuário?

Essa minha passagem pelas pizzarias não foi premeditada, simplesmente aconteceu. Como cliente (ou usuário se você preferir), fiquei mais satisfeito com a pizzaria mais simples do que com a pizzaria mais bonita, requintada, que tinha website e tudo mais. E por que eu gostei da mais simples? Será que é por que eu não gosto de coisas requintadas? Claro que não. Eu gostei do lugar simples porque eles me serviram uma pizza melhor. O mais importante de uma pizzaria é a pizza ser gostosa ora bolas. Não adianta ter uma cadeira linda, usar um iPad pra fazer pedidos, guardanapo imperial e talher de outro se a pizza não for saborosa. É simples assim. E o que isso tem a ver com a nossa área?

Vamos pensar nas aplicações que fazemos no dia a dia. O Youtube, por exemplo, tem um site bem simples. Não considero o site deles uma obra de arte, muito pelo contrário. O player de vídeos deles provavelmente é um dos mais simples e feios que existem na web. Então por que será que ele é um produto de sucesso? Simples: o youtube da muita importância para o que tem realmente valor para o usuário do site deles, que é ver e compartilhar vídeos. É muito simples enviar um vídeo e mais simples ainda ver videos. Qualquer leigo consegue fazer isso. O player de vídeos deles funciona perfeitamente bem, apesar de não ter uma aparência linda. E o usuário se importa com essa aparência não muito bonita? Alguma vez você pensou em deixar de acessar o Youtube porque o site não é lá tão bonito? Acredito que não. Eu poderia citar diversos exemplos de produtos de sucesso que são extremamente simples e as vezes feios mas que são sucesso exatamente por focarem na necessidade do usuário, mas nem preciso citar porque acho que já deu pra entender onde eu quero chegar.

Parece chover no molhado, mas é impressionante o número de vezes que me pego discutindo ou observando discussões sobre se um site/aplicação precisa de borda arredondada, gradiente, se o cinza está um pouco mais claro ou escuro, ou se o botão está 1 píxel pra direita ou pra baixo, quando por vezes o que tem mais valor para o usuário nem está ótimo ainda. Não que esses detalhes não tenham importância, muito pelo contrário. O ponto aqui é que o foco deve estar primeiro no core business e depois nos acessórios. É o exemplo da pizzaria. Me lixei pra decoração linda, música ao vivo e requinte da primeira pizzaria, pois a pizza não era tão boa (se fosse certamente eu voltaria). Ao meu ver eles se preocuparam demais com coisas secundárias e esqueceram de contratar ótimos pizzaiolos. Certamente me lembrarei muito mais da segunda pizzaria, que era um lugar bem mais simples mas tinha uma deliciosa pizza.

Pra finalizar, pense um pouco sobre os motivos que fazem do iPhone um produto de sucesso. Provavelmente você perceberá que um dos menos relevantes é a sua beleza.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Indo direto ao ponto, meu primeiro projeto importante foi desenvolver junto com meu time um novo player de vídeos para a globo.com, o qual chamamos de Player 2.0. Pra mim isso era algo totalmente novo, pois meu contato com desenvolvimento Flash/ActionScript havia sido muito pouco, num projeto no início de 2009. Como a maioria já sabe, o desenvolvimento de um Player de Vídeos hoje em dia precisa necessariamente ser feito em flash, pois é o runtime que tem o maior alcance de usuários. A parte de vídeos do html5 ainda tem diversas lacunas a serem preenchidas e é necessário ainda um bom tempo para que a “massa” de usuários tenham seus browsers atualizados com suporte a essa tecnologia.

Nesse desenvolvimento do Player, pude perceber juntamente com meu time que desenvolver na plataforma do Flash já é o um grande desafio, pois a plataforma e o runtime tem alguns detalhes que você precisa entender e saber lidar, caso contrário você vai ter muita dor de cabeça.

Runtime e Sistema Operacional

Quando você desenvolve alguma coisa em Flash, especialmente um Player de Vídeos, um ponto onde é preciso tomar bastante cuidade é com o Runtime do Flash (vulgo Flash Player). O Runtime pode ter comportamentos diferentes em diferentes versões do próprio runtime e também do sistema operacional. Por algumas vezes nós passamos por situações onde percebemos que o Player não estava funcionando em uma versão específica do Runtime no Internet Explorer 6 no Windows XP. Isso causou uma certa correria, mas felizmente conseguimos resolver o problema antes de colocar no ar e não houve impacto.

Lições aprendidas e tivemos tomar algumas medidas, entre elas testar em Linux, Windows e Mac e nos principais browsers e Runtimes do Flash como parte do nosso Definition of Done (DoD). Na prática, hoje uma estória não é dada como pronta se não tivermos certeza que o que foi feito funciona nos diversos environments pré estabelecidos. No início isso era parte do DoD do Sprint, mas após passarmos por uma situação, onde achamos um problema no IE6 (pra variar) bem no último dia do sprint, e que iria colocar todo esse Sprint por água abaixo, movemos esse item do DoD do Sprint para o DoD das estórias. Acabamos resolvendo o problema sem impactar no sprint, mas o desfecho poderia ter sido outro.

Testes Automatizados

Nos tempos atuais, é quase unânime a importância de testes automatizados no desenvolvimento de software. Todo programador deveria saber os princípios de testes automatizados e aplicá-los no seu dia a dia. Infelizmente, existem alguns environments que não facilitam muito esse tipo de prática. Nesses casos, é necessário lidar com o problema de maneira pragmática, caso contrário as coisas não andam. Diferentemente de outras tecnologias, neste caso não podemos escolher alguma opção diferente, pois a opção é uma só (o Flash).

No desenvolvimento do Player, nós usamos o FlexUnit como ferramenta principal de testes automatizados. Dentro do que ele se propõe, faz seu trabalho bem feito, e facilita bastante os testes. Tem suporte a testes assíncronos, e sua documentação explica bem as principais funcionalidades.

Uma coisa que tem nos atrapalhado bastante são os frameworks de test doubles. Nenhum dos frameworks que testamos funcionou no nosso ambiente. Aqui, algo que percebemos no densenvolvimento para Flash foi que cada tutorial na internet pode funcionar numa minor/revision version do runtime e na outra aquele tutorial já não funciona. É bem complicado e custei a aceitar, mas é assim que funciona nesse environment. Ainda não descarto a possibilidade de que poderiamos insistir mais pra conseguir alguma coisa melhor, ou que não soubemos fazer direito, mas não poderiamos ficar empacados nisso, sem mover nosso projeto pra frente.

Mesmo com essas dificuldades, estamos conseguindo fazer uma quantidade boa de testes e isso tem nos ajudado muito.

Continous Integration Server

Outro desafio bem complicado que tivemos foi ter um build server funcionando bem e rodando nossos testes automatizados. Mais uma vez os tutoriais da internet acabam não funcioando direito. Pra piorar, pra você rodar testes ActionScript 3, que é a linguagem do Flash, é necessário levantar uma instância do FlashPlayer, que precisa de um Servidor X. Essa instância vezes não fecha, fica travada, ou apresenta alguns problemas que nada tem a ver com os testes da aplicação. Custamos a perceber isso, mas foi o que aconteceu.

No fim das contas, hoje temos nosso servidor de build e integração contínua funcionando bem, e com poucos problemas.

Estratégia de Migração

Fazer uma mudança no Player de Vídeos da globo.com não é uma tarefa simples. Não poderíamos simplesmente colocar um Player novo no lugar do antigo e ver o que aconteceria. Além de ser um baita risco seria uma baita irresponsabilidade. Precisavamos então pensar numa estratégia …

Antes  do momento de colocar o primeiro release no ar, decidimos usar um catálogo de vídeos com acesso bem pequeno. Para isso, criamos uma opção que ativa/desativa a versão nova em cada catálogo, individualmente. Dessa forma, poderiamos voltar para a versão antiga IMEDIATAMENTE, em caso de algum problema.

Essa estratégia foi perfeita, pois conseguimos pegar diversos pontos de melhoria, e fazer os ajustes necesários sem gerar impacto para os usuários. Com os ajustes feitos e uma nova versão no ar, resolvemos então colocar em mais um catálogo de vídeos, dessa vez um com mais acessos. Nesse momento nosso player ainda não suportava vídeos ao vivo, portanto ainda não podiamos colocar em catálogos como o do Globo News, pois caso contrário teriamos problemas. Isso provou como a nossa escolha de criar uma opcão de ir habilitando sob demanda se mostrou bastante acertada, pois assim que terminamos a funcionalidade de vídeos ao vivo, habilitamos essa nova versão do Player para o Globo News.

Hoje, estamos já com quase todos os catálogos de vídeos usando esse Novo Player. Em breve, todos os vídeos da Globo.com serão servidos por ele. Isso só não aconteceu ainda porque temos algumas estórias com alguns detalhes que tornam viável a substituição completa do Player que está no ar hoje. O mais interessante de tudo é que estamos tendo impacto e stress zero, graças e estratégia bem traçada por todo nosso time.

Conclusão

Esse começo na equipe de Webmedia está sendo ótimo. Criar um Player de Vídeos do zero tem sido uma experiência fantástica, apesar de todas as dificuldades.

Algumas das coisas mais importantes que estou tirando de lição desse projeto é que (1) nem sempre dá pra fazer tudo certinho com todos os testes automatizados, etc, etc etc, (2) as vezes estamos num vendor lock-in onde não dá pra sair e ai você tem que saber superar com os problemas do enviroment dessa tecnologia e (3) migrar uma aplicação que afeta quase todos os sites de uma empresa do tamanho da globo.com sem causar impacto em ninguém é difícil, mas não impossível.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Ruby 1.8, Ruby 1.9, Rails 2, Rails 3, cada projeto usando diversas gems. Como isolar esses ambientes para evitar conflitos?

Em Outubro de 2007, surgiu uma ferramenta chamada RVM, com o objetivo de criar ambientes isolados para desenvolver software em Ruby, permitindo que programadores pudessem usar várias versões de Ruby e Gems numa mesma máquina de forma limpa e sem conflitos. O projeto vem se tornando mais popular este ano, e de fato tem se mostrado muito útil. A lista dos autores pode ser conferida aqui.

Instalação

Para instalar o RVM, não é preciso muita coisa além de um ambiente POSIX (linux, bsd, etc). Eu instalei no meu Mac sem problemas. Eu acho que a única coisa que não vem por padrão que você precisa instalar é o git, que é usado para instalar/atualizar o RVM e instalar/atualizar as versões de Ruby.

Dito isso, abra o terminal e execute o seguinte comando:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

O procedimento não deve demorar mais que alguns minutos, dependendo da sua conexão. Em seguida, abra seu profile (.bash_profile, .profile, .bashrc, etc) e adicione as seguintes linhas:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source “$HOME/.rvm/scripts/rvm”
PS1=”\$(~/.rvm/bin/rvm-prompt) $PS1″

A segunda linha é para que a versão do Ruby que você estiver usando apareça no prompt, caso contrário você vai precisar ficar verificando a todo momento qual versão você está usando e isso pode ser bem chato.

Em seguida, carregue o rvm (da próxima vez que abrir o shell isso não será mais necessário):

$ source ~/.rvm/scripts/rvm

Pronto, o RVM está instalado e é hora de começar a arrumar nosso ambiente.

Instalando versões de Ruby

A partir do RVM, é possível instalar qualquer implementação Ruby. Por exemplo, podemos instalar o Ruby, Ruby Enterprise e o Jruby. Para uma lista completa acesse aqui.

Nesse tutorial, vamos instalar o ruby 1.8.7 . Execute o comando abaixo no terminal:

$ rvm install 1.8.7

1.8.7 é um atalho para o último patchlevel da verão 1.8.7 do Ruby. Em geral, isso funciona para todas as versões. A instalação demora um pouquinho, mas nada absurdo, portanto vá tomar um café e volte. Após o termino, “entre” no ambiente do Ruby instalado.

$ rvm –default 1.8.7

Nesse momento, você entrou no Ruby 1.8.7 e definiu essa VM como default no RVM.

Para voltar ao Ruby do systema (fora da RVM), basta ir no shell e digital:

$ rvm use system

Para listar as VMs instaladas (ou Rubies como preferem os criadores e como chamaremos a partir de agora), basta digitar:

$ rvm list

Escolha a Rubie e use-a conforme o exemplo abaixo:

$ rvm use 1.8.7

Instalando as Gems

Uma das manias que a maioria dos Rubistas tem é instalar as gems usando sudo. Isso hoje em dia é considerado má prática. Ainda mais com RVM, já que a intenção é criar uma espécie de SANDBOX por usuário/aplicação, conforme veremos a seguir.

Primeiramente vamos ver as gems que estão instaladas na nova Rubie. O comando é o já conhecido gem list. Ao rodar esse comando na Rubie instalada pelo RVM, você pode ter a impressão que suas gems sumiram, mas na verdade isso é exatamente o esperado, pois cada Rubie tem seu ambiente totalmente isolado. Para ter uma idéia, rode o seguinte comando e veja o output:

$ rvm info

O output fornece toda a informação sobre o ambiente dessa Rubie que está sendo usada no momento. Observe bem a linha home: \n gem:. Nela você verá onde estão sendo instaladas as gems. Repare que ele cria uma estrutura de diretórios sugestiva para você manter suas gems bem isoladas. A estrutura é a seguinte:

~/.rvm/gems/{Rubie@Gemset}/

Todas as gems serão instaladas nesse diretório. Não estranhe o @Gemset, falaremos dele adiante.

Vamos então instalar o Rails nessa Rubie. Não use sudo pelo amor de Deus

$ gem install rails –no-ri –no-rdoc

Depois execute um gem list para ver seu ambiente instalado. Se quiser, execute rvm system e veja que suas gems no ruby do sistema provavelmente são totalmente diferentes.

Gemsets

Vamos falar agora do tal @Gemset que eu coloquei na estrutura. Gemsets é uma forma de criar uma SANDBOX mais “profunda”. Em um primeiro momento pode parecer desnecessário, mas se você pensar que pode ter mais de um projeto por Rubie e não quer que as gems deles se misturem nem gerem algum tipo de conflito, essa estrutura passa a fazer todo sentido.

Supunha que você tenha um projeto chamado blog. Para criar uma gemset (e entrar nele) para esse projeto basta executar o seguinte comando:

$ rvm gemset create blog && rvm gemset use blog

Feito isso você verá que no seu prompt (se você fez essa configuração de instalação) estará aparecendo da seguinte forma: rubie@gemset. Rode o comando gemlist e verá que novamente suas gems que foram instaladas na Rubie sumiram. Mais uma vez isso é esperado, pois acabamos de criar uma nova SANDBOX para esse projeto específico. Nesse momento, basta instalar suas gems nessa gemset que seu projeto terá um ambiente totalmente isolado.

Se você executar o rvm info, verá que a home das suas gems está com um path diferente do anterior, pois o rvm criou um diretório para a Ruby com a nova Gemset, deixando tudo muito bem organizado.

Existem algumas gems que todos os projetos podem precisar, como Rake e Capistrano. Não seria uma boa idéia instalar essas gems em cada gemset. O RVM nos dá uma ajuda nesse sentido, criando uma gemset global, permitindo compartilhar gems entre todas as gemsets de uma Rubie. Para instalar uma gem nessa gemset basta mudar para ela e installar, como já vimos anteriormente. Vamos a um exemplo:

$ rvm gemset use global
$ gem install capistrano capistrano-ext –no-ri –no-rdoc

Pronto, essas gems não precisam mais ser instaladas para cada projeto novo que você for rodar nessa Rubie.

Conclusão

O Ruby Version Manager é uma ferramenta muito interessante para gerênciar seu ambiente Ruby. Ter vários Rubies instalado se torna cada vez mais comum, pois os projetos antigos precisam ser mantidos e novos projetos surgem, usando Rubies mais novos. O uso dos gemsets para isolar as gems também faz toda a diferença, evitando diversas dores de cabeça e deixando o ambiente organizado e limpo. Vale a pena experimentar.

<< UPDATE >>

Tem um comando importante que não abordei que é o rvm list known que mostra as opções de Rubies disponíveis para instalação. Créditos ao Rodrigo Lopes.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

É fato que nos dias de hoje muitas tecnologias novas surgiram no cenário mundial. Temos sido inundados por celulares, smartphones, notebooks, netbooks e outros mais. Hoje em dia existe internet 3G nas principais grandes cidades do mundo. Internet WIFI já é algo comum faz tempo. Esses recursos estão começando a mudar nossas vidas de uma forma surpreendente. Mas será que essa idéia é nova? Quando será que começaram as pesquisas sobre essas tecnologias? Qual será o impacto futuro em nossas vidas? Acredito que estamos realmente num caminho onde a computação fará parte de quase todos os objetos que usamos no dia a dia.

Definição

Ubíquo não é uma palavra muito usada em nosso cotidiano. Portanto, vale a pena apresentarmos alguns significados para nos ajudar a aprofundar mais no assunto.

Ubíquo significa algo universal, ou seja, algo que todos entendem, conhecem. Ubíquo também pode ser interpretado como aquilo que esta presente em todos os lugares, ao mesmo tempo. É como onipresença. Essa segunda definição tem mais a ver com o conteúdo desse artigo.

História

Em 1991, Mark Weiser escreveu um artigo chamado “O Computador do Século 21 (The Computer for the 21st Century). Weiser era cientista chefe do Centro de Pesquisa Xerox PARC. Nesse artigo, ele definiu o termo Computação Ubíqua, que define um contexto onde a presença computacional em algum objeto é totalmente transparente para quem usa e em alguns cenários totalmente invisível. Weiser também exemplifica a escrita, que foi provavelmente a primeira tecnologia de informação e que se tornou Ubíqua em países industrializados. Ele usa esse exemplo para definir que as tecnologias que são mais profundas são as aquelas que “desaparecem”. Por desaparecer, acho que Weiser quis dizer que a tecnologia fica tão arraigada no nosso dia a dia tornando seu uso automático, deixando de ser aquele algo novo e surpreendente. Vislumbrando como seria a computação do nosso século, Weiser também fala sobre redes gigabits, armazenamento de terabytes e sobre Tabs e Pads, que seriam os palms, smartphones, Kindles e iPads que temos hoje. Quase no fim do artigo, ele conta uma estória ilustrativa de uma pessoa vivendo nesse mundo todo conectado e apresenta diversos protótipos feitos por ele e sua equipe de alguns desses equipamentos e tecnologias.

No que diz respeito a tecnologias, lembro-me bem que Java era uma dessas que originalmente foi criada para ser usada em dispositivos embarcados, especialmente na informatização da casa, mas era algo muito avançado para época. Isso surgiu no mesmo ano em que Weiser escreveu seu artigo. No fim das contas a linguagem Java tomou outro rumo, muito bem sucedido por sinal.

Contexto atual e futuro

É impossível negar que a computação Ubíqua tem afetado nosso dia a dia. Hoje temos Hotspots WIFI em diversos lugares. A internet 3G está presente nos celulares modernos, possibilitando infinitas formas de comunicação. Serviços de Voz sobre IP tornaram possível usarmos ferramentas como Skype, que permite obter um número de um País e utilizar em qualquer lugar do mundo. Cada vez mais fazem parte do nosso dia a dia tecnologias como as de automóveis com computador de bordo, iPhones, iPads, totem para compra de ingressos no cinema, totem para check-in de voos, e outros mais.

Outra tecnologia que está acelerando o processo da computação Ubíqua é o Cloud Computing. Há alguns anos, milhares de pessoas tem suas contas de email online em serviços como gmail, yahoo mail e similares, de forma a não precisarem mais de um cliente de email como ferramenta obrigatória em seus computadores. Essa modalidade é conhecida como SaaS (Software as a Service). Outra modalidade é o IaaS (Infrastructure as a Service), onde existe uma infraestrutura transparente para quem contrata servidores, podendo adicionar mais recursos computacionais ao invés de mais um computador ou hardware físico. Mais recentemente surgiram também plataformas para desenvolvimento de software totalmente na web como o Google App Engine, Heroku e outros. Esse é o modelo PaaS (Platform as a Service).

Hoje em dia fala-se muito também em casas inteligentes, um conceito onde toda a casa está interligada e conectada, permitindo que luzes acendam com comando de voz, geladeiras enviem pedidos de compras ao supermercado quando estiverem perto de esvaziar, cafeteiras saberem o horário do seu café da manhã e prepararem o café sem você precisar fazer nada, e por ai vai. Esse conceito está ligado a Computação Pervasiva, que é uma espécie de subárea da Computação Ubíqua. Quem assistiu o filme “O Demolidor” (1993), com os atores Silvestre Stalone e Welsey Snipes, lembra que esses conceitos estão presentes no filme. Embora atualmente existam algumas iniciativas de empresas nesse ramo de Computação Pervasiva, essa tecnologia ainda está bem distante de uma adoção em massa.

Falando de futuro, é bem verdade que ainda não chegamos no nível onde Weiser aponta em seu artigo, mas afinal, ainda estamos no início do século, tendo passado apenas uma década. Uma das frases ditas por ele nesse artigo que chamou muito a atenção sobre esse futuro foi: “Não precisamos de nenhuma revolução na inteligência artificial, apenas incorporar a computação no cotidiano”.

Conclusão

O Caminho para Computação Ubíqua tem avançado muito nos últimos anos. As pesquisas e previsões de Mark Weiser tem se concretizado, quase que como uma profecia. Como profissionais de TI, nos resta estar atentos as oportunidades de negócio que essas tecnologias tem a nos oferecer e tirar proveito disso.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.