Configurando uma fila JMS no Glassfish 4.1.1

Eu realmente prefiro ter um certo conforto na hora de configurar aplicações e servidores então por isso prefiro fazer as coisas através de interfaces gráficas ou web. Antes que alguém resolva me julgar, eu não sou administrador de sistemas, então acho que não tem problema não saber todos os comandos de cabeça, já que não faço isso todos os dias.

No entanto de quando em vez nos esbarrasmos com uma situação em que não temos saída, a aplicação admin do Glassfish 4.1.1 está com um problema e não permite criar recursos pela tela, reporta uma exceção. A solução foi criar a fila de mensagens via asadmin (o console de linha de comandos que fica na pasta bin da sua instalação do Glassfish) e lá executar o seguinte comando:

asadmin> create-jms-resource
Enter the value for the restype option> javax.jms.Queue
Enter the value for the jndi_name operand> jms/Parametros
Administered object jms/Parametros created.
Command create-jms-resource executed successfully.
asadmin> 

O legal é que a aplicação vai te perguntando os valores que você precisa. Depois disso, se você quiser editar, a interface gráfica até funciona, o problema está na criação mesmo.

Configurando a biblioteca RCUDA em um laptop com Optimus

Então você tem um laptop com uma placa de vídeo nvidia, mas ela é a placa secundária, o que significa que ela não aparece diretamente para o sistema operacional. Em um sistema assim rodando o Linux temos uma solução que é instalar o pacote Bumblebee para ter acesso à placa e rodar aplicações que utilizem sua capacidade de processamento. Digamos que você resolve instalar o pacote RCUDA que permite que os programas escritos na linguagem R utilizem os recursos da placa de vídeo.

Let the games begin!

O principal problema que temos é que o acesso à placa é feito utilizando o programa optirun, outro problema é que se você nunca utilizou a linguagem R existe uma grande chance de não saber instalar os módulos extra, incluindo o RCUDA

De acordo com as informações no site do RCUDA você pode instalar diretamente a partir do arquivo zip, porém, você ainda precisa instalar o módulo do qual o RCUDA depende que é o RAutoGenRunTime, ele pode ser conseguido diretamente a partir do github aqui e você pode baixar o zip. Não tive sucesso em instalar diretamente a partir do zip, então o ideal é descompactar para uma pasta.

No entanto esse módulo depende de outro ainda, o bitops, que pode ser conseguido aqui, basta baixar o pacote de código fonte e a instalação pode ser feita diretamente do tar.gz.

Minha instalação foi feita em uma máquina com OpenSuse 13.2 64 bits utilizando a versão do Bumblebee do próprio repositório (os passos para Instalação e configuração podem ser vistos aqui, eu tomei o cuidado de atualizar a página com algumas informações referentes ao uso de CUDA), você precisa ter o pacote da linguagem R instalado no sistema, também instalei os pacotes de desenvolvimento da linguagem R. Estas instalações do R, fiz a partir dos repositórios do OpenSuse utilizando o YAST mesmo.

Uma outra coisa importante o RCUDA precisa do pacote LLVM, que foi instalado a partir do repositório do YAST também, na versão 3.5, o pacote do CUDA instalado, foi conseguido a partir da página da nvidia e foi o RPM para a versão 13.2 do OpenSuse que é o CUDA 7.0.

Para instalar vamos usar os seguintes comandos:

sudo R CMD INSTALL bitops_1.0-6.tar.gz

Para o RAutoGenRunTime, o módulo foi descompactado para uma pasta local e em seguida:

sudo R CMD INSTALL RAutoGenRunTime

Agora o maior problema, o módulo principal RCUDA precisa que a variável LD_LIBRARY_PATH seja definida para /usr/local/cuda/lib64, mas como todas as instalações precisam ser feitas como root esse passo precisa de um terminal root porque configurar o LD_LIBRARY_PATH antes do sudo não modifica o seu valor na sessão root que abrirá, então temos:

sudo su

depois:

export LD_LIBRARY_PATH=/usr/local/cuda/lib64:.

e finalmente:

optirun R CMD INSTALL RCUDA

usar optirun é fundamental porque durante a instalação do módulo é feita a compilação de um pequeno código para verificar a versão do CUDA SDK instalado na sua máquina (que deve ser igual ou superior a 5.0), em máquinas com tecnologia optimus, quando executamos um programa diretamente, a placa nvidia não é encontrada e o programa acaba retornando um erro.

Um dos maiores problemas que eu tive foi não conhecer a linguagem R e por isso não sabia como era a instalação e configuração de seus módulos, então inicialmente tentei executar o ./configure do pacote RCUDA. Foi assim, inclusive, que descobri os detalhes referentes a configuração da variável LD_LIBRARY_PATH e de que um programa era executado durante a instalação. Em minha primeira tentativa fiquei um tempo olhando para o resultado do ./configure procurando o Makefile para compilação sem sucesso, e aí achei as informações de como instalar os módulos R.

Para testar sua instalação basta ir até a pasta tests do diretório RCUDA descompactado e executar algum dos programas, por exemplo:

optirun Rscript device.R

Rscript é o comando para executar diretamente um programa R, neste caso device.R e sempre precisamos executar com optirun, porém não precisa mais ser em um terminal root.

Uma coisa importante é que para executar os programas, o RCUDA.so (gerado pela instalação do módulo R) precisa encontrar as bibliotecas do CUDA SDK então você precisa ter o LD_LIBRARY_PATH=/usr/local/cuda/lib64:. definido sempre, se reiniciar a máquina precisará configurar novamente. É claro que você pode também configurar essa pasta no sistema com uma configuração padrão do linux:

Editar o arquivo /etc/ld.so.conf como sudo e adicionar a linha /usr/local/cuda/lib64, depois executar:

sudo ldconfig

Agora é só programar em R utilizando as extensões do RCUDA para utilizar o poder de processamento da sua placa GPU.

Atualização:

Se você resolver usar o CUDA SDK 5.5 precisa modificar o arquivo checkSDKVersion.c dentro da pasta do RCUDA para chamar a função cuDriverGetVersion. Originalmente, este arquivo usa a função cudaDriverGetVersion que acaba retornando 0 e impede a instalação.

Como configurar seu firewall Linux para acessar uma VPN

Recentemente eu precisei acessar uma VPN em ambiente Windows e fiquei “vendido” porque minha máquina Linux não estabelecia a conexão nem com reza forte!

Como o trabalho em questão era urgente eu dei o braço a torcer e acessei minha partição Windows para conectar e fazer o que era necessário. Só que isso não me desceu a garganta, eu sabia que tinha algum detalhe que estava faltando e assim que tive um tempo livre resolvi dar o primeiro tiro, desligar o firewall e tentar conectar. Bingo (ninguém mais fala bingo né?) era exatamente o firewall que estava barrando a conexão, então agora era descobrir qual era a configuração que eu tinha que fazer.

No firewall será necessário criar uma regra personalizada com:

Rede de origem 0/0 (ou seja, qualquer coisa a partir do seu computador será direcionada para a conexão de VPN)

Protocolo TCP

Porta de destino pptp (1723)

Bom, na parte da conexão VPN você pode usar o NetworkManager para criar a configuração que é bem tranquilo, mas se o destino é uma máquina Windows deixe marcado apenas MSCHAP e MSCHAPv2, utilizando criptografia MPPE.

Update importante, nas versões 13.1 e 13.2 do OpenSuse, mesmo fazendo a configuração da regra do firewall, não esta estabelecendo a conexão, isso porque um módulo de pptp não está sendo carregado. É necessário executar a linha a seguir toda vez que abrir uma sessão:

sudo modprobe nf_conntrack_pptp

E pronto, uma vez que você acesse a rede Microsoft informará a sua senha no domínio e fará parte daquela rede. A partir daí pode usar o KRDC para acessar uma máquina remota com RDP.

É interessante porque aí você pode continuar em seu ambiente Linux, mas acessando a máquina Windows na qual precisa fazer alguma coisa.

Gestão de projeto e Timesheet Open-Source

Procurei algumas ferramentas open-source que auxiliem na tarefa de gestão de projetos e, em especial, na apropriação de horas dos recursos (podem ser funcionários ou até freelancers). Uma ferramenta que eu gostei bastante foi o Ganib. Você pode criar o seu projeto no MS-Project e importar no Ganib o XML gerado, mas se não tiver ou não usar o MS-Project pode ficar tranquilo porque o Ganib permite criar as tarefas, adicionar os recursos e controlar o calendário.

Tem muitas funcionalidades legais, tem um blog integrado, wiki, permite adicionar arquivos do projeto e assim você pode ter tudo relacionado ao seu projeto em uma ferramenta integrada. É claro que eu encontrei alguns problemas, mas comecei a usar a versão 1.3 que tinha realmente algumas falhas, mas na versão 2.2 algumas das coisas que reportei parece que já foram corrigidas (ainda não pude experimentar).

Uma ferramenta muito legal que vem integrada é o g-track que é uma aplicação Java que conecta no servidor do Ganib e baixa as tarefas do usuário permitindo o controle de tempo gasto em cada uma das tarefas com “começar”, “pausar” e “concluir”. A grande vantagem disso é que as pessoas vão controlando o tempo gasto nas suas atividades mas isso já vai sendo refletido na visão do gerente. Quem já precisou coletar o andamento das tarefas de uma equipe sabe o problema que é isso 😉

A instalação do Ganib é super simples e eles disponibilizam um pacote que já vem inclusive com o Java e com o Tomcat já tudo empacotado, você só precisa instalar o MySQL, rodar o script que vem no zip para configurar o banco e configurar o login e senha do banco de dados no arquivo da aplicação Web. Nada demais. Um problema que eu tive foi usar a versão errada do MySQL, a versão mais recente ainda não era suportada quando fiz a minha instalação. Preciso ainda instalar novamente para verificar a compatibilidade.

Se você quer uma ferramenta muito boa para gerenciar seus projetos, equipes, tarefas e recursos vale a pena experimentar o Ganib.

GNU Cobol (antigo OpenCOBOL)

Eu não sou nenhum fã de COBOL, na verdade nem sei programar nessa linguagem (só para constar ela está no índice TIOBE em 19º lugar, tendo subido 5 posições desde 2012), mas o fato é que já tem muito tempo que eu ouço que o mainframe vai morrer, que o COBOL vai desaparecer. No entanto, no ano passado eu recebi por email uma informação de uma empresa de São Paulo que estava contratando programador COBOL com um salário de R$ 20 mil (detalhe, CLT).

Eu trabalhei em um projeto na EDS (que agora foi comprada pela HP) que era um piloto para integrar uma aplicação COBOL com um front-end em Java através de EJBs que rodavam no Websphere sobre z/OS e os EJBs teriam que chamar o tal programa COBOL. Foi um projeto muito interessante e (na minha visão) divertido de trabalhar, eu lembro que tinha que ficar interagindo com as equipes de COBOL/Mainframe porque eu não sabia (e continuo sem saber) nem como listar onde estavam os programas naquela plataforma. Só para constar, funcionou que foi uma beleza 🙂 a gente tinha uma aplicação Java cliente que se conectava no EJB remoto e fazia a chamada que depois, via JNI, chegava no programa COBOL. Uma coisa bem legal disso tudo é que, na época, estávamos usando uma tecnologia que tinha sido pouco usada até pelo pessoal da IBM (que era a fornecedora do software) então trocamos vários emails com o pessoal do suporte para achar os detalhes das chamadas.

Enfim, o fato é que o COBOL não vai morrer, e nem os mainframes, pelo menos não pelos próximos 10 (20, ou X) anos.

Já ouvi falar de outros projetos para tentar passar códigos fontes de COBOL de programas que ainda estão funcionando para baixa plataforma (como o pessoal de Mainframe se refere aos servidores da família x86) compilando os programas com alguma ferramenta. Alguns desses projetos funcionaram, mas os servidores de baixa plataforma não deram conta do recado e acabaram reativando os Mainframes.

Então, se você estiver interessado em experimentar essa linguagem tem uma opção interessante. O OpenCOBOL permite compilar o código de COBOL para C e posteriormente compilado para a plataforma destino que pode ser Linux, Mac e Windows. Você pode achar mais informações sobre OpenCOBOL aqui.

OpenCL: lembre desse nome!

Eu tenho visto muitos tweets nas últimas semanas de novidades sobre o OpenCL, embora seja difícil de imaginar que consiga (em um tempo curto) superar o desempenho de soluções específicas como o CUDA, mais e mais fabricantes estão suportando o padrão.

A própria nvidia oferece suporte ao OpenCL em suas placas de vídeo, eu ainda não consegui fazer uma comparação de tempo entre implementações usando CUDA e OpenCL em uma mesma placa da nvidia para ver qual a perda de desempenho que pode acontecer, mas a diferença é que você pode pegar sua versão OpenCL (mesmo que, supostamente, mais lenta) e compilar para rodar em uma placa ATI (AMD) Radeon.

Mais do que isso, agora você pode escrever até mesmo para a sua placa FPGA, e isso sim é uma grande avanço 😉

Kinect para mover coisas

Primeiro você vê o vídeo, depois a gente conversa

Ok, então agora posso falar, muito legal esse projeto! A equipe utilizou dois Kinects para, de um lado ler os movimentos do usuário, e do outro fica lendo os bloquinhos de plástico que são controlados mecanicamente. Assim conseguem mostrar para o usuário remoto o que está acontecendo.

Eu acho que as pesquisas na área de interação estão ficando cada vez mais interessantes, o mais importante é perceber como os cientistas pegam alguma coisa que estamos acostumados e repensam aquilo de uma forma completamente diferente!

Vários tutoriais de Android

Eu não sou exatamente um grande fã de redes sociais, mas o twitter tem uma coisa interesante que é receber novidades específicas de tecnologias ou empresas nas quais você tem algum interesse. Até porque como os tweets têm que ter poucos caracteres não dá para ter muitos anúncios o que é uma grande vantagem em relação ao Facebook.

Bom essa volta toda para dizer que nos últimos dias eu vi vários examples de código interessantes do Android no site Java Code Geeks. Você pode achar muita coisa por lá e acho que vale dar uma conferida 🙂 Só achei que os exemplos (pelo menos os que eu olhei) eram bem isolados. Isso tem suas vantagens e suas desvantagens, mas de qualquer forma fica recomendado.

Finalmente Kinect na máquina virtual VMWare Player Plus

Conforme eu postei aqui ainda não havia conseguido colocar o Kinect (edição XBOX 360) para funcionar em uma máquina virtual. Ora, mas porque alguém gostaria de fazer isso? Como eu comentei antes, fica mais fácil de trabalhar com os alunos porque não precisamos nos preocupar com as configurações (que são muitas, são complicadas e tem tudo para dar errado em sala de aula).

Enfim, depois de muito ler os fóruns da internet descobri que haveria uma esperança se ao invés de usar o VirtualBox da Oracle, usasse o VMWare (estou usando o Player Plus, grátis para uso pessoal), pois a implementação de mapeamento USB da VMWare é melhor do que o da VirtualBox.

Depois de reinstalar a máquina virtual algumas vezes e tentar instalar o material do OpenNI (biblioteca para suporte a tracking de esqueleto) sem sucesso, resolvi tentar usar o libfreenect (que é uma biblioteca de mais baixo nível e que apenas retorna a imagem de profundidade).

Primeiro tentei usar a versão que está compilada no repositório do OpenSuse 12.3, mas essa não funcionou, como eu sou teimoso tentei pegar o código fonte que eu já tinha aqui e compilar na máquina virtual, e qual não foi a minha surpresa quando a imagem apareceu!

Agora estou em dúvida se o libfreenect também não funcionaria no VirtualBox também, embora quando testei a câmera não ficava estável. Acho que isso tem a ver com a forma como é implementado o suporte USB mesmo, porque na VMWare, quando você pluga um dispositivo na máquina virtual ele é desconectado da máquina física, então provavelmente essa é a mágica que acontece!

Wiimote na máquina virtual, mas Kinect ainda não

Essa semana eu consegui fazer um teste que já vinha me rondando há algum tempo. Uma das coisas que mais atrapalha em qualquer aula de qualquer disciplina de computação é preparar o ambiente para os alunos trabalharem. Nem sempre temos acesso de administrador na máquina e isso pode dificultar muito as coisas, mais do que isso, nem sempre a preparação do ambiente é relevante para o conteúdo que será ministrado (eu disse *nem* sempre, as vezes é…)

Pois bem, uma solução simples é criar uma máquina virtual com tudo que você precisa e distribuir para os alunos apenas o arquivo para eles usarem, tanto no laboratório quanto em casa, isso facilita muito a vida! Porém quando você usa dispositivos menos, digamos, convencionais em suas disciplinas fica a dúvida, será que a ponte entre o USB da máquina host com a máquina virtual vai dar certo?

Então eu queria saber se conseguiria colocar o ambiente de suporte ao Wiimote com wrapper para Lua (o artigo do SBGames2011 sobre o projeto pode ser visto aqui) e que pode ser usado no Löve2D dentro de uma máquina virtual e está usar a antena do bluetooth do host para se conectar ao controle. Também queria saber se o Kinect, ligado ao host poderia ser usado dentro da máquina virtual. Esses dois equipamentos são usados em nossa disciplina de Interação Homem-Máquina (ou Humano-Computador, o nome varia) na UniLasalle e o ambiente de suporte não é exatamente trivial de configurar, até porque hoje estamos usando uma biblioteca para Wiimote que precisa rodar em 32bits enquanto a biblioteca de suporte ao Kinect precisa rodar em um Linux 64bits.

O Kinect não teve jeito mesmo, inclusive vi em vários fóruns que as pessoas tentaram e não conseguiram também, eventualmente o dispositivo até aparece, porém não pode ser aberto. Isso me deixou preocupado se o Wiimote teria o mesmo resultado, mas deu certo! Isso é bom porque metade do problema já está resolvido 🙂

Agora tenho que pensar em um jeito fácil de instalar o ambiente de suporte ao Kinect…