O canivete suíço do desenvolvedor: ferramentas de diagnóstico para aplicações Java EE

Saudações a todos,

Estou postando direto do JUDCon 2013 Brazil para dizer meu muito obrigado a todos que compareceram e que vieram cheio de vontade de conhecer mais o ecossistema JBoss. Os workshops de Openshift (ministrados diretamente pelos evangelistas OpenShift) também foi um sucesso.

Para os que compareceram à minha palestra, segue abaixo a apresentação:

JUDCon Brasil 2013 - Não Percam

Amanhã começa o evento mais importante para a comunidade JBoss: O JUDCon, JBoss Users and Developers Conference. E como era de se esperar, teremos bastante assunto sobre OpenShift... \o/
Eu irei palestrar no evento, mas o assunto não está relacionado sobre Cloud Computing nem OpenShift (mesmo assim, espero que gostem). Mas para compensar, teremos workshops com os desenvolvedores do Openshift (Steven Citron-Pousty e Shekhar Gulati) e até um desenvolvedor brazuca (Fabiano Franz) apresentando.
Para quem quiser ir, ainda dá tempo. Acesse http://www.jboss.org/events/JUDCon/2013/brazil e veja o local e agenda do evento. Espero ver todos por lá.

Ferramentas de DevOps em Openshift

Introdução

Além de todos os benefícios que eu sempre venho dizendo e escrevendo neste blog do Cloud Computing, quero aqui mostrar um cenário do qual o desenvolvimento de aplicações pode se tornar cada vez mais prático utilizando  ferramentas que podem auxiliar o que chamados de DevOps (Development Operations). DevOps trata de unir o desenvolvimento, Quality Assurance (QA) e Infraestrutura (Technology Operations) de forma a estressar a comunicação, colaboração e integração entre esses times e com isso padronizando os ambientes de desenvolvimento e facilitando o gerenciamento de releases da aplicação.

Um gráfico que exemplifica o papel de DevOps em um processo de software  (Fonte: wikipedia)

Cloud Computing, além de provisionar um ambiente operacional para suas aplicações em questão de segundos, aproxima o desenvolvedor de um ambiente de produção (ou muito próximo dele) e assim o desenvolvedor consegue ter uma visibilidade muito maior de como sua aplicação irá se comportar em um ambiente desses. Entretanto, não podemos simplesmente botar todo o foco nisso sem esquecer em métricas de qualidade do código nem em integração contínua.

Nesse post eu irei mostrar que em Openshift você pode fazer tudo isso e ainda por cima disponibilizar publicamente e de uma forma bem simples.

Gerenciamento de projetos com Redmine

Redmine é uma ferramenta escrita em Ruby que permite a criação e gerenciamento de issues de projetos, além de servir como um repositório de documentos e arquivos relevantes ao projeto e também pode ser criada uma base de conhecimento em formato wiki. O que eu achei a maior sacada do Redmine é que ele traz uma visualização das issues em um gráfico Gantt(o gráfico preferido dos gerentes de projetos), podendo assim ver a situação do projeto de forma online.

Gráfico Gantt gerado pelo Redmine

Atualmente, eu venho utilizando o Redmine em um projeto pessoal meu e por isso eu venho estudando essa ferramenta para pode me organizar nas tarefas. Com ele, eu consigo ver exatamente o que eu quero que minha aplicação tenha e assim poder eu mesmo organizar as tarefas e ir registrando meu progresso.
Aliando a facilidade de provisionar um sistema como o Redmine com a infraestrutura de nuvem pública, é possível criar um ambiente para os gestores de projetos de uma startup a gerenciarem e monitorarem os projetos e seus detalhes de forma que não precisem manter essa infraestrutura (nem pagarem por isso).

Integração Contínua com Jenkins

Quem já ouviu falar de Integração contínua, com certeza já ouviu falar do Hudson/Jenkins. Essa ferramenta pode ser uma mão na roda para projetos com muitos desenvolvedores, onde ele auxilia a equipe a testar todo o projeto a partir do código que já se encontra em um repositório de código, desde compilando o código até executando testes unitários e de integração. Tarefas mais completas (e por consequëncia, complexas) chegam até a publicar os artefatos em repositórios como o Nexus.

Tela do jenkins e os detalhes de uma tarefa automatizada

Dentre todas as ferramentas que irei mencionar neste post, esse com certeza é o mais integrado ao ambiente OpenShift pois já nasceu com essa integração com o Jenkins e portanto é o mais fácil de se utilizar dentro do OpenShift.

Qualidade de código com Sonar

Para aumentar a qualidade de código de seus projetos, há a ferramenta Sonar para análise de qualidade de código. Obviamente, isso é feito de forma estática e baseado em regras de desenvolvimento. Para cobrir a qualidade do código em execução deve-se utilizar ferramentas de teste unitários, de integração, funcionais, etc. Isso tudo pode ser combinado no Jenkins em uma tarefa de integração contínua, com mencinado na seção anterior.

O Sonar já vem com algumas regras (algumas delas criadas pela própria Sun, e que Deus a tenha), o que permite que você não comece a criar as regras do zero e poupando tempo na definição das mesmas.

Tela do sonar com um exemplo de análise de um projeto

Um detalhe importante para utilizar o sonar em seus projetos OpenShift: o projeto é todo estruturado no Maven e portanto você pode utilizar o plugin do Sonar para assim poder executar a tarefa:

$ mvn sonar:sonar

Porém o plugin exige que se utilize uma URL com uma porta específica para acesso ao repositório do Sonar e registrar todas as informações relevantes à ele. Como no OpenShift, as regras de segurança são muito restritar, é necessário que você habilite o port forward em sua aplicação sonar com o seguinte comando:

$ rhc port-forward -a <aplicacao_sonar>

Monitoramento de aplicações com Openshift Metrics

OpenShift fornece um cartridge específico para o monitoramento da saúde de sua aplicação. Ela é muito simples, mas já te dá informações cruciais da sua aplicação(como consumo de memória e CPU). Para adicionar em sua aplicação o cartridge para monitorar sua aplicação, basta executar:

$ rhc cartridge add metrics-0.1 -a <nome-aplicacao>

Após a conclusão do comando, você pode acessar o Metrics através da URL:

http://<aplicacao>-<dominio>.rhcloud.com/metrics/

OpenShift metrics

Por ser uma ferramenta ainda experimental, o código ainda não está disponível. Acredito que em breve teremos mais funcionalidade e também a abertura do código.

Conclusão

As ferramentas apresentadas neste post podem ser instaladas de forma muito simples: seja pela ferramenta rhc ou pelo próprio console administrativo do Openshift ou até utilizando dos quickstarts da comunidade que, em sua maioria, se encontram no github do Openshift. Apesar da facilidade da criação desse ambiente, as contas gratuitas do Openshift permitem até 3 aplicações criadas e portanto você pode consumir toda a sua cota, mas nada te impede de criar várias contas e gerenciar essas aplicações em uma conta específica.

Gerenciando suas aplicações no cloud com as ferramentas de cliente

Neste post, irei mostrar a ferramenta rhc, que permite gerenciar em linha de comando todas as aplicações, seu domínio e outras informações referentes à sua conta OpenShift. No primeiro post, eu mostrei muito por cima como criar uma primeira aplicação usando a IDE Eclipse utilizando o Plugin JBoss Tools. Tentarei aqui ser o mais neutro possível a respeito de plataformas então eu vou explicar como instalar a ferramenta no Linux, Mac OS e Windows.

Instalando a ferramenta no Linux

Para poder utilizar a ferramenta no Linux, é preciso instalar os seguintes pacotes:

• rubygems
• git

Como podem ver, a ferramenta foi escrita em Ruby e por isso apesar de mencionar a instalação de apenas dois pacotes eles trarão dependências adicionais para poder fazer os pacotes principais funcionarem.

Após a instalação com sucesso dos pacotes, basta executar o seguinte comando para instalar o rhc:

$ sudo gem install rhc

Instalando a ferramenta no Mac

Para instalar a ferramenta no Mac, é preciso ter os seguintes pré-requisitos:

• Acesso a root
• Suite XCode completa ou git for OS X

Após a instalação, basta executar o comando:

$ sudo gem install rhc

Instalando a ferramenta no Windows

Para instalar a ferramenta no Windows, é preciso ter os seguintes pré-requisitos:

• Instalar o Ruby 1.9 for Windows (Lembre-se de marca a opção "Add Ruby executables to your PATH")
• Instalar o Git for Windows (Marque a opção "Run Git from the Windows Command Prompt")

Feito isso, basta executar o comando:

C:\> gem install rhc

Configuração inicial da ferramenta

O primeiro comando que iremos aprender é o comando:

$ rhc setup

Nele, você irá fazer as configurações iniciais da ferramenta, como gerar as chaves de segurança SSH para o login da ferramenta(muito importante para poder conectar ao repositório git das aplicações), a criação de um nome de domínio(com ele, todas as aplicações criadas pela sua conta levarão esse nome único para identificar aplicações criadas por você), e verificar alguma pendência de configuração exigida pelo OpenShift.
Após o procedimento de setup, ele irá gerar os seguintes arquivos:

<user_dir>/.openshift/express.conf
<user_dir>/.ssh

O primeiro é uma configuração bem básica do Openshift (inicialmente um usuário padrão ao usar o comando rhc, que pode usar outro usuário adicionando a opção -l no comando, e o endereço do servidor Openshift) e o outro é o repositório de chaves SSH para comunicação com os serviços Openshift. Sem isso, você não conseguirá fazer um git clone do repositório.

Criando a aplicação

Depois de preparado o ambiente, estamos prontos para a criação da aplicação. O comando para criar é:

$ rhc app create -a <nome_da_aplicacao> -t <tipo_aplicacao>

Onde o <tipo_aplicacao> pode ser:

•  dyi-0.1
• jbossas-7
• jbosseap-6.0
• jenkins-1.4
• nodejs-0.6
• perl-5.10
• php-5.3
• python-2.6
• python-2.7
• python-3.3
• ruby-1.8
• ruby-1.9
• jbossews-1.0 (basicamente um Tomcat 6)
• jbossews-2.0 (basicamente um Tomcat 7)
• zend-5.6

Como podem ver na lista, a variedade de linguagens/servidores para desenvolvimento no Openshift tem crescido cada vez mais. E ainda podemos criar nosso próprio com o Do-It-Yourself Cartridge (farei um post explicando sobre isso). Essa tarefa irá criar um processo automático que no final irá gerar um endereço do repositório git e também a URL da sua aplicação no formato http://<nome_da_aplicacao>-<nome_do_dominio>.rhcloud.com

Snapshots da aplicação

Caso você queira criar backups de sua aplicação para posteriormente voltar às versões anteriores, o Openshift permite que você crie snapshots da sua aplicação e restaurá-los quando quiser. Em outras palavras, o snapshot é arquivo compactado que contém tudo que sua aplicação precisa para ser recuperada em uma outra gear do Openshift, tais como as variáveis de ambiente, o repositório git, os binários da aplicação, etc. Para criar um snapshot, basta executar o comando:

$ rhc snapshot save -a <nome_da_aplicacao> -f <nome_do_arquivo>

Assim, caso você queira restaurar a aplicação, execute o comando:

$ rhc snapshot restore -a <nome_da_aplicacao> -f <nome_do_arquivo>

Diagnóstico de problemas

Sempre pode ocorrer problemas e que precisam de nossa intervenção para que nossa aplicação possa voltar ao ar ou até mesmo monitorar nossas aplicações para procurar eventuais problemas. Para isso, o rhc possui alguns comando que podem auxiliar o desenvolvedor a encontrar o problema.
O primeiro de todos os comandos irá verificar a saúde da infraestrutura do Openshift:

$ rhc server

Nele, é possível verificar se o problema não é generalizado e portanto se há alguma ação que pode ser realmente tomada por conta da sua aplicação. Caso apareça a mensagem "All systems running fine", então estamos à salvo... =D
O segundo comando inspecionará todos os logs da sua aplicação e irá imprimir (sob demanda) as mensagens deles. O comando é:

$ rhc tail -a <nome_da_aplicacao>

Por fim, pode ser necessário inspecionar a performance em si da aplicação, assim verificando se a mesma está muito lenta, então pode ser necessário inspecionar as Threads do sistema. O comando para gerar o thread dump (um arquivo que descreve todas as Thread em execução do sistema) é:

$ rhc threaddump -a <nome_da_aplicacao>

Após a execução desse comando ele irá retornar uma mensagem dizendo onde o Thread Dump estará disponível, podendo inspecionar utilizando o comando descrito anteriormente. Para ser mais exato, o próprio rhc irá já enviar o comando completo que deve ser executado para inspecionar o Thread Dump.

Conclusão

Espero que esse post seja de muita utilidade a todos pois alguns usuários Openshift como eu adoram em algum momento utilizar a linha de comando para criar suas aplicações e até mesmo automatizar alguns processos. Fica aqui uma dica: todos esses comandos do rhc por trás há uma API REST que é consumida pelos comandos (que são nada mais nada menos que código Ruby). Em um post futuro explicarei sobre a API REST.

Migre suas aplicações Google App Engine para Openshift.

Há tempos que quando iniciei meu contato com Cloud Computing, sempre fiquei com o pé atrás ao falar de Google App Engine (GAE). Não que ele seja ruim, que não há escalabilidade ou qualquer coisa desse tipo, mas principalmente porque desenvolver com o GAE implica em utilizar apenas duas linguagens (Java e Python) e às vezes ter que se limitar a usar algumas coisas da própria linguagem suportada por esse PaaS(como o Java) e com isso podendo até não permitindo utilizar alguns de seus frameworks.
Um dos princípios que costumo falar ao adotar soluções PaaS é o de sempre verificar se o seu provedor não utiliza soluções fechadas (o famoso Vendor Lock-in) e portanto "prendem" o cliente a ficar em suas soluções sem uma chance de poder migrar as mesmas para um outro provedor. Neste artigo, irei descrever como migrar suas aplicações GAE para o Openshift, e de novo não porque Openshift é melhor e/ou GAE é ruim, mas principalmente por trazer maior liberdade para o cliente final poder avaliar outros provedores.

O Google App Engine(GAE)

O Google App Engine (ou GAE) é um dos pioneiros em se tratando de soluções PaaS(Platform-as-a-Service, ou Plataforma-como-um-serviço). Trata-se de utilizar a infraestrutura dos servidores do Google (a mesma utilizada pelo Google para manter todos os seus serviços no ar) para criar, desenvolver e administrar suas aplicações utilizando como linguagem o Java ou o Python. Não há o que negar sobre a performance dos datacenters do Google e sobre sua capacidade de inovação, o que fez com que o GAE se tornasse um dos principais provedores de soluções de Middleware gratuito para Cloud Computing, e também contém uma interface bem simples para monitorar e administrar suas aplicações.

Tela inicial do GAE

 O GAE oferece duas linguagens para desenvolvimento de aplicações, que são o Java e o Python. Em relação ao Python, o desenvolvimento de aplicações é tranquilo e conta com diversos (e bons) tutoriais na Internet para auxiliar no desenvolvimento. Já não consigo ver uma vantagem tão grande assim quando se fala de desenvolver uma aplicação GAE usando Java, já que há uma série de limitações que a Google impõe à linguagem, criando uma espécie de JRE White List que diz quais são as classes que podem ser usadas para o desenvolvimento de aplicações. Isso pode tornar alguns frameworks não funcionarem direito por conta dessas restrições (veja a página Will it Play) ou até mesmo terem que ser configurados de uma forma que dá um bocado de trabalho.

Interface administrativa do GAE

O GAE também possui um Datastore próprio baseado no conceito de BigTable e que é próprio do Google. Assim como toda a tecnologia provida do GAE, esse datastore é base para diversos serviços do Google, o que torna a confiabilidade no mesmo ainda maior. Entretanto, por ser uma tecnologia específica deles não há muito o que fazer se for o caso de migrar uma aplicação GAE para outras plataformas.
Por fim, e dessa vez quis deixar os serviços que eu digo que são os diferenciais do GAE, ele possui um esquema de versões da aplicação que eu acho muito bom. Ele consiste em implantar diversas versões de uma aplicação e com isso poder testar cada versão isoladamente (adicionando como sufixo o número da versão). Após o teste da última versão (ou da versão que deseja publicar), basta selecioná-lo na lista e pedir para publicar, com o mínimo de downtime em sua aplicação. Outro grande diferencial é o dashboard do GAE (ver figure acima), que fornece diversas métricas para monitoramente de administração da sua aplicação.
Novamente, meu objetivo aqui não é dizer que X é melhor que Y nem tirar os méritos de determinadas tecnologias. Quis aqui apenas expressar alguns dos pontos positivos e negativos e também fornecer alternativas para manter a liberdade de escolha de provedores. Com base nessa breve descrição, quis mostrar que uma aplicação GAE roda exclusivamente no ambiente do Google por motivos que forçam o desenvolvedor a utilizar tecnologias fechadas do Google e que portanto pode tornar a migração dessas aplicações inviável. Pensando nisso, eu quis criar este post para apresentar o projeto CapeDwarf. Explicarei na próxima seção no que consiste este projeto e também mostrarei como utilizá-lo.

O projeto CapeDwarf

O projeto CapeDwarf é um projeto da JBoss que visa criar um ambiente semelhando ao do GAE utilizando todo o ecossistema de middleware da própria JBoss. O criador do projeto, Aleš Justin, descreve o CapeDwarf como "uma implementação do Google App Engine, que permite que aplicações sejam implantados em servidores JBoss AS sem modificação". Mas como assim sem modificação? Está me dizendo que eu posso migrar uma aplicação GAE para o CapeDwarf sem mexer em sequer uma linha de código?
A resposta mais clara para a pergunta acima é: Sim! Você pode migrar aplicações GAE para o CapeDwarf sem alterar 1 LoC (medida da Engenharia de Software que indica Linha de código (ou Line of Code). A idéia é simplesmente criar uma série de subsistemas em cima do servidor de aplicações JBoss para que uma aplicação GAE possa viver fora do ambiente, utilizando jGroups, Infinispan e outros projetos da JBoss.org.
Você pode encontrar maiores informações no site do projeto.

Executando no Openshift

O passo a passo descrito nesta seção parte da premissa que o leitor leu o primeiro post a respeito dos primeiros passos para utilização do Openshift, portanto irei direto ao assunto.
Na tela de gerenciamento do Openshift, você verá a listagem de todas as aplicações criadas na sua conta (lembrando uma coisa importante: caso já tenha 3 aplicações criadas, sugiro criar uma nova conta ou remover uma das aplicações pois o Openshift limita uma conta free a criar até 3 aplicações sem habilitar Scaling) ou se não tiver nenhuma ele irá direto para a tela de criação de uma aplicação.

Tela de gerenciamento do Openshift

Na tela de criação da aplicação, procure por CapeDwarf. Basicamente, se trata de um servidor JBoss AS contendo toda a camada que o CapeDwarf implementa para "simular" os serviços do GAE.

Criação da nova aplicação

Depois de selecionado o tipo de aplicação, defina o nome da sua nova aplicação. Note que o Openshift irá pegar todo o código necessário para configurar o ambiente do github. Caso queira ver outras opções de aplicação, poderá verificar diretamente no site.

Configuração da nova aplicação

Por fim, clique no botão "Create Application"

Finalização da criação da aplicação

Feito isso, o Openshift irá realizar os processos iniciais (propagar o novo endereço em seus servidores DNS, clonar o código do Openshift, fazer o build, etc.) e depois mostrará a tela de conclusão com a URL da sua nova aplicação. Se você chegou até aqui, então estamos no caminho certo. =D

Tela de informações sobre a nova aplicação criada

Copie e cole o endereço criado para sua nova aplicação e acesse em seu navegador favorito(não se preocupe se a URL retornar HTTP 500 ou HTTP 404, isso só indica que a URL ainda não propagada nos servidores DNS). Você terá a tela abaixo:

Tela inicial da nova aplicação

Essa é a tela de apresentação do CapeDwarf rodando no Openshift. Veja que há também um endereço git configurado para sua aplicação, portanto faça o clone de seu repositório para poder copiar o código. Como uma alternativa caso você tenha apenas o arquivo .war gerado da sua aplicação, copie no diretório <app_dir>/deployments, e não se esqueça de gerar um arquivo vazio dentro de <app_dir>/.openshift/markers/skip_maven_build para dizer ao Openshift não gerar mais builds. Esse procedimento não sobreescreverá a tela inicial da aplicação, devendo ser acessada como http://gaeapp-meudominio.rhcloud.com/minhaappgae.
Você leitor deve se perguntar agora: mas o GAE permite monitorar minha aplicação através de uma interface administrativa, por acaso migrando minha aplicação para o CapeDwarf/Openshift eu vou perder essa funcionalidade? A resposta é não. Se você observar rolando a página um pouco mais pra baixo, há uma seção chamada Admin Console, onde ele fornece um usuário e senha que você pode acessar a interface administrativa de sua aplicação

Senha gerada para acesso ao admin console

Com esse usuário e senha em mãos, basta acessar a URL http://gaeapp-meudominio.rhcloud.com/_ah/admin (não se esqueça que se sua aplicação estiver empacotada como um .war em <app_dir>/deployments, você deve acrescentar o nome da aplicação) e após o login você terá acesso ao console administrativo de sua aplicação. Note que ela é semelhante ao console do GAE propositalmente para que não haja nenhuma dificuldade em utilizar o ambiente.

Console Administrativo da aplicação GAE no CapeDwarf

Muito legal, não? Pois bem, a má notícia é que o CapeDwarf ainda está em sua versão Beta1 (nos próximos dias a JBoss irá lançar o Beta2) e portanto algumas das funcionalidades dessa interface ainda não estão prontos, bem como alguns dos serviços que o GAE oferece ainda não foram implementados (são bem poucos, mas isso depende de quão dependente desses serviços estão com o GAE).
Fico por aqui e caso tenham dúvidas/sugestões/reclamações a respeito do CapeDwarf ou do Openshift, podem postar comentários que eu responderei com maior prazer. Ou se preferir, pode ir no fórum do CapeDwarf e perguntar diretamente aos desenvolvedores do projeto.

Curso online: Amazon Web Services For Newbies

Recebi ontem um tweet do José Papo (Amazon Web Services Evangelist - Latin America e meu ex-professor da graduação) indicando um curso gratuito sobre AWS para Newbies. Basicamente, o curso trata de explicar o conceito de algumas das ferramentas que compoem o AWS e qual a finalidade de cada uma delas para sua infraestrutura. Ao fim do curso o instrutor Anthony James (Twitter: @anthonydjames), dá uma prática de como utilizar as ferramentas e botar no ar aplicações na nuvem da amazon.

Bom, este post é curto apenas para divulgar aos interessados em conhecer soluções de IaaS (Infrastructure-as-a-Service, ou Infraestrutura-como-um-serviço) e como eles funcionam. Para quem quiser conhecer o curso, mas acessar a página da udemy.com e procurar por "Amazon Web Services for Dummies". Para os leitores pragmáticos (a.k.a. os preguiçosos, como eu), pode acessar o curso diretamente aqui.

Evento TI no Vale 2012

No último sábado (15/12), participei do evento "TI no Vale 2012" a pedido de meu amigo William Antônio (jesuíno), organizado por ele e mais alguns integrantes do JUG Vale, localizado na cidade de São José dos Campos. Fiquei honrado por novamente voltar a esta cidade que tanto admiro por ter um grupo de programadores fanáticos (assim como o William) e também por esta região ter institutos de pesquisa de peso (como o ITA e o INPE). A última vez que fui para lá foi para um evento do próprio JUG Vale.

Logo do evento

O eventou contou com quatro trilhas (no mesmo formato de eventos como o TDC (The Developers Conference): Games, Mente Aberta, Nuvem de Elétrons e Programação. O próprio site foi algo interessante (e também parte do assunto relevante a este blog), pois eles contruíram o site do evento utilizando Openshift como uma solução de PaaS e também de hospedagem. Para quem quiser conferir, o site é http://site-tinovale.rhcloud.com.
Eu participei da trilha Programação, onde apresentei a palestra "Sua aplicação nas nuvens com Openshift". O objetivo da palestra tratou de falar sobre como Cloud Computing tem impulsionado muitas startups a criarem suas idéias e lançarem ao mercado em tempo recorde com baixo custo e como grandes empresas puderam economizar com TI simplesmente diminuindo a ociosidade de seu parque de servidores. Por fim, apresentei quatro demos interessantes: Uma aplicação Magento (um framework de e-commerce escrito em PHP) rodando na nuvem, uma (simples) aplicação em Python com Django, demonstrei uma breve instrodução ao projeto Capedwarf, que permite a migração de aplicações Google App Engine para ambientes JavaEE/JBoss e Openshift sem mexer em uma linha de código(farei um post sobre isso nas próximas semanas), e um exemplo prático de como migrar e por fim demonstrei como é possível criar um ambiente DevOps com Openshift e Jenkins (claro que só isso não é o suficiente, mas é um bom ponto de partida para isso).
Minha intenção com as demos foi simplesmente mostrar que Startups hoje viraram moda, mas nem sempre sinônimo de startup é rentabilidade a curto prazo. Porém é possível encurtar essa trilha se sua solução/idéia precisa de uma hospedagem à Internet e que também permita criar um ambiente de Middleware à sua escolha, sem ter que te travar por conta de suportar apenas uma ou outra tecnologia. Além disso, é possível também usar soluções já prontas no mercado (como o Magento ou sua própria aplicação em GAE) sem ter que reinventar a roda ou reescrever código. Espero que o pessoal do evento tenha gostado, pois eu gostei e sempre gosto muito de apresentar por lá.
Gostaria de novamente agradecer ao William e ao pessoal do JUG Vale que sempre me recebem muito bem quando eu vou aos eventos e também ao Professor Renzo da FATEC e Diretor de Tecnologia da QMagico (uma espécie de Khan Academy brazuca) por compartilhar seus conhecimentos e experiências com o Google App Engine. Segue abaixo meus slides apresentados no evento, e como ainda não recebi as fotos do evento ficarei devendo nesse momento. Assim que tiver as fotos eu posto aqui.