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!
terça-feira, 19 de maio de 2015
quarta-feira, 13 de maio de 2015
SMOOTH o sonho das consumidoras e consumidores...

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-
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
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.

Bom, precisamos terminar a 'venda' do produto, que você pode obter por meio das nossas consultoras de plantão.
Marcadores:
design responsivo,
programação avançada,
smooth
domingo, 10 de maio de 2015
Esqueci a senha...
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.
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.

quinta-feira, 7 de maio de 2015
Fim da Fila

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 eachorder (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.
Marcadores:
boas práticas,
desempenho,
programação avançada
Assinar:
Postagens (Atom)