Fazendo do Jeito Certo

A maior parte dos desenvolvedores web, designers ou programadores, começaram antes do surgimento dos movimentos em prol dos padrões web, usando tabelas para montar layouts em editores WYSIWYG, e ainda hoje este método é usado na maioria dos projetos de internet. Logo, é natural que muita gente, ao começar a entender o valor dos padrões, se pergunte como migrar do desenvolvimento “tradicional” para o desenvolvimento de código semanticamente coerente.

É um caminho muito duro o que separa o desenvolvedor acostumado a editores visuais do desenvolvimento de código coerente. E é muito comum que o designer desista após uma primeira tentativa frustrada de desenvolver um website tableless, com layout CSS e XHTML validado.

Por isso gostaria de propor um caminho gradual, mais suave, para aqueles que querem se aventurar pela primeira vez pelos padrões web. O princípio desse método é da recompensa. Você pode obter um grande benefício aproximando seu código dos padrões web, mesmo que não faça tudo de uma vez. Quero mostrar como você pode começar, e obter benefícios imediatos.

Limpe seu HTML

A minha primeira recomendação é que você estude CSS. Comece pela formatação básica de fonte, cor e tamanho. Isso vai te garantir código menor e produtividade maior com pouquíssimo esforço.

Assim, ao criar um item de menu, você vai evitar códigos como este:

<a href="parceiros.asp"><font
face="Arial, Helvetica, Sans-serif" size="2"
color="#FF3300"><b>Parceiros</b></font></a>

Colocando no lugar:

<a href="parceiros.asp" class="menu">Parceiros</a>

Tendo no CSS:

.menu{
font-family: Arial, Helvetica, Sans-serif;
font-size: 80%;
font-weight: bold;
color:#FF3300;
}

Como você pode ver, o CSS é extremamente simples. Aprender esses quatro atributos, mais o “font-style” (para fazer itálico), é a primeira coisa que eu recomendo. É claro, isso apenas faz cócegas nas possibilidades do CSS, ainda há muito o que aprender, mas recomendo começar por aí porque é algo que você pode aprender em alguns minutos e vai te salvar muito, muito tempo. E você vai começar a ter o controle da formatação, tendo todas as definições de fonte em um único arquivo, podendo alterar, por exemplo, a qualquer momento, a fonte de todo o conteúdo ou de todos os menus do site.

O passo seguinte para limpar seu HTML é se livrar do spacer.gif, aquele gif transparente de 1 pixel que se usa para dar espaços em tabelas, e das dezenas de tabelas aninhadas. Para isso vamos começar a estudar o “box-model”.

O pulo-do-gato aqui é um atributo CSS chamado padding. O padding é a distância entre as bordas de um elemento e o texto dentro dele. Assim, se é preciso que o conteúdo de uma célula esteja a 10 pixels da borda esquerda, ao invés de inserir uma célula extra como espaçador, ou inserir mais uma tabela, basta definir uma classe para essa célula. Uma vez que você já está colocando a formatação no CSS, provavelmente esta célula já tem uma classe. Então basta:

.conteudo{
padding-left:10px;
}

Isso vai fazer com que o texto esteja a 10 pixels da borda esquerda do documento. Ah, claro, o CSS também pode livrar você de definir no HTML as bordas e o background das células de sua tabela. Lembre-se, quanto mais layout e formatação você colocar no CSS, mais controle terá sobre seu site, principalmente em mudanças de layout durante o processo de produção e em futuras manutenções. O site também será mais leve para carregar.

Concluímos então que, após aprender os atributos de formatação de fonte, o passo seguinte é aprender os atributos background, border e padding. Indo até aqui você com certeza será um desenvolvedor muito mais feliz! Depois de limpar seu HTML, ganhar controle sobre a formatação de seu site e se tornar muito mais produtivo, você está pronto para passar à segunda etapa, correndo atrás da semântica.

Começando o Trabalho de Gente Grande

Muito bem, agora você já pode limpar seu código. Vamos estudar um exemplo prático. No começo de cada uma de suas páginas você tem um título, cujo código hoje é assim:

<font face="Arial, Helvetica, Sans-serif" size="4"
color="#FFFF00"><b>Novidades</b></font>

Ao limpar esse código, você vai substituir esse monte de tags por uma só. Que tag você vai usar? Como o CSS te permite formatar qualquer elemento, muita gente que começa a estudar o assunto acha que é indiferente que tag usar, e coloca algo como:

<p class="titulo">Novidades</p>

Agora, veja bem, outro desenvolvedor poderia resolver o mesmo problema com:

<div class="titulo">Novidades</div>

E o resultado visual poderia ser o mesmo. Acontece que há algo na natureza do HTML que nos diz que tag usar. Chamamos esse algo de “semântica”: as tags do HTML tem significado. A tag P é para parágrafos, a tag DIV para divisões no conteúdo, e há uma série de tags para título, h1, h2, h3, h4, h5 e h6. Assim, se você pode usar qualquer tag, pode fazer assim:

<h1>Novidades</h1>

O que você ganha com essa preocupação? Os buscadores inteligentes podem ler semanticamente o conteúdo de um documento, entendendo que trecho de código é um título, por exemplo. Assim, escrever HTML semanticamente correto pode melhorar muito sua visibilidade em buscadores. O segundo bom motivo é que você vai saber para que serve cada tag se tiver que mexer nesse mesmo documento daqui a alguns meses. E vai ser mais fácil também se outra pessoa tiver que dar manutenção no seu código.

Logo, use as tags do HTML para aquilo para o que foram criadas:

• dd, dl e dt para listas de definições (um glossário, por exemplo)


• h1 a h6 para títulos


• p para parágrafos


• abbr para abreviaturas e acronym para acrônimos


• blockquote e q para citações longas e curtas


• address para endereços (sabe aquele rodapé onde vai o endereço e o telefone da empresa?)


• ul e ol para listas e li para os itens da lista

Você pode obter uma lista mais abrangente em:

http://www.w3schools.com/xhtml/xhtml_reference.asp

E formate tudo ao seu gosto com CSS.

Finalmente, Livrando-se das Tabelas

Não há bons motivos para você eliminar a qualquer custo todas as tabelas de seu primeiro trabalho. Conheço alguns excelentes profissionais, muito talentosos, que fizeram um ótimo trabalho em sua primeira tentativa de tableless. Mas a maioria dos que eu vi tentarem demoraram muito para conseguir da primeira vez, e alguns não obtiveram os resultados que esperavam. Isso tudo serve para que você possa produzir mais rápido e melhor, não o contrário. Então vá com calma. Faça alguns estudos em tableless, comece eliminando parte das tabelas em seus primeiros trabalhos. Por exemplo, remover as células de tabela que formam o menu, trocando por uma lista (com as tags ul e li), é um ótimo desafio para o primeiro projeto.

Ah, e não se esqueça que para dados como uma tabela periódica ou um calendário a solução semanticamente correta é a tabela mesmo. Ou seja, tableless não é ausência de tabelas, é o seu uso apenas onde é semanticamente justificável.

Não vou entrar em detalhes aqui, porque já escrevi bastante sobre como construir um layout no Tutorial Tableless Básico, mas o conselho é ir com calma, sem estresse. Você logo vai estar produzindo tableless mais fácil do que produz sites com tabelas.

XHTML

Há uma coisa que muita gente que está começando me pergunta: o que é e para que serve esse tal de XHTML? É muito mais simples do que parece. Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser. Não estamos falando de um novo HTML, com novas tags ou coisa assim. Pelo contrário, o XHTML 1 foi feito para funcionar mesmo em navegadores antigos. Mas, ao mesmo tempo, Um arquivo XHTML é também um arquivo XML válido, que pode ser lido por qualquer interpretador de XML.

Meu primeiro conselho, nesse caso, é que você, se não trabalha com XML, deixe preocupação com o XHTML para depois de dominar bem o código semântico e o layout tableless. Não porque seja complicado, pelo contrário, transformar bom HTML em XHTML é bem simples, mas simplesmente porque você pode obter benefícios muito significativos, e muito mais rapidamente, aprendendo CSS do que XHTML.

O segundo conselho é que você comece a estudar o assunto. Depois de dominar bem layouts CSS, mergulhe no XML. A maioria dos bancos de dados hoje permite extrair dados diretamente em XML e todas as plataformas de aplicações web trabalham bem com XML. E com a poderosa linguagem XSLT você pode muito facilmente oferecer seus os dados em XHTML para o navegador.

Voando Alto

Estamos falando de muito mais do que criar sites estilosos. Há duas semanas esteve aqui um amigo com um Palm novo, um Zire 71, e um celular com acesso à internet. Isso está se tornando cada vez mais barato e comum. Conheço também uma porção de empresas e instituições, entre elas uma série significativa de TeleCentros e órgãos públicos, que estão adotando Linux como sistema operacional para desktops. O Google hoje é responsável por 90% do tráfego que meu site consegue de buscadores. É o primeiro colocado absoluto entre os buscadores. E conseguiu isso indexando semanticamente o conteúdo real dos sites. Praticamente todas as plataformas web estão oferendo suporte a XML e apostando na idéia de webservices.

Quem segue os padrões web não precisa ter medo do futuro. Não importa que browser vai ser o mais usado daqui a dois anos, que tecnologia vai estar na moda ou de onde as pessoas vão estar usando a internet. Seu site estará lá, leve, acessível, atual e útil.

Principais problemas em consultoria de banco de dados

Olá pessoal. Na coluna desta semana abordarei algumas situações críticas nas quais me deparei durante algumas consultorias de banco de dados.

Infelizmente tenho encontrado vários problemas durante as consultorias nas quais participo. Algumas vezes encontro problemas técnicos, outras vezes problemas de coordenação/gerencialmente e até problemas políticos. Por isso resolvi contar nesta coluna alguns dos principais problemas que já encontrei durante a minha experiência como consultor na área de banco de dados. Já havia entrado neste tópico em uma das minhas colunas anteriores, chamada de Pimp My Database, mas desta vez não descreverei uma situação específica.

A idéia aqui é mostrar quais os principais problemas que eu encontrei, e não fazer uma crítica infundada. Geralmente estes problemas possuem soluções simples, porém é preciso primeiro a conscientização do impacto destes problemas no ambiente como um todo antes de procurar uma solução.

Cursor em trigger

Muitos desenvolvedores estão acostumados a trabalhar com cursores, ou seja, a maneira de se processar os dados de uma tabela linha-a-linha. Esta técnica pode fazer sentido em muitas situações relacionadas à programação, porém em 99% das vezes que ela é utilizada dentro do banco de dados devemos substituí-la. No que diz respeito à banco de dados, os cursores consomem muitos recursos, são ineficientes, geram locks desnecessários e tornam mais difícil a compreensão do código.

Como exemplo do qüão prejudicial isso pode ser eu cito o uso do cursores dentro de um trigger. Em geral isso acontece porque a pessoa que criou o trigger precisava realizar algum tipo de processamento para cada uma das linhas, como incluí-las em uma tabela de log. E como um trigger é disparado cada vez que uma instrução é executada tem-se uma perda de desempenho e recursos consideráveis quando se coloca um trigger dentro de um cursor.

Para substituir os cursores dentro de um trigger é preciso analisar o código e ver exatamente o que está acontecendo. Veremos um exemplo então. O código da listagem 1 apresenta um trigger que contém um cursor.

CREATE TRIGGER TRG_INS_T_CELULA ON T_CELULA FOR INSERT  
AS  
BEGIN

DECLARE @MAX_CELULA INT
DECLARE @CELULA_CODIGO INT

SELECT @MAX_CELULA  = MAX(CELULA_CODIGO)+1 
FROM T_CELULA

IF @MAX_CELULA IS NULL
 SET @MAX_CELULA  = 1

DECLARE C CURSOR FOR
SELECT CELULA_CODIGO
FROM INSERTED

OPEN C

FETCH NEXT FROM C 
INTO @CELULA_CODIGO

WHILE( @@FETCH_STATUS  = 0)
BEGIN
 UPDATE T_CELULA
 SET CELULA_CODIGO  = @MAX_CELULA
 WHERE CELULA_CODIGO = @CELULA_CODIGO

FETCH NEXT FROM C 
INTO @CELULA_CODIGO

END

CLOSE C

DEALLOCATE C

END

Listagem 1. Trigger de inclusão com cursor.

O que o trigger TRG_INS_T_CELULA faz é obter o maior valor da coluna CELULA_CODIGO e depois somar um. Caso a tabela esteja vazia o código atribui o valor 1 para a variável @MAX_CELULA. Em seguida é feito um cursor para ler linha-a-linha todos os valores da tabela INSERTED. Dentro do loop a instrução UPDATE é utilizada para atualizar as linhas da tabela T_CELULA.

Para trocar o cursor do trigger da listagem 1 basta lembrar que podemos utilizar mais de uma tabela na cláusula UPDATE, ou seja, podemos substituir todos os upates realizados por apenas uma instrução que fará um join com a tabela INSERTED, que existe apenas dentro do trigger. Além disso podemos utilizar a função ISNULL() para verificar se há alguma linha na tabela quando desejamos obter o maior valor. Na listagem 2 temos o trigger sem o cursor, porém mantendo a funcionalidade original.

/**************************************************************/      
/* NOVA VERSAO DO TRIGGER TRG_INS_T_CELULA
Descrição: Ajustes de desempenho: retirada de trigger */      
 ALTER TRIGGER TRG_INS_T_CELULA ON T_CELULA FOR INSERT
AS
BEGIN
 -- TROCA DE CURSOR POR UM UPDATE COM JOIN
 UPDATE T_CELULA
 SET
     CELULA_CODIGO = (
SELECT ISNULL(MAX(CELULA_CODIGO)+1,1) FROM T_CELULA
)
 FROM T_CELULA A, INSERTED B
    WHERE A.CELULA_CODIGO = B.CELULA_CODIGO
END

Listagem 2. Código fonte do trigger TRG_INS_T_CELULA sem cursor.

Constraints FK duplicadas

Em uma consultoria recente me deparei com a seguinte situação: um relacionamento entre uma chave primária e uma chave estrangeira estava duplicado. Ou seja, haviam duas constraints de chave estrangeira que tinham o mesmo propósito! Procurei tentar entender qual a lógica disto mas não fui capaz. As duas constraints estavam iguais e, fora o nome, não havia nada que diferenciava uma da outra.

Em outras palavras não havia necessidade da segunda constraint. Provavelmente isso aconteceu porque os desenvolvedores, ou quem criou o modelo, efetuou a operação de criação de constraint duas vezes ou algo assim. Além de tornar o modelo mais difícil para se compreender, repetir esta constraint pode causar problemas de desempenho durante a modificação das linhas na tabela. Neste caso a solução mais fácil foi procurar os relacionamentos duplicados e excluí-los o mais rápido possível.

Uso ineficiente de índices

O uso ineficiente de índices é outra situação que encontro com freqüência quando presto consultoria. Muitos desenvolvedores, e mesmo DBAs, criam índices de forma errada, desnecessários, e muitas vezes sem nenhum critério. Este tipo de atitude gera problemas de desempenho, consumo excessivo de recursos, falhas e pode até fazer com que o banco de dados inteiro fique indisponível.

Para citar um exemplo, houve uma vez que eu estava procurando o motivo pelo qual um banco de dados estava crescendo de tamanho de forma anormal, algo como 500 MB por semana, sem que houvesse uma razão aparente.

Analisando os dados do modelo pude perceber que a maior tabela ocupava mais da metade da base, com 20 GB e 40 milhões de linhas. Destes 20 GB que a tabela ocupava aproximadamente metade era ocupada apenas pelos índices, pois a esta tabela tinha 14 índices incluindo a chave primária. Analisando mais profundamente descobri que dois dos índices foram criados para colunas que continham apenas valores NULL e que não eram utilizados em nenhuma consulta. Resultado: estes índices estavam ocupando espaço desnecessário e prejudicavam o desempenho quando alguma linha era inserida, alterada ou excluída da tabela.

Senha do login sa em branco

Neste item temos uma questão de segurança. Não raro encontro diversos ambientes de bancos de dados com problemas de segurança e vulneráveis a ataques. Isso geralmente acontece porque os responsáveis pela segurança ou não sabem corretamente como implementá-la ou simplesmente acabam concedendo direitos além dos necessários para um usuário ou login.

O SQL Server 2000, em particular, sofre do problema da senha do login sa em branco. Graças a um check box na instalação é possível deixar a senha do principal login administrativo do SQL Server em branco tornando o banco de dados e todo o ambiente vulnerável. Além disso, o SQL Server 2000 não faz diferenciação entre letras maiúsculas e minúsculas na senha, característica que foi modificada sensivelmente no SQL Server 2005.

Isso me lembra de uma consultoria na qual fui chamado para acompanhar a implantação de um novo sistema. O responsável pela implantação disse-me que só poderia instalar os componentes se a senha do sa estivesse em branco. Na hora protestei dizendo que isso seria uma grande brecha de segurança. Sugeri a criação de um novo login ou mesmo deixar a senha do sa em branco apenas durante a instalação do sistema. Mas não teve jeito: graças a este requisito indesejável tive que deixar a senha do sa em branco senão o sistema não poderia ser instalado. Isso deixa claro a falta de preocupação com a segurança do banco de dados por parte de alguns profissionais.

Abandono de servidor

O abandono e a falta de monitoria e manutenção é um assunto muito sério que as empresas nem sempre se dão conta. As vezes parece que os profissionais pensão que um banco de dados é como uma planta: deixam ele em um canto e esperam que ele faça o seu trabalho sozinho e sem manutenção. As vezes até esquecem de molhar a planta, ou seja, verificar como anda o status do banco de dados e dos seus recursos.

Devido às características de diversos sistemas é importante sempre monitorar de perto um banco de dados. Pode ser para evitar que o disco seja preenchido totalmente ou para checar se o servidor está consumindo 100% do processador por causa do banco de dados, não importa. O que deve ser colocado como prioridade é a observação do banco de dados periodicamente para evitar ser pego desprevenido em caso de problemas.

Já cheguei a acessar um servidor remotamente e notar que há pelo menos seis meses ninguém fazia uma faxina periódica no servidor. Isso quer dizer que ninguém verificava se os logs estavam com alguma mensagem de erro, se o Transacion Log estava cheio, se a rotina de backup era adequada, se algum job falhou, se era preciso fazer um expurgo na base e outras tarefas que não são essenciais para a operação, mas que precisam ser realizadas periodicamente.

Lentidão

Com certeza problemas de lentidão são o motivo número 1 para um consultoria em banco de dados. É comum encontrar problemas de lentidão que supostamente são causados pelo banco de dados em uma consultoria, o que geralmente faz com que a empresa procure um profissional específico para cuidar desta situação.

Um cenário típico: após um período de desenvolvimento um sistema foi implantando na empresa com relativo sucesso. Algumas modificações aqui e ali e o sistema está sendo utilizado sem grandes problemas. Após um tempo considerável a aplicação começa a demorar um pouco. Os usuários notam mas não reclamam. Com o tempo a situação vai piorando: a tarefa que era executada quase que instantaneamente agora leva minutos. Os desenvolvedores são notificados e fazem pequenas modificações na aplicação ou logo de cara sugerem a compra de um hardware melhor. Geralmente isso melhora um pouco ou quase nada o desempenho, mas em poucos dias a situação se agrava. Chega um pouco que a lentidão do sistema começa a atrapalhar a operação da empresa.

Já cansei de encontrar cenários como acima. Talvez pela falta de preparo para realizar um tunning de banco de dados ou pela pressa por soluções rápidas muitas empresas simplesmente começam a se preocupar com desempenho apenas quando ele atinge um nível crítico, o que pode ser tarde demais. Em poucas palavras basta dizer que problemas de desempenho são o campeão de pesadelos (e também a principal fonte de trabalho!) para qualquer DBA ou consultor de banco de dados.

Péssima tipagem

Um problema que venho encontrando cada vez mais é a tipagem de dados errada. Esta questão envolve diretamente os desenvolvedores, programadores, analistas, modeladores, etc pois são eles os responsáveis pela criação dos tipos de dados das colunas de uma tabela.

Um exemplo simples: muitos desenvolvedores adoram o tipo de dados INT do SQL Server. Precisa armazenar um valor numérico? Bota o tipo de dados INT então! Nem que seja para armazenar a idade de uma pessoa, que raramente vai passar do valor numérico 100.

Esse é um erro com graves conseqüências. Primeiro porque escolher o tipo de dados errado vai gerar problemas de desempenho, consumo excessivo de disco, memória, processador e rede. Segundo porque modelar algo errado é um dos passos que leva a vários problemas na prototipação, programação, testes, implementação e treinamento. E terceiro porque isso dá um trabalho do caramba para resolver!

O meu conselho aqui é pensar muito bem antes de escolher o tipo de dados, pois isso é tão importante quando escolher qual tabela deve ser criada no modelo. Procurar se informar qual é o melhor tipo de dado assim como suas características vale muito mais a pena do que simplesmente escolher um tipo de dado baseado no conceito de que ou é texto ou é número ou é data.

Falta de estratégia de backup

Poucas coisas são mais aterrorizadoras do que não possuir uma estratégia de backup em ambientes que precisam de uma. Infelizmente já perdi a conta de situações nas quais me deparei com um ambiente em que não havia um backup confiável e que poderia ser utilizado.

Isso é particularmente preocupante porque na maioria das vezes em que alguém sugere o uso de backup é porque a situação já está desesperadora. Seja porque algum usuário cometeu um erro sério ou porque houve uma falha de hardware, o backup deve SEMPRE ser consistente, confiável e ficar a um passo de ser restaurado. Caso contrário é bem provável que uma situação que já esteja ruim torne-se pior ainda por não haver uma contingência adequada.

Ausência de um DBA

A ausência de um DBA é uma questão cultural, no meu ponto de vista. Se muitas vezes encontro a realidade onde já é difícil a contração de um desenvolvedor para um projeto imagina então contratar um DBA, que geralmente é profissional raro no mercado e com um valor hora alto.

Bom, basta dizer que confiar bancos de dados gigantes na mão de desenvolvedores que conhecem um pouco do banco é uma péssima idéia. Não querendo desmerecer os desenvolvedores, mas na minha experiência de consultoria tenho encontrado muitas equipes de desenvolvedores atolados de trabalho e com responsabilidades muito aquém do que foram inicialmente combinadas. Querer colocar a responsabilidade de um banco de dados grande e complexo na mão de um desenvolvedor cujo principal objeto é programar é a receita para se dar mal. Por isso creio que a partir de um certo volume de dados, e de acordo com a complexidade do sistema e do banco de dados, é crucial contar com a presença de ao menos um DBA na equipe, seja ele permanente ou não.

Falta gritante de recursos de hardware e software

Hardware é caro. Hardware para servidor de banco de dados então é mais caro ainda. Infelizmente esta afirmação é uma constante que dificilmente vai ser modificada nos próximos anos. Por isso na maioria das vezes em que é necessário investir em hardware já fico preparado para montar uma defesa com argumentos, dados, estatísticas e evidências conclusivas de que realmente é necessário realizar um upgrade ou montar uma nova plataforma para atender as necessidades.

Além disso também já encontrei problemas com o custo relacionado com software. Deixando de lado a questão da pirataria, várias vezes tive a oportunidade de me deparar com locais onde a edição do SQL Server não era a edição mais recomendada para o ambiente em que ele estava sendo utilizado. Motivo? O custo envolvido na compra da edição correta. Infelizmente o máximo que podemos fazer nestes casos é provar com argumentos sólidos que é preciso investir no software também, além é claro de cruzar os dedos e esperar que isso faça algum efeito.

Bom, estas foram apenas algumas situações ruins nas quais encontrei durante consultorias de bancos de dados. Espero que ao descrevê-las poucas pessoas se identifiquem com a situações, pois caso contrário a minha hipótese de que pouca atenção vem sendo dada à área de banco de dados irá se confirmar.

De qualquer maneira, espero que a exposição de problemas como estes possam trazer à tona a gravidade de algumas situações e que esta discussão forneça um incentivo para que os responsáveis procurem soluções para os problemas o mais rápido possível.

Um grande abraço e até a próxima pessoal.
Por Mauro Pichiliani

Google lança hosting grátis para aplicativos

App Engine é um serviço gratuito para desenvolvedores que podem hospedar seus projetos e usar a infra-estrutura do Google. Trabalha com aplicativos em Python e concorre com serviço similar da Amazon. Você usaria?
O Google acaba de lançar um serviço chamado App Engine. A idéia é ser um serviço completo de hosting, banco de dados e servidor de arquivos com infra-estrutura e tecnologias do Google, com a oferta de uma boa quantidade de recursos gratuitos para desenvolvedores criarem seu aplicativos.
O servidor aproveita o famoso cloud computing do Google, database com BigTable e storage com o Google File System. Todas estas tecnologias são utilizadas pelo próprio Google em seus aplicativos para que sejam rápidos e facilmente escalonáveis.
Escalabilidade sem preocupação
A novidade resolve um grande problema que startups têm: como gerenciar um servidor quando se faz sucesso de uma hora para outra. Em um dia eu tenho um punhado de usuários, no outro dia eu tenho milhões, meu servidor cai, eu fico desesperado e perco os cabelos e os usuários.
Com o App Engine o desenvolvedor pode preocupar-se só em desenvolver o seu programa e deixar toda a parte de infra estrutura para o Google.
Modelo de negócio briga com Amazon
Na versão "preview" lançada, os aplicativos não podem usar mais do que 500 MB de espaço em disco, 200 milhões de megaciclos/dia de CPU, e 10 GB de banda por dia. Vocês sabem que isso não é pouco.
Outro limite é que, por enquanto, somente aplicativos desenvolvidos em Python podem rodar no servidor. Google diz que a estrutura toda é feita para suportar qualquer linguagem e que vai aos poucos liberar novas linguagens.
A idéia, quando o produto estiver pronto, é vender mais recursos para os desenvolvedores, conforme a demanda de seus aplicativos. Exatamente o que a Amazon faz com seus serviços de Storage e Cloud Computing.
A concorrência entre os dois agora será uma briga boa de assistir. Enquanto o Google entra no mercado com uma afinidade muito grande com os desenvolvedores, a Amazon já é o líder deste mercado e tem vários cases muito interessantes para mostrar.
APIs do Google para tarefas mais comuns
Além de tudo isso, o App Engine ainda dá acesso a APIs do Google para fazer tarefas comuns como autenticação de usuários e envio de e-mails. Ou seja, eu poderei usar minha conta do google para fazer login em um aplicativo hospedado no App Engine.
O serviço tem também uma ampla gama de análises de uso do servidor, de banda, de ciclos, etc, algo como o Google Analytics mas voltado para o servidor em si e não para o conteúdo. Eles dizem que estes são só os primeiros features, que ainda não estão nem perto de ter todos os features planejados para o serviço.
Isso deve mudar o cenário?
Com isso, desenvolvedores têm um custo a menos para lançarem um aplicativo. Será que isso muda o cenário da web 2.0? Será que terá um impacto grande? Você usaria o serviço?

Por Gilberto Alves Jr.