Dia 29 de outubro, sexta-feira, foi realizado no Brasil o Google Developer Day 2010, evento já tradicional do Google para aproximar a comunidade nerd dos projetos e planos da empresa.
A última vez que fui em um GDD foi em 2008. E as diferenças para 2010 começaram logo na inscrição. Diferente de 2008, quando você só se cadastrava no site do GDD e pronto, já estava registrado para o evento, em 2010 foi necessário fazer uma prova de programação, e até enviar currículo.
A prova não tinha nada de mais. Era composta por 5 questões que abordavam temas gerais da computação, propondo problemas que só eram facilmente soluveis através de um algoritmo. E era essa a intenção: fazer do evento um evento para desenvolvedores, e não para qualquer-um-que-quer-um-almoço-grátis-do-Google.
O que foi mais sinistro foi ter que enviar o currículo para eles. Além da prova (que poderia ser feita por um amigo programador), era necessário ainda reafirmar que se é da área de tecnologia (e quais os interesses).
Após 15 dias de espera, saiu o resultado. Eu estava aprovado, porém dois amigos da empresa em que trabalho, não. Será que eles possuem filtro para Google fanboys? Enfim, parece que o currículo foi levado bem a sério (tenho conhecimento em vários projetos do Google, acredito que isso tenha feito diferença). Os critérios de aprovação ficaram sem clareza, entretanto.
O evento começou as 9 horas, com credenciamento a partir das 8. Como era véspera de feriado, São Paulo estava relativamente vazia, então não tive problemas de trânsito do aeroporto até o local do evento (Sheraton WTC Hotel).
Entrada do evento |
O mala do lado da entrada do evento |
Discurso de abertura do evento |
- Na apresentação sobre novas features do HTML5, o palestrante demonstrou a captura de sinais de acelerômetros através de Javascript, fazendo um texto girar de acordo com o movimento do notebook;
- Na apresentação sobre GWT + Spring Roo, quando o palestrante inseriu um campo a mais em uma classe do modelo (entidade), e a página de CRUD dessa classe se atualizou imediatamente, exibindo o campo a mais para ser inserido ou pesquisado;
- Na apresentação da pesquisa por reconhecimento de voz, o palestrante falou, em português, uma frase complexa (com termos em inglês no meio) e o celular com Android interpretou corretamente e trouxe os resultados da pesquisa.
Programação em toda parte |
Então era chegada a hora de decidir. Com 3 apresentações simultâneas, era necessário escolher o tema de interesse e entrar na sala correspondente. A programação de todo o evento é acessível pelo site oficial.
Do array de salas, era necessário escolher um índice (entre 0 e 2) |
- Novidades da Google App Engine e Google App Engine for Business;
- Google Web Toolkit: O que é, como funciona e tópicos mais profundos.
Hora do almoço. Diferente de 2008, o Google alugou um salão a mais no hotel, e a dividiu em sessões (chamados de lounges) por interesse. Havia o lounge de Cloud computing, outro de Android, outro de APIs etc.. O objetivo era trocar idéias sobre o tema nas áreas especificadas, tanto entre os participantes quanto com os próprios palestrantes. A idéia foi boa, mas era difícil encontrar alguém com o real interesse na sessão em que estava. Todos estavam é mais preocupados em encontrar um lugar bom para sentar e almoçar em paz.
O mala no lounge do Android |
De fato, a web está cada vez mais próxima dos aplicativos desktop, no sentido de capacidade gráfica, comunicação e interação com o usuário. Inclusive muitos frameworks (GWT por exemplo) permitem uma codificação muito próxima a de frameworks consagrados de GUI para desktop, como o Java Swing e o QT.
Após a palestra sobre HTML5, e decepcionado com as primeiras palestras sobre computação em nuvem, parti para o Android, com o tema "Práticas efetivas de interface com o usuário".
Foi a melhor palestra até então. O palestrante enumerou, de forma clara e objetiva, os fatores que levam ao sucesso (ou ao fracasso) de uma boa interface com o usuário, focando em dispositivos móveis. Porém, as dicas dadas foram tão esclarecedoras, que são pertinentes a quaisquer meios de interfaceamento, seja mobile, web, desktop, tv, carro ou o que for. O tema da apresentação está descrito no blog oficial dos desenvolvedores do Android (vale a pena a leitura ;-) ).
A próxima palestra que participei foi sobre APIs Google Apps. A principal idéia transmitida aqui é que desenvolvedores web que utilizam o ferramental do Google não precisam se preocupar em reinventar a roda, com relação a problemas típicos de toda aplicação, como autenticação/autorização, envio de mensagens, gerenciamento de calendário etc.. O Google fornece as peças para que os desenvolvedores brinquem de Lego.
Por exemplo, é relativamente simples integrar o GMail do usuário com documentos gerados pela sua aplicação (armazenados no Google Docs) e marcar compromissos na agenda (via Google Calendar), tudo isso acessível através de autenticação via OpenID.
Novo intervalo, mais quitutes para serem devorados (tinha até sorvete), mais papo nerd... Não era a toa que havia fila no banheiro masculino: das 1000 pessoas participantes, deveria haver... hummm... umas 5 mulheres?
Carrinho se sorvete do Google |
Após o intervalo, e empolgado pela ótima palestra sobre o Android, fui a mais uma palestra com o mesmo apresentador. Dessa vez o tema era "Construindo aplicativos de alto desempenho".
Novamente com uma excelente apresentação, o palestrante mostrou tanto otimizações já bem conhecidas pelos desenvolvedores Java (como por exemplo evitar operações com ponto flutuante, evitar concatenação direta de Strings, evitar reflection em código crítico etc.), como otimizações específicas do Android, pricipalmente com relação ao modelo de Threads do sistema.
Aqui eu reparei como o modelo de Threads do Android se assemelha com o Swing. Da mesma maneira que a literatura enfatiza que código pesado não deve ser executado na Thread de eventos do Swing (aka. EDT, Event Dispatch Thread), código pesado não deve ser executado na Thread principal do Android. Isso porque a Thread principal do Android é a responsável pela GUI, então qualquer outro processamento demorado deve ser executado em um fluxo separado.
O que o palestrante deixou claro é que algumas operações são inerentemente lentas, como acesso a recursos na internet e acesso a "disco" (entre aspas porque celulares não possuem HDD). Não se pode melhorar significamente o tempo gasto nessas operações, mas o feedback dado ao usuário pode sim ser o diferencial entre uma operação parecer ser demorada ou não.
Tim Bray, o cara do Android |
Uma coisa que me irrita frequentemente é o fato de ter que fazer cadastro em tudo quanto é site de serviços pela web. Bancos, e-mails, redes sociais, companhias aéreas, mensageiros instantâneos, fóruns, blogs... Todos requerem cadastro, um usuário e senha, e adivinha só... Uma vez cadastrada uma senha em um site raramente utilizado, o próximo acesso sempre é via "esqueci minha senha". Não precisaria ser assim. O OpenID resolve justamente esse problema: que tal ter um único usuário e senha para todos os serviços que utiliza? Inclusive os que você desenvolve?
Junto com o OpenID, o OAuth permite o acesso a dados do usuário, como e-mail, perfil, Geo Location etc. tudo, obviamente, mediante aprovação direta pelo usuário. Assim praticamente acaba a necessidade da famosa tabela "User" no seu sistema: é só deixar o Google gerenciar essa parte para você.
Após as últimas palestras foi feito um happy hour, com cerveja liberada e quitutes a vontade. Como não bebo e tenho intolerância a lactose, não pude aproveitar muito, mas de qualquer maneira valeu a convivência com o pessoal do evento.
Docinhos com o logo do Chrome |
Mais sobre:
Os vídeos da Google I/O abrangem de forma mais completa aquilo que foi passado no GDD: http://www.google.com/events/io/2010/
Té++