Quase um Everest!

Estamos 'quase' no topo do mundo! ou seja, mais ou menos no topo do Monte Everest, mas mesmo assim feliz e fincando nossa bandeira, e não faço isso sozinho, estou acompanhado de nossos 8405 visitantes/mes. Um numero absurdamente grande diante das nossas humildes pretensões, e somente alcançado devido a paciência e curiosidade dos nossos amigos do blog.

A todos que me ajudaram a levar todo equipamento para o topo, meu muito obrigado!

SMOOTH o sonho das consumidoras e consumidores...

Estava procurando na web e encontrei a solução que faltava para tornar a pele mais macia, lisa, bonita, leve,...., chama-se SMOOTH DREAM... Ta no post errado? acho que não, pois todo desenvolvedor Genexus Web hoje esta 'sonhando' com o produto: SMOOTH, aquele que deixa sua interface web exatamente com essas características: macia, lisa, leve, bonita,... A questão é que não se trata de uma pastinha, um pozinho, e sim do mais novo recurso da EV3. Aqui exploraremos um pouco da capacidade do Web User Experience = SMOOTH do Genexus Evolution 3 e seu impacto nas nossas telas.

Smooth revoluciona a maneira com que a pagina Web é carregada, e o seu objetivo principal é reduzir ao máximo a quantidade de bytes trocados entre o servidor e o browser, e como consequência sua aplicação gera interface com maior desempenho.

Modo Compatível

Nas versões anteriores do Genexus, Web User Experience = Previous Version Compatible, ao se clicar em um evento de servidor, um botão Confirmar, por exemplo, toda página era reconstruida, fazendo com que qualquer ação que o usuário gerasse, causasse lentidão, por conta do processamento no servidor, transmissão de dados pela internet e a recarga no browser.

Vamos a um exemplo, imagine a interface abaixo, com três controles grids. Ao se gerar um evento no Grid1 (cidade), clicando no nome da cidade por exemplo, isso faz com que o Grid2 (clientes) seja recarregado. No modo tradicional, leia-se Ev1, Ev2, e anteriores, o resultado seria carregar: A Master Page, a pagina web toda com o Grid1, Grid2 e Grid3, incluindo ainda nesta conta, tudo que tem na Master Page como a construção do menu de opções, os controles de segurança, ou seja, um simples clique no Grid1 gerava um custo altissimo.

Neste mesmo exemplo, somente para termos uma noção dos valores, abrindo o Fiddler para recuperar a comunicação entre o browser e o servidor teríamos uma visualização de tudo que foi transmitido, ou seja todos os elementos necessários na interface, incluindo HTML, CSS, IMAGENS, JS, ou seja, tudo. E claro o browser deveria receber e recalcular tudo para colocar no devido lugar.

Em dimensões numéricas seria algo em torno de: 47.064 Bytes, num tempo estimado de 525 microsegundos (para localhost).

Neste modelo todos os eventos são executados na sequencia:
START-

-EVENTO USUARIO-REFRESH-LOAD

Smooth

Passando um pouco do produto de beleza, ou seja, selecionando a opção: Web User Experience = Smooth, esta mesma interface geraria um modo de navegação totalmente diferente, nada seria recarregado na interface a menos que o próprio desenvolvedor programe comandos REFRESH nos componentes. Desta forma seria necessário que ao interceptar um clique no Grid1, que o Grid2 seja atualizado por meio de um comando Grid2.Refresh(), tal qual apresentado a seguir.

Event Grid1.OnLineActivate
    &CidadeId =CidadeId
    Grid2.Refresh()
endevent

Os eventos neste modelo ficam limitados a

- EVENTO USUARIO

Sabe o resultado disso? somente o Grid2 será atualizado, todo resto da interface permanecerá do mesmo jeito.  A comunicação será limitada a uma chamada AJAX ao servidor para obter a carga do grid2. No nosso caso reduzindo a para apenas 1.452 bytes. O Fiddler devolveu míseros 31 milissegundos neste exemplo.

Mas já da para tirar uma conclusão, você prefere  uma comunicação que transmita 47.064 Bytes a cada retorno ao servidor, ou a carga inicial completa e em seguida chamadas menores com aproximadamente com 3% desse total. E melhor, sem reconstruir master page, recarregar menus e outros penduricalhos da interface?  Não precisa nem me responder, já sei a resposta.

Bom, precisamos terminar a 'venda' do produto, que você pode obter por meio das nossas consultoras de plantão.

Esqueci a senha...

Esqueci praticamente todas as minhas senhas, e o mais engraçado é que estou muito feliz por isso ter acontecido, porque de fato esqueci a senha da minha conta de email, da minha conta no sistema, do banco de dados, do internet banking, praticamente todas.  Quanto tempo isso não acontece com você? O evento que causou isso foram 20 dias de ferias bem tiradas em que pude conhecer e desfrutar dois países Argentina e Chile.

Apos 10 anos sem de fato tirar fėrias, 20 dias sem computador, internet, celular, skype e whatsapp causaram um efeito ótimo, esquecer as coisas sem importância que definitivamente carregamos nesta vida e que só percebemos que de fato não importam quando ficamos de fato sem, e não sentimos falta. Desligar-se da internet, desligar-se do trabalho, conhecer lugares fantásticos, outras pessoas, povos, costumes, comer na rua, ver o dia passar, ver o por do sol, andar de moto faz um bem danado para nosso cérebro.

Quanto a viagem vou dizer uma coisa, os argentinos não são arrogantes, ao contrário são um povo muito educado, acolhedor e simpático.  Os chilenos também, alguns muito brincalhões, mais a maioria age profissionalmente. Mas confesso que ainda não estou muito tentado a ter uma camisa do Boca, ou do River, cada um no seu quadrado digamos.

Só tenho um problema agora, ler os 400 emails pendentes que ficaram para traz por conta desses dias, mas fazer o que, é o preço que pagamos.

Ah, e quanto a parte do Genexus nisso tudo, ... Não se esqueça de incluir no seu sistema um programa de recuperação de senhas, para usuários afortunadamente 'esquecidos' como eu, rs.

Fim da Fila

Para tabelas em que se optou não utilizar o autonumber para gerar o valor da chave primaria numérica, e claro incremental, temos algumas saídas para obter o ultimo valor registrado.

Como a adoção do algoritmo depende de uma opção do próprio desenvolvedor, melhor estudar os modelos, que apresentam características distintas em termos de complexidade de programação e também desempenho, para que possamos optar por uma solução eficaz.

Para testar os modelos realizei um teste em uma tabela com 9000 registros, e uma única interface que implementa os três métodos de forma a manter a mesma regularidade de operação, e também para se obter uma medida de desempenho, através da medição do tempo de resposta. Esta medição foi realizada marcando-se o tempo entre o inicio da chamada ao servidor até o retorno completo da resposta ao navegador, portanto, não referem-se especificamente ao algoritmo em si, mas ao contexto da pesquisa em uma interface real, e para garantir um numero mais amadurecido descartamos o maior e o menor valor auferido, e calculamos a média da série, e os resultados foram:

1) Usando a Fórmula MAX

    &ClienteId = max(ClienteId) + 1

Nesse modelo, uma fórmula MAX aponta para a tabela alvo, e retorna o valor maximizado do identificador, ou seja, o maior indicador inserido na tabela, em outras palavras, o último registro.  Na media este modelo gerou um tempo de 6,3 milissegundos para a tabela de 9000 registros.

2)  Percorrendo a tabela toda

    for each
        &ClienteId = ClienteId
    endfor
    &ClienteId+=1

Neste, o que temos é um for each que percorre toda a tabela, e como a tabela é ordenada pela chave primária em ordem crescente, o último registro define o último identificador. Este foi o pior modelo, pois na media gerou um tempo de 56,3 milissegundos.

3) Ordenando e pegando o ultimo registro

    for each
    order (ClienteId)
        &ClienteId = ClienteId
        exit
    endfor
    &ClienteId+=1

Neste modelo, pega-se o último registro da tabela por meio da ordenação do identificador em ordem decrescente e um exit que encerra o laço já no primeiro registro recuperado.  Este modelo apresentou o melhor desempenho com um tempo de 5,3 milissegundos.

Portanto, se você percorre a tabela toda para obter o ultimo identificador gerado, você esta gastando uma energia imensa do processador + memoria para alcança-lo, aproximadamente 10 vezes mais, se comparado com os outros dois outros métodos, que apresentam desempenhos semelhantes.

Resumo: Tempo em milissegundos

Método 1	6,333333
Método 2	56,33333
Método 3	5,333333

Analisando a proposta 1) e 3) observamos que apesar da primeira perder alguns milisegundos, é uma forma bem interessante pois o código é mais simples e muito mais sintético, ou melhor, a que apresenta o melhor custo x beneficio.

Nos pequenos detalhes está a qualidade.