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.

É 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.

Como já mencionei em outros posts nesse mesmo blog, nossa área de desenvolvimento de software/informática está cheia de termos/nomenclatura que se confundem facilmente (e.g. as discussões no GUJ sobre DTO). Mais uma vez, falarei sobre um deles: a classificação júnior, pleno, sênior.

Dando uma passeada pelos sites de emprego de informática, é fácil ver vagas para analista de sistemas / programador / desenvolvedor júnior, pleno e sênior, etc. Acontece que a maioria das pessoas (inclusive os gerêntes de TI) não sabem muito bem fazer essa distinção entre os níveis, causando uma grande confusão na cabeça de todo mundo, inclusive na hora de negociar o cascalho. Portanto, vamos começar pelo básico …

Não sou uma pessoa entendida de RH, muito menos sei a história sobre como começou essa nomenclatura de júnior, pleno e sênior. Mas como trabalho na área de TI faz 12 anos e já passei por um bocado de empresas, acho que posso dar meu pitaco sobre o assunto. As melhores definições que consegui na internet para sênior foram: ancião, velho, pessoa com mais experiência em alguma profissão. De cara tem alguma coisa estranha na resposta que o tal gerente deu pro meu amigo, mas não para por ai.

No início da minha carreira, nas empresas onde passei, geralmente o cara sênior era um cara com mais experiência, uma pessoa que viveu mais situações, uma pessoa mais madura (não necessáriamente velha ou idosa). Por muitas vezes, essa pessoa não conhecia uma ferramenta ou outra de trabalho que eu conhecia, mas isso de maneira alguma me colocava no mesmo nível daquele profissional, pois tomando conhecimento da existência daquela ferramenta e utilizando um pouco do seu tempo, a tal ferramenta estava absorvida por este.

E o que eu quero dizer com isso? Eu quero dizer que se você começou agora, mesmo que você saiba python, ruby, java, erlang, haskell, xpto, brainfuck, você é Júnior ainda. Lógico que é ótimo saber diversas ferramentas e eu recomendo a todos estudar para isso. O mesmo princípio se aplica ao profissional sênior. Fatalmente tem algumas coisas que lhe fogem ao conhecimento, porém a diferência é que esse naturalmente conhece muitas ferramentas  devido a sua experiência ao longo dos anos. Não foi simplesmente um livro que leu ou um tutorial da internet que fez, mas projetos reais que participou. Um sênior deve saber debater com seus superiores sem medo, com argumentações bem formuladas, sabendo exatamente a sua posição, mas sem muito se intimidar quando conversa com outro profissional acima na hierarquia. Deve chamar a responsabilidade para si em momentos críticos, deve ajudar e ensinar os demais simplesmente porque isso é de sua responsabilidade.

Saber ou não uma determinada linguagem ou ferramenta não faz necessáriamente de você nem júnior nem sênior, pois isso as vezes depende da sua trajetória de carreira. Eu por exemplo não sei nada de ABAP, pois nunca trabalhei com SAP ou algo que use essa linguagem. Talvez você esteja aprendendo Java nesse momento mas tem 10 anos de experiência com C/C++ e tem ótimas práticas de programação. Em fim, é bem relativo.

Pra finalizar, certa vez um amigo me disse que sênioridade é algo como um estado de espírito. Vou até um pouco além disso. Acredito que sêrionidade é um estado avançado de profissionalismo aliado a maturidade alcançada ao longo do tempo.

Disclaimer:

Para que não pareça que defendo regime de quartel, quero deixar bem claro que hoje em dia de nada adianta você ser maduro e experiente se você é um profissional encostado e desatualizado. E o talento, é claro, sempre fala mais alto.

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

Aplicativos Open Social parecem algo como uma brincadeirinha de criança, coisa que qualquer pessoa faz. Mas na verdade, desenvolver esse tipo de aplicação para um programa como o Big Brother Brasil não é tão simples. Aplicações de grande volume geralmente usam arquiteturas recheadas de cache, processamento assíncrono usando fila, criptografia, alguns servidores e um bocado de outras coisas que o torna tão complexo quanto qualquer outro sistema.

Quero aproveitar também e destacar, que conseguimos desenvolver o produto completo “do zero”, em pouco mais de 1 mês. Isso inclui configuração de todos os servidores (inclusive produção que são várias máquinas), ambiente interno de desenvolvimento, servidor de integração contínua, desenho dos bonecos dos brothers de forma personalizada, vários testes de carga em ambientes que simulam produção e muita comunicação. Estou falando disso, pois usamos metodologias ágeis e acredito fortemente que se não fosse assim, não teria sido possível entregar o aplicativo nesse tempo (e não trabalhamos nenhum fim de semana). No caso específico aqui da globo.com, SCRUM é a metodologia usada, mas poderia ser Extreme Programming ou alguma outra qualquer. Um detalhe também importante é que nosso time tem apenas 10 pessoas, o que contraria um pouco o modelo tradicional que diz que com mais gente o trabalho anda mais rápido.

Se você gosta de Big Brother Brasil e deseja expressar sua opinião sobre algum brother, entre na seção de aplicativos do orkut e procure por: BBB – Voodoo Brother.

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