Bush It!

Um amigo postou um vídeo, e através deste vídeo, garimpando, cheguei a estes outros abaixo.

Vejam estes vídeos:

Crítica muito boa.


E para representar a atual situação do País. É... hoje só amanhã!



"É mole?! É mole mais sobe..."

Ahhhh e pra quem não conhece, os caras são os tais de: Os Barbixas

C++ Sucks! (by Linus Torvalds)

Primeiro pensamento: "Ahhhh que facada!"

Alguns amigos irão dar pulos mais altos que eu a hora que lerem isso, especialmente um =)

Mas enfim, este post me levou a esta discussão, que tornou-se mais "quente" quando Linus Torvalds (é... aquele do tal do GNU/Linux) respondeu o seguinte:

C++ is a horrible language.

Ele continua:

In other words: the choice of C is the only sane choice. (...)
I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices.

E diz mais:

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.

Achei que este tipo de "flame war" sobre linguagens, IDEs, times de futebol, etc... só acontececem entre os mortais =)

Deixo duas frases:
"Use a melhor ferramenta para o trabalho"
"Para quem só tem um martelo, todo parafuso parece prego."

Grupo de Usuárias de Programadores

Este post é apenas uma homenagem a este grupo ou GUPRO =) Eu vi esses dias no Blog do Urubatan.

Demais! Parabéns! Muito legal todos os posts!

E o testesinho para saber "How Nerdy you are" também é bem legal.

Este foi o meu resultado:



Bom, ao menos meu resultado foi menor que do urubatan =) UFA! =) hahahaha

SCEA - JEE5 Beta Exam

É... descobri só hoje (já meio atrasado) que abriu a nova prova SCEA atualizada à nova versão JEE5. E ela está na versão Beta, o que por tradição da Sun é FREE. Já que é "de grátis" então vamos fazer né =)

Então, se você quer se arriscar nesta certificação, ao invés de investir na SCWCD, SCBCD e tantas outras... invista seu tempo nesta =)

As inscrições abriram no dia 20/09 no site da prometric. Então, logue lá, e entre na opção Schedule an Appointment, vai pedir algumas coisas, e depois irá aparecer uma caixa com a certificação que vc quer fazer. A SCEA Beta JEE5 é a última opção.

A prova I deve ser feita até dia 20 de outubro, ou seja, muito pouco tempo para estudar =) E são 160 questões, e o candidato terá 4h para fazer a prova. Como a prova é beta, tem muita questão mesmo, e a cada questão tem um espaço para um comentário sobre a questão.

O prazo para a fase II começa em Novembro e termina em Dezembro juntamente com a parte III.

Então, boa sorte a quem for se aventurar. Segue abaixo alguns links, que podem ajudar nesta empreitada:

Site Oficial

Link de divulgação no JavaRanch, com algumas informações
MailGroup criado para a prova
NYCJAVA - SCEA Study Group

Se alguem souber de algum material interessante e/ou informação útil, favor postar aqui!

Valeu!

Clustering de Jboss - Parte 1

Há algumas semanas atrás eu estava estudando a melhor arquitetura para uma nova aplicação que estamos fazendo. Esta aplicação a princípio deveria por obrigatoriedade rodar clusterizada e distribuida, sendo ela dividida em algumas partes distintas. OK, pensei comigo mesmo, a melhor maneira de fazer isso, é com EJB mesmo, não vai ter como fugir desta vez.

Embora, EJB tenha um certo overhead na parte de lookup e tudo mais, me pareceu a melhor saida no momento mesmo. E analisando melhor a aplicação, a melhor saida ainda, era usar JMS. Devido ao Assincronismo da aplicação. Enfim, para isso tive que estudar certinho como é que o jboss trabalha com o cluster dele, e como fazer funcionar, além de ter que verificar como fazer para que os MDBs e a Fila ficassem clusterizados também.

Então, resolvi postar aqui como fazer tudo isso funcionar, pois a documentação do JBoss não é lá grandes coisas, embora tenha ajudado muito, e o material na internet não é tão abundante assim.

Colocando o Jboss em Cluster

Bom, para utilizar o Jboss em cluster, primeiro é claro você precisa de 2 máquinas ligadas em rede. Da até pra utilizar na mesma para fazer testes, mas da muito empenho, vai por mim, mas se você precisa mesmo utilizar, você precisa trocar TODAS as PORTAS que o Jboss usa, que não são poucas, e para isso precisa garimpar nos milhares de .xml que ele tem (boa sorte =]). Este post pode te ajudar em algumas, porém ele fala de Jboss rodando na configuração default, mas na all que é onde ele já tem as configurações de cluster, tem muito mais portas =).

Então temos, 2 máquinas ligadas em rede e conversando entre si. Simplesmente o que precisamos fazer para colocá-las em Cluster é levantar o jboss de uma máquina e depois de outra, utilizando a configuração all, assim:

run.bat -c all -b 10.77.6.26 (coloque o ip da maquina aqui)

Como pode se notar, o parametro -c indica qual configuração ele vai utilizar, e o parâmetro -b qual será o IP utilizado para identificar a máquina. Caso não seja passado o ip, o default assumido será 127.0.0.1.

Quando "subir" um jboss você notará nas mensagens de log que ele reconheceu que é o primeiro nó do cluster, ou que ele não conseguiu achar nenhum outro nó "no ar" para formar um cluster. Este Jboss estará rodando OK, porém sozinho esperando encontrar algum outro nó para formar o cluster. O próximo passo então, é subir o outro Jboss. Na hora que ele estiver subindo, irá mandar uma mensagem em multicast (ip=228.1.2.3 porta=45566 via UDP) o servidor que já está no ar irá receber esta mensagem, e então inicia o "handshake" e pronto, eles entram em cluster. Tudo isso será mostrado no log do seu jboss, então para isso deixe o cosole aberto e vá vendo as mensagens que vão aparecendo. Irá aparecer algo assim para o primeiro nó:

16:12:40,828 INFO [DefaultPartition] Number of cluster members: 1
16:12:40,828 INFO [DefaultPartition] Other members: 0
16:12:40,828 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
16:12:40,828 INFO [DefaultPartition] State could not be retrieved (we are the first member in group)

Você pode inclusive ter vários "clusteres" em uma mesma rede, basta para isso mudar o nome do cluster (no arquivo /server/all/deploy/cluster-service.xml), que por default vem com o nome de DefaultPartition. Para verificar se os seus Jboss estão em cluster, além de ver no console que o cluster foi formado, abra o jmx-console e procure por DefaultPartition e clique nele. Lá você encontrará os IPs das máquinas que estão fazendo parte do Cluster na opção CurrentView.

Vale a pena ressaltar que a comunicação padrão entre os nós do cluster é feita via UDP com Multicast. No meu caso, eu enfrentei problemas para que os nós se achassem, havia muita demora para formar o cluster, e o farm-deployment raras vezes acontecia. Por um problema de Windows (eu li em algum lugar alguma coisa assim), ou do elemento de rede entre os pontos (a nossa rede é uma bosta), não sei bem o que poderia ser, mas não me surpreenderia com nenhuma das possibilidades. O que me deu esta luz, foi justamente este post, ao menos ele estava tendo o mesmo problema que eu. Lembre-se disso caso esteja tendo problemas, isso pode te economizar muito tempo =)

Enfim, o que tive que fazer para funcionar foi alterar o protocolo de UDP para TCP. Fiz isso no arquivo /server/all/deploy/cluster-service.xml). Logo no começo do arquivo existe uma tag chamada < attribute name="PartitionConfig" > , e dentro desta tag tem um outro elemento chamado < Config >. O que vem habilitado (descomentado) por padrão é o UDP, e (graças a Deus) logo abaixo vem a configuração de TCP comentada. Então o que precisa fazer é descomentar um e comentar o outro. E alterar o elemento TCPPING para que ele contenha os IPs dos principais nós do seu cluster, os quais ele acha no começo, depois você pode incluir outros. Então ficaria algo mais ou menos assim:

< tcpping initial_hosts="${jboss.bind.address}[7800],10.77.6.40[7800]"

Sendo que o próprio jboss substituirá jboss.bind.address pelo seu endereço de IP, e o ip que aparece ali, é o IP do outro nó do seu cluster, ou quantos nós você tiver.


Farm Deployment

Outro aspecto interessante do JBoss, é o deployment em farm. Que nada mais é, você precisar apenas se preocupar com um dos nós, e este cuida de replicar o seu estado para os outros. Então, basta apenas você ter sua aplicação publicada em um dos nós e este copiará a todos os outros a aplicação. O mesmo acontece quando você fizer undeploy de uma aplicação em um dos nós.

Para publicar uma aplicação no farm, basta você copiá-la para o diretório /server/all/farm ao invés de copia-la para /server/all/deploy como é o padrão. Caso você copie para o diretório deploy a sua aplicação será publicada apenas na máquina em questão e o farm-deployment não será executado.

Conclusão

Eu não esperava, mas este será o primeiro de uma série de 3 posts (possivelmente), pois senão iria ficar um post muito grande, e eu não gosto de ler posts muito grandes. Então pretendo nos próximos posts falar sobre como configurar sua fila JMS no esquema de High Availability. E ainda uma aplicação de exemplo para testar este esquema. E como deixar seu Jboss mais "tunado" =)

Até!

[edited]
O Paulo Jerônimo tem um screencast bem interessante sobre como rodar mais de um jboss em cluster na mesma máquina.