13/10/10

Poderia falar um pouco sobre o que é o Coolendar? Quais as principais funcionalidades?

Em termos gerais o Coolendar é algo tão simples quanto uma aplicação de organização pessoal, gerenciamento de tarefas, ou calendário. Mas é uma aplicação de calendário cool. Ou seja, um cool calendar.

Enquanto usuário, nunca fui satisfeito com as aplicações de calendário existentes - e acredite, eu procurei muito. Essa visão em matriz, uma espécie de tabela baseada na metáfora de um calendário "real", desses de parede ou de mesa. Observe bem, essencialmente todas as aplicações desse gênero são iguais.

Além disso - novamente enquanto usuário - nunca consegui distinguir a real diferença entre uma aplicação de calendário e uma de tarefas. Acredito que isso possa - e deva - ser gerenciado em um único fluxo, centralizado. Qual a diferença entre um apontamento de calendário e uma tarefa agendada com data e hora? A possibilidade de atribuir tempo de duração? Aprendi no Rework que tempos de duração são poison e não lhe permitem ser conciso. Aliás, as ferramentas não são feitas de forma a aproveitar ao máximo o seu valioso tempo. Pense bem como elas funcionam: você clica em " New Event" e...! Cria-se uma nova atividade com uma hora de duração do seu dia. Uma hora. Provavelmente 12,5% do seu dia inteirinho de trabalho. Quão simples é criar um compromisso nessas ferramentas de, digamos, 7 minutos? 14? Não muito simples. E por fim, reconheça - tempos de duração dificilmente funcionam - a não ser quando tem reserva pra sala de reunião.

Há muito tempo que pensava em desenvolver algo realmente diferente. Usar novas premissas, novas abordagens visuais e de interação, que permitisse customizações pessoais e, principalmente, tornar fluída, agradável e social a sua organização de compromissos. Pretendo chegar - e estou quase chegando - em algo mais ou menos assim:

tomorrow 9am #meeting for the #coolendar interview with @yarasenger

Dá pra perceber que com essa frase, praticamente em linguagem natural, eu agendo o compromisso (data e hora), atribuo tags para me organizar e ainda notifico os participantes do evento?

Qual foi a sua motivação para criar este projeto?

Além das motivações que citei acima - como usuário -, houveram as motivações técnicas: mais precisamente, o Google App Engine . Eu já tinha o projeto "na gaveta" há algum tempo, e quando o Google lançou a versão Java da sua plataforma App Engine - que inicialmente existia apenas para Python - decidi que era hora de implementar este projeto como "case" de validação da plataforma. Mais do que isso, não para validação apenas da plataforma em si, mas também de uma série de outras tecnologias que eu tinha aqui separadinhas, esperando pra serem vistas, e que não tinha tido ainda oportunidade de validar no dia-a-dia de projetos. Por exemplo, o desenvolvimento de extensões para o Google Chrome ( veja aqui ). Quem me conhece também sabe que, além de arquitetar e desenvolver, gosto muito de interfaces web e usabilidade - então decidi também colocar em prática os conhecimentos em HTML5 e CSS3 , adquiridos recentemente.

Poderia comentar um pouco sobre a Arquitetura da sua aplicação (tecnologias usadas, frameworks, bibliotecas)?

Desde o início optei por utilizar uma solução que fosse muito, muito leve - no App Engine você tem quotas gratuitas de processamento, storage, memória e transferência, que apesar de bastante generosas, são limitadas e te obrigam a primar pela performance desde o início. Na verdade acho isso muito bom. Além disso, trabalho muito com o padrão Spring + Hibernate /JPA, então queria algo que fosse bem diferente.

O App Engine para Java possui uma " whitelist " das classes da JRE que podem ser utilizadas, e o que não estiver nessa lista é bloqueado pela própria plataforma. Isso acabou fazendo com que uma série de frameworks não funcionassem lá , ou tivessem suas funcionalidades limitadas. No início essa lista era ainda mais restritiva, hoje alguns novos pacotes já são suportados, ou então existem workarounds, ou então os projetos disponibilizaram "fixes" para fazer com que os frameworks pudessem funcionar. Pra se ter uma idéia, por exemplo, até hoje não é permitida a execução de novas threads ou o acesso aos sistemas de arquivos .

Optei então pela seguinte arquitetura no servidor: JDO (persistência), Google Guice 2.0 (Injeção de Dependência e Aspectos), Jersey (REST) e Servlets/JSP (interface), sendo que para a interface desenvolvi ainda um suporte básico a mapeamento de URL's com anotações e baseado no módulo Web and Servlets do Guice 2.0 . Também uso, como utilitários, as bibliotecas fluentjava (que busca trazer algum suporte a Fluent Style e DSL's), guava-libraries (uma espécie de utils do Google) e Joda-Time (para manipulação de datas, horas e timezones, que uso muito no projeto).

Na web, como comentei há muito HTML5 e CSS3, além de jQuery 1.4.2 e jQuery Tools 1.2.5.

Como decidiu colocar no Google App Engine? Desde quando está usando o Google App Engine?

Foi um caso raro de plataforma que puxou a aplicação, como comentei anteriormente - decidi desenvolver a aplicação para testar a plataforma - apesar de já ter a demanda pela aplicação anteriormente. Comecei usando a plataforma em Python, e pouco tempo depois foi anunciado o suporte a Java (em Abril de 2009) , que passei a utilizar logo no início.

Quais foram os maiores desafios?

Certamente as limitações da plataforma (a whitelist que citei anteriormente), principalmente no início.
Conseguir manter o uso da aplicação dentro da quota gratuita também tem sido um desafio mais recentemente, mas pelo menos esse é um desafio bom de encarar.

Interessante um usuário "comemorar" que estourou a cota gratuita, o que significa isto? (Poderia falar um pouco de números?)

Bom, deves te referir a isso aqui .

No último dia 3 de Outubro, minha quota gratuita de utilização da plataforma foi excedida, mais especificamente na parte de processamento (CPU).

A quota disponibilizada pelo Google é contabilizada a cada 24h, sendo que existe também um controle "por minuto" (que te permite controlar que seu aplicativo não irá consumir a quota gratuita do dia em um período muito curto de tempo). Quando um aplicativo consome todo o recurso alocado, ele fica indisponível até a próxima renovação da quota, ou seja, a próxima "virada" de dia (24h). Se isso acontecer, qualquer usuário que tentar acessar seu aplicativo naquele período receberá uma mensagem de "over quota".

Veja, as quotas disponibilizadas pelo Google gratuitamente não são baixas, pelo contrário: em termos de CPU, você tem 6,5 horas de CPU para cada período de 24h, considerando um processador Intel X86 de 1,2Ghz (mais detalhes aqui ). Mas o Coolendar estava passando por um período de grande volume de acessos (no dia em que houve o primeiro estouro de quota, chegamos a picos de 6 requests por segundo; depois desse dia baixamos um pouco mas temos nos mantido em médias de 1,5 requests por segundo). Aí entra em cena o " billing " do Google App Engine: você libera mais recursos, de forma controlada, para suportar a demanda; pagando somente pelo excedente consumido.

O que você gostou mais no GAE e o que gostou menos?

Gosto muito do "painel de controle", que lhe permite ter uma visão geral do consumo de recursos, logs, permissões, jobs, recursos mais acessados e outros. O plugin do Eclipse também é ótimo, por permitir o deploy de forma muito, muito simples. Mas não posso deixar de citar a plataforma de uma forma geral, que é fantástica por lhe disponibilizar um ambiente distribuído, escalável, gerenciado e de alta performance, sem que você precise se preocupar com nenhuma questão de infra.

O que gostei menos, certamente, é a lista de pacotes não suportados - citaria em especial threads, sistema de arquivo e o suporte a JPA, que apesar de existente, é bastante fraco.

O que você gostou mais no GAE e o que gostou menos?

Existem ainda um conjunto de recursos que, na minha opinião, devem ser implementados para que se tenha uma versão "Beta", passível de ser chamada de "ferramenta de organização pessoal", "ferramenta de calendário" e ainda "cool" for real. E esse conjunto ainda não foi atingido. Apesar de ele já poder ser utilizado tranquilamente, eu classificaria a versão atual como "Alfa". Assim, estamos em um momento em que o feedback dos early adopters é muito importante, e caminhando para uma versão "de verdade".

Podemos esperar para breve (além dos ajustes e melhorias óbvios que estão faltando): aplicativo Android, mais interações "sociais", capacidade de customizações, (muito) mais mecanismos de notificação (alertas por SMS, Twitter, clientes desktop, etc) e integrações diversas (Google Calendar, iCal, Outlook, etc).

Tenho mantido um ritmo constante de desenvolvimento no projeto, inclusive com tempo da minha semana dedicado especificamente para isso. O projeto seguirá tendo uma boa evolução, será gratuito e livre de publicidade. Ao longo da minha carreira sempre tive projetos pessoais ( aqui , aqui e os deprecated, aqui e aqui ), mas o Coolendar é o que tem tido o retorno mais legal no menor período de tempo. Além do mais, gosto dele de forma especial. Ainda não tenho clareza em relação ao modelo a ser adotado: se vou liberar o código sob licença open source, se haverá um modelo de negócios por trás dele ou não, ou como vai ser.