Introdução

TDD e BDD na prática em apps Java EE, com JUnit, Arquillian, Selenium e Cucumber é o título do tutorial que submeti ao evento Agile Brazil 2013. Nesse tutorial, minha proposta é oferecer aos participantes os conceitos fundamentais, numa visão prática e através do uso de excelentes ferramentas, um guia para a construção de aplicações Java EE através de práticas que dirigem o desenvolvimento tornando-as testáveis e aceitáveis para o cliente, sob o ponto de vista de negócios. Meu desejo é que, ao término desse tutorial, qualquer desenvolvedor Java EE ainda não "infectado por uma metodologia baseada em testes" passe a sê-lo. =)

Este post apresenta o roteiro do tutorial que cobrirei no tempo esperado para sua realização (80 minutos), caso ele seja aprovado. Contudo, ele vai além pois também faz links com outros artigos e materiais disponíveis sobre o assunto na Internet (alguns de autoria própria), apresenta código que utilizo para explicar de conceitos que demonstrei há alguns anos em outros artigos e, por fim, faz uma breve introdução ao Cucumber. Até o dia do evento, escreverei partes complementares a esse material, também na forma de tutoriais e/ou vídeos, onde explicarei exemplos menos triviais e mais reais que demonstrarão, ainda, o uso integrado de ferramentas como o Arquillian, o Selenium e o Cucumber. Independente da submissão de minha palestra ser aprovada, isso deverá ocorrer pois esse material também tem importância fundamental para um trabalho que venho desempenhando num cliente, nesse instante.

Este post é, na verdade, uma proposta de atividade que estou enviando para o evento FLISOL/DF, edição 2013. Esse evento é de fundamental importância para a comunidade que atua com software livre no Brasil, especialmente no Distrito Federal, onde desenvolvedores Java vem trabalhando com softwares dessa categoria há muito tempo, sejam eles disponibilizados pelos grupos Apache, JBoss, GlassFish, etc. Sendo assim, eu considero de extrema relevância uma apresentação na forma de oficina/tutorial que demonstre como uma aplicação, com requisitos corporativos, pode ser construída e implantada em produção, partindo da montagem do ambiente de desenvolvimento para uma equipe, até sua instalação num ambiente que garanta alta disponibilidade, tolerância a falhas e capacidade para atender alta demanda transacional. Tudo isto, é claro, utilizando softwares livres e a especificação Java EE 6.

Como explico no livro que estou escrevendo, o JBoss EAP 6.0.1 é construído com base nos fontes do JBoss AS 7.1.3. O binário do JBoss EAP pode ser baixado pelo site da Red Hat (mediante subscrição ou assinatura trial) e o do JBoss AS 7.1.3 não está disponível na página http://www.jboss.org/jbossas/downloads (leia detalhes sobre isto em https://community.jboss.org/thread/197780). Porém, os fontes de ambos estão disponíveis e, podem ser compilados. Em meu livro estou explicando detalhadamente os scripts que apresento neste post e o processo de compilação. Todavia, aqui, estou sendo breve e direto a execução dos scripts. Vamos lá...

Um arquivo kickstart é muito útil para a montagem de um ambiente de treinamento que utilize o Linux CentOS. Ele é utilizado pelo instalador Anaconda que lê seu conteúdo e, baseado nas configurações realizadas, automatiza todo o processo de instalação e configuração de distribuições como o RHEL, Fedora, CentOS e Oracle Linux. Após a execução do Anaconda, com pouco ou nenhum questionamento, está pronto o Linux que eu e meus alunos utilizamos no ambiente que darei aula.

Neste post, utilizando o arquivo kickstart ks, a vm-centos gerada em "Criando uma VM CentOS via linha de comando" e também o mirror construído em "Criando e utilizando um mirror local do CentOS" eu concluo a documentação das tarefas que executo para criar a VM que utilizo nos treinamentos de JBoss que ministro e que também cito no meu livro. Após concluir sua leitura, você terá toda a bagagem necessária para montar tua própria VM CentOS, de maneira automática e rápida.

Ninguém duvida que, em ambientes automatizados, a linha de comando seja essencial. Escrevendo meu livro sobre JBoss cheguei, também, a mais um motivo para apresentar a linha de comando: não tive paciência para ficar tirando screenshots das telas do VirtualBox enquanto criava a máquina virtual (VM) que utilizo nesse livro. Além disso, é chato inserir figuras em um documento e redimensioná-las adequadamente para explicar cada uma delas (é preciso ter uma paciência de designer gráfico pra estas coisas ;). Por isso, resolvi descomplicar, e economizar páginas, trabalhando com as linhas de comando que são necessárias para criar uma VM ao invés de explicar as telas que fariam os mesmos comandos no VirtualBox. ;)

Com a execução do script Bash vm-centos.create.sh eu crio a VM nos moldes que preciso para a execução de todas as atividades que preciso apresentar em meu livro. Neste post, apresento pequenos detalhes a mais sobre esse script.

Introdução

Em ambientes de treinamento eu costumava fornecer uma máquina virtual (VM) que eu dava o nome de VMCursoLadoServidor. Ainda continuo com esta mania (meus alunos copiam uma VM pronta) mas, agora, eu não a disponibilizo mais para download. Em vez disso, eu estou entregando um arquivo kickstart do CentOS para que você mesmo instale sistema operacional em uma máquina real, ou virtual utililizando teu software de virtualização preferido.

Este post explica como eu crio o mirror que disponibilizo em http://centos.pj. Esta URL é, como expliquei no post VirtualHost em Apache 2 No OS X Mountain Lion, um virtual host que disponibilizo no Apache instalado em meu notebook. Um mirror, por sua vez, é uma cópia de um site que possui pacotes, informações para instalação e ISOs de uma distribuição Linux (nesse caso, o CentOS).

Em próximos posts, mostrarei como construo esta VM no VirtualBox pela linha de comando através do utilitário VBoxManage e do uso de um arquivo kickstart. Mas, agora, vamos a construção do mirror. ;)

Eu utilizo o Dropbox para compartilhar arquivos com meus alunos pela Internet. E, como já citei em posts anteriores, utilizo o DropbProx que desenvolvi como uma forma de ter uma URL melhor identificada com meu domínio (Ex.: http://a.ladoservidor.com/equipe/index.html) ao invés de utilizar uma URL do Dropbox (Ex.: http://dl.dropbox.com/u/5689841/equipe/index.html).

O problema é que, em alguns ambientes de treinamento, o acesso a Internet é complicado, lento, restrito ou, no pior caso, tudo isto ao mesmo tempo. E, em situações onde utilizo distribuições Linux (Ex.: CentOS, Ubuntu) em que preciso baixar/instalar pacotes a partir da Internet, a adição de um repositório de pacotes local para ser acessado através do Apache instalado em meu MacBook é o que me salva.

Sem fazer a configuração de nenhum VirtualHost no Apache, para poder baixar um pacote do meu mirror CentOS via HTTP, o aluno utiliza uma URL como http://pj-macbookpro/~pj/CentOS/ (é simples habilitar o Web Sharing para ter esta URL funcionando rapidamente). Para isto, basta que o nome da minha máquina pj-macbookpro esteja configurado no arquivo /etc/hosts da máquina do aluno. Contudo, esta URL seria mais "bonitinha" se fosse http://centos.pj. Não acha? ;) Então, a solução é a configuração de um VirtualHost.

Algumas semanas atrás eu resolvi que era chegada a hora de atualizar o sistema operacional do meu Mac para o OS X Mountain Lion. Uma das coisas que foram alteradas após esta atualização foi que a opção Web Sharing sumiu. Utilizando-a era simples eu compartilhar qualquer arquivo simplesmente copiando-o para o diretório ~/Sites. Aviso: este post é destinado para usuários Mac que utilizavam esta opção e querem ter de volta esta alternativa para compartilhar seus arquivos. Independente do seu conhecimento em Apache (pode ser que você pense que estou falando de algum tipo de índio americano) ;) siga em frente na leitura!

PessoALL, boa tarde !

Uma situação comum é a necessidade de conectarmos uma aplicação cliente, seja ela um componente EJB, um componente Web, uma aplicação desktop ou uma aplicação de linha de comando, a um componente EJB hospedado em outro servidor através de sua interface remota.
Nesse post, iremos ver como fazer com que uma aplicação de linha de comando invoque um método de negócio em um componente EJB hospedado em um ambiente WebSphere 7.

PessoALL, bom dia !

Como vocês já sabem, amanha Terça 22 de Maio  vamos receber Stephen Chin para duas apresentações de JavaFX, uma em Brasilia e outra em Sobradinho.

Aqui no Lado Servidor, utilizamos o Git para compartilhar uma série de projetos. E buscávamos uma opção de repositório privado, e gratuito, onde pudéssemos manter um repositório remoto e central.

O GitHub oferece esse serviço, e muitos outros recursos excelentes. Entretanto nosso time é pequeno optamos por algo mais objetivo e sem incrementos. A opção escolhida foi o Dropbox. Sem mais delongas, vamos ao passo-a-passo:

Dica rápida!

1. Abra o AppleScript Editor;
2. Entre com o seguinte script (tudo numa única linha):
   

   do shell script "bash; HOME=/Users/$USER/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox"

   
   
3. File > Save As... escolha "Application" como o formato;

Ainda não utiliza o Dropbox? Clique neste link para criar sua conta!

__| Sessão de Q&E de Java EE 6, GlassFish, JavaME e Java SE 7 ao vivo |__

Na tarde da Terça-feira da próxima semana, os evangelistas da Oracle Arun Gupta e Roger Brinkley vão conversar diretamente com VOCÊ, independentemente de onde você esteja, e responderão suas duvidas sobre a plataforma Java.

Vamos transmitir ao vivo, pela Internet, uma sessão de perguntas e respostas sobre Java EE 6, GlassFish, JavaME e Java SE 7. Você envia suas dúvidas e perguntas para a lista de discussão do DFJUG, em http://www.grupos.com.br/grupos/dfjug ou pelo Twitter do DFJUG, em http://twitter.com/#!/dfjug e o Roger e o Arun responderão ao vivo suas perguntas.

Anteriormente no Apache Tomcat 5.5, existiam 3 diretórios que pudessem conter JARs de bibliotecas, para serem compartilhados entre as aplicações. Na época, era uma confusão.

À partir da versão 6, tudo ficou mais simples, com um único diretório: lib. Na versão 7 isto foi mantido. Porém pode ser o caso de se querer usar um diretório separado para bibliotecas de frameworks. Misturar isso com os JARs do Tomcat parece arriscado e insensato.

Ontem eu passei por um problema gravíssimo em ambiente de produção: pouco tempo após a aplicação entrar no ar, o diretório $JBOSS_HOME/server/${jboss.server.name}/tmp/vfs-nested.tmp/ estava estourando o espaço em disco destinado a partição em que o JBoss estava instalado e, em função disto, a aplicação começou a apresentar erros. Resultado: tivemos que retroceder num processo de migração até descobrir solução para o defeito :-( O que causou o problema?