A re-Introduction to JavaScript

Como vi no blog do Guilherme Chapiewski (oh nomezinho difícil de escrever=] ), resolvi postar aqui também este link para um ótimo artigo sobre JavaScript.

Como JS está muito em alta hoje, ele tem grandes chances de perder a má fama que ganhou ao longo dos anos, e pra quem tem estudado e aplicado ele hoje em dia, tem se surpreendido com o seu poder, e o pensamento mais comum é: "Bah! E isso sempre existiu!"

Então pra quem é desenvolvedor web, esta é uma leitura essencialmente obrigatória.

Um link interessante ainda para dar uma olhada é o da especificação da linguagem JavaScript pela ECMA.

Valeu =)

Java e C++ Benchmark

Devido ao fato de muitos amigos c-maniacs ficarem, ainda nos dias de hoje, baseando suas opiniões sobre Java nas velhas VM's 1.3-1.4 (no melhor dos casos), resolvi escrever este post. Não, não sou eu quem farei os benchmarks, mas fiz uma simples pesquisa no google sobre "c +java +benchmark" e dei uma lida em alguns artigos que falam sobre este tema, alguns de versões um pouco mais antigas da VM e outros sobre versões mais novas (1.5+).

Sei que este assunto é muito delicado e nada é decisivo, existem muitas variantes a serem consideradas e existem muitos testes diferentes. Mas o que realmente vemos, se quisermos ver é claro, é que o Java HOJE não é mais igual aquele antigo Java 1.1 de que tantas pessoas baseiam suas opiniões.

Well "Talk is cheap. Show me the code."

Antes de mais nada, vamos lembrar que não adianta querermos comparar um C com Java, mas sim C++ com Java, e é isso que a maioria destes benchmarks faz.

Para começar, utilizo o recente post de Paul Buchheit (criador e Lead Developer do Gmail), onde o primeiro parágrafo do seu post ele diz:

"A lot of people seem to be taking this post to be the "Ultimate C vs Java shootout". It's not. Performance is a very complex topic. My only real point is this: Java (which used to be slow) has reached the class of "fast languages". For the majority of applications, speed is no longer a valid excuse for using C++ instead of Java."

Em suma, ele diz que não é sua pesquisa o ultimato neste assunto de benchmark, mas que Java hoje, está na classe das "Linguagens Performáticas" e que "Velocidade ou Performance" não é mais desculpa para usar C++ ao invés de Java.

Ainda no post de Paul Buchheit, ele ressalta, que muitos testes atualmente contam o tempo de "start up" da VM como tempo de processamento, e simplesmente o que ele fez, foi fazer a iteração 3 vezes para cada código, e isto fez com que Java, fosse um pouco mais rápido que C na segunda e na terceira iteração.

Outro site que achei interessante, e que já tinha visto a uns 2 anos atrás, é este e ele tem um gráfico (abaixo) bem legalzinho sobre o desempenho em várias coisas, e isto usando a VM 1.4.2.



Outro ótimo artigo, que recomendo a leitura, é o do J.P.Lewis and Ulrich Neumann, onde além de colocar seus resultados, ainda desmistificam algumas coisas como:

1. GC is it worse... or better?
2. Run-time Compilation
3. Why is "Java is Slow" so Popular?

Não usei mais sites, porque acho que estes 3 satisfizeram minha idéia. Apesar de que em cada link deste post, existem muitos outros links para outros artigos sobre benchmark. E algo importante a ressaltar é "Não tome por verdade apenas 1 estudo sobre benchmark".

Concluindo, este não é um post que porá fim a questão, mas ao menos tenta abrir um pouco a mente dos "bitolados". Parar no tempo não é nem um pouco bom, ainda mais na nossa área. Entretanto, este também não é um post para dizer "Larguem C++ usem Java e sejam mais felizes", existe sempre a melhor escolha, e é impossível escolher o melhor caminho numa bifurcação se você só conhece um dos caminhos.

Garota de 7 anos cria um Pet Shop usando Java

WTF?!?!

Sim, foi o que pensei ao ver a notícia no InfoBlogs, e quando clico no link, me deparo com esta foto! Hahahaha muito boa =)

Créditos ao Rafael Benevides

Funcionalidade de Thread/Timer em JavaScript

Bom, digamos que o título não está exatamente bom, mas não consegui pensar em nenhum melhor =/

Ontem estava precisando fazer um lance parecido com o "Thread.sleep(numero);", ou melhor, acho que era mais parecido com o "Timer.schedule()", porém em JavaScript, e lembrei do tal conhecido método setTimeout(). Ele funciona, de uma maneira simplificada, assim:

<>
<>
 var contador=0;
 function testeTimeout()
 {
  document.getElementById('contador').innerHTML = contador++;
  setTimeout('testeTimeout()',1000);
 }
< /script>

< onload="testeTimeout()">
 < id="contador">
 < /div>
< /body>
< /html>

O que ele faz é "agendar" a execução do método passado no primeiro parametro, depois do tempo setado (que é em milisegundos) no segundo parametro. Ou seja, no exemplo acima ele iré executar o metodo testeTimeout(), e irá "agendar" uma próxima execução deste método para daqui a 1 segundo.

Um exemplo prático do uso disso seria fazer um agendamento de processamento de método (function) javaScript, para por exemplo, ficar fazendo um pooling via ajax em um determinado Serviço publicado pelo Application Server.

Outro aspecto interessante ainda sobre essa função é:
"Ela é blocante ou não?"
A resposta para esta pergunta é NÃO. Existem 2 situações onde ela poderia bloquear:
ter mais instruções no método logo abaixo da chamada de setTimeout
chamar outro método através de um evento qualquer por intervensão do usuário por exemplo.

Segue abaixo um exemplo para comprovar os dois exemplos. O timeout agora foi setado para 10 segundos para que seja possível a interação do usuário (clicar no botão):

<>
<>
 var contador=0;
 var contador2 =0;
 function testeTimeout()
 {
  document.getElementById('contador').innerHTML = contador++;
  setTimeout('testeTimeout()',10000);
  for(i=0; i<10; i++)
  {
   contador2++;
   document.getElementById('contador2').innerHTML =
    document.getElementById('contador2').innerHTML+' '+contador2;
  }
 }

 function alerta()
 {
  document.getElementById('contador2').innerHTML = 'outra função';
  alert('teste');
 }
< /script>

< onload="testeTimeout()">
 < id="contador">
 < /div>
 < id="contador2">
 < /div>
 < type="button" value="Alerta" onclick="alerta()">
< /body>
< /html>

Concluindo, você pode, por exemplo, deixar um "serviço em background" na sua aplicação e ele não irá interferir no funcionamento geral, dentre outras inúmeras funcionalidades.

------
Pode até não ser tão grande novidade, mas agora quando precisar algo já tenho os exemplos prontos aqui (o que é uma coisa que normalmente perco) =)

Programação Orientada a Gambiarras

Uma histórinha para iniciar a semana (ao menos aqui em SP) bem gostoso...

Sei, que a maioria já ouviu falar nisso, e outras ainda não. No entanto hoje de manhã, depois de um feriado prolongado no estado de SP, em que eu passei bebendo e dormindo, me deparo com uma situação que me lembrou este fluxograma:

Sim... isso mesmo. Logo cedo um email na minha caixa, falando que uma certa funcionalidade não estava OK num dos sistemas que herdei assim que entrei na atual empresa em que trabalho. Dai pensei comigo: "Bah... se eu mexer nessa bagaça vai dar mais merda! Vai começar a pipocar tudo! E dai sim EU serei o responsável!"
Uma conclusão que eu cheguei aqui, junto com um amigo, é que está aplicação está "fundamentada sobre gravetinhos", ou seja, vc tenta colocar um gravetinho a mais para sustentar a bagaça e o começa a quebrar os gravetinhos do outro lado...
É aquelas horas que vc grita: "PQP, assim não dá, vou refazer toda essa bosta aqui!", mas teu gerente te olha de longe com aquele olhar de "4 letrinhas" NTNB (No time, No Budget). =(

Bom, Boa semana a todos!
Desejem-me sorte!

--
Já que falei de POG segue o link para referência: http://desciclo.pedia.ws/wiki/POG