Precisei configurar e testar uma estrutura distribuída e expansível do Solr para indexações rápidas e consultas mais rápidas ainda. Devido ao fato do Solr 4 (que implementa o “modo Cloud”) ainda estar em Beta (pelo menos até a data de publicação desse post), existe pouco material de boa qualidade.

No site oficial um tutorial simples ensina a rodar o Solr através do Jetty interno levantando o serviço de um Zookeeper também interno.

Bem, antes de mais nada, vamos a definições rápidas:

Lucene

Motor de indexação e busca de textos, rico em recursos, escrito em Java e cross plataforma. Essencialmente nos permite indexar grandes e numerosos textos para realizarmos buscas rápidas.

Solr

Plataforma opensource de buscas para o Lucene, permitindo integrações via requisições REST e outros recursos de gerenciamento. De maneira bem simples, é uma interface para o Lucene.

Solr Cloud

É o novo recurso do Solr 4-Beta, permitindo a distribuição ou replicação de índices através de várias instâncias do Solr.

Zookeeper

Serviço centralizado de manutenção de configurações, distribuição de estados e gerenciamento de eventos. É usado pelo Solr Cloud para obtenção de configurações e comunicação entre as instâncias do Solr.

1. Preparando

Durante o tutorial, considerarei uma determinada estrutura de pastas. Todos os passos foram executados em Linux (CentOS 6) com Java 7 (1.7.0_06-b24).

Baixei o Tomcat 7 (7.0.29) e extraí para /usr/tomcat/ .

Baixei o Solr 4 (beta) e extraí em /usr/solr/ .

Baixei o Zookeeper 3 (3.4.3) e extraí em /usr/zookeeper/ .

2. Configurando e iniciando o Zookeeper

A simplicidade do serviço principal do Zookeeper é assustadora. Entre na pasta de configurações e edite o arquivo zoo.cfg conforme abaixo:

#cd /usr/zookeeper/zookeeper-3.4.3/conf/
#vim zoo.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/zookeeper/data/
clientPort=9000

No arquivo zoo_sample.cfg existem explicações sobre os possíveis parâmetros. Mas já deve ficar claro que dataDir informa onde ficarão os arquivos gerados e o PID do serviço; e o clientPort será a porta que o serviço escutará por clientes.

Para startar o serviço, é mais fácil ainda:

#cd /usr/zookeeper/zookeeper-3.4.3/bin/
#./zkServer start

3. Carregando configurações do Solr no Zookeeper

O Zookeeper, quando iniciado, gera um sistema de arquivos virtual que pode ser distribuído e pode ser acessado através do serviço. E é nesse sistema de arquivos que temos que salvar as configurações do Solr para que qualquer instância acesse, mesmo que remotamente.

O acesso ao Zookeeper requer uma implementação muitas vezes complicada… se tivéssemos que fazer tudo manualmente. Mas existem ferramentas, APIs e scripts prontos pra isso.

No pacote do Solr, juntamente com alguns exemplos, existe um script (bash e bat) para esse envio de configurações… e também existem configurações prontas para utilizarmos… e dados para testarmos… Enfim, vamos fazer o upload.

#cd /usr/solr/apache-solr-4.0.0-BETA/example/cloud-scripts/
#./zkcli.sh -cmd upconfig -confdir /usr/solr/apache-solr-4.0.0-BETA/example/solr/collection1/conf/ -confname collection1 -z localhost:9000

Depois que o envio terminar, podemos acessar o sistema de arquivos do Zookeeper e ver o resultado.

#cd /usr/zookeeper/zookeeper-3.4.3/bin/
#./zkCli.sh -server localhost:9000
#ls /configs/collection1

4. Configurando o Solr

Apesar das configurações de indexação serem obtidas do Zookeeper, existem configurações locais que definem a função da instância local do Solr. Nessa configuração local, definimos as instâncias que serão criadas (cores) e a quais collections e shards essas instâncias se conectarão.

Explicando e seguindo uma ordem de hierarquia:

Collection

É o conjunto de configurações que foram carregadas. No nosso caso, temos uma collections nomeada como “collection1″. Pode-se considerar que representa um domínio de dados, como “livros”, “documentos” ou “jornais da cidade”.

Shard

É uma divisão física dos índices salvos, permitindo a distribuição da tarefa de indexação por várias instâncias do Solr. No caso da perda de uma shard inteira, a parte dos índices que estavam nesta shard serão perdidos.

No caso de 2 ou mais cores estarem configurados para a mesma shard, estes serão réplicas, mantendo cópias dos mesmos índices fornecendo um nível de redundância e acelerando consultas.

Além disso, se não for especificado uma quantidade de  shards, por padrão existirá apenas 1. E os cores serão igualmente distribuídos entre as shards se não forem forçadamente direcionados.

Core

É efetivamente uma instância do Solr, com sua própria configuração e seu próprio índice. Deve ser especificado um nome único para cada core e a configuração (collection) que será carregada. A definição da shard é opcional.

#cd /usr/solr/apache-solr-4.0.0-BETA/example/solr
#vim solr.xml

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true">
  <cores adminPath="/admin/cores" host="localhost" hostPort="8080" >
    <core name="core1" collection="collection1" instanceDir="core1/" shard="shard1" />
    <core name="core2" collection="collection1" instanceDir="core2/" />
  </cores>
</solr>

No caso, criei 2 cores apontando para a mesma configuração. Cada um deles com seu próprio nome e pasta (onde serão salvos os índices). O “core1″ possui uma shard especificada e será a única existente. O “core2″ será designado automaticamente para “shard1″.

Importante notar as outras configurações. O “persistent=true” permitirá que o gerenciamento de cores pela interface reflita neste arquivo. E o “host” e “hostPort” devem ser os mesmo para o acesso padrão ao Tomcat com o Solr.

5. Configurando e subindo o Tomcat

Apenas duas coisas são necessárias para podermos startar o Tomcat e ver tudo funcionando: incluir a configuração apontando para o .war do Solr e setar uma variável do Java necessária para o Solr Cloud.

#cd /usr/tomcat/apache-tomcat-7.0.29/conf/Catalina/localhost/
#vim solr.xml

<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="/usr/solr/apache-solr-4.0.0-BETA/dist/apache-solr-4.0.0-BETA.war" path="/solr">
        <Environment name="solr/home" type="java.lang.String" value="/usr/solr/apache-solr-4.0.0-BETA/example/solr" override="true" />
</Context>

Observe que é necessário apontar o local onde está o “solr.xml” configurado anteriormente.

Para iniciar o Solr em modo Cloud, basta disponibilizar a variável Java “zkHost” apontando para o endereço onde o ZooKeeper está escultando.

No caso, inclua a variável no JAVA_OPTS através de export ou editando o “catalina.sh”. Então inicie o Tomcat.

#export JAVA_OPTS=”-DzkHost=localhost:9000″
#./startup.sh

Quando terminar de startar, acesse http://localhost:8080/solr/. Se o Cloud Mode do Solr ativou com sucesso (devido à variável “zkHost”), no menu lateral deve aparecer a opção “Cloud”. Nesta é possível visualizar o gráfico da rede de instâncias conectadas ou que já conectaram.

Se tudo ocorreu bem, neste gráfico deverão ter um collection “collection1″, um shard “shard1″, e dois cores “localhost” (o nome do core é usado para nomeá-los em outras áreas).

Certo?! =)

Lembrando que aqui temos 2 instâncias na mesma máquina que o Zookeeper… Mas podem ser n instâncias em máquinas diferentes, apontando para o mesmo Zookeeper. Basta seguir os passos 4 e 5 para cada servidor.

Pararei por aqui… Formas de indexar, conectar, consultar, otimizar e etc. são operações existentes desde versões anteriores do Solr e, por isso, muito comuns pela rede… So… GOOGLE IT!

Recentemente voltei a desenvolver (de verdade) em Java e estou encarando desafios inéditos até então para mim. Estou vendo muitas coisas novas e espero tornar o blog um pouco mais ativo com essas “descobertas”. Talvez 1 ou 2 posts por semestre… =]

Anyway, a motivação desse post é que precisei utilizar dois bancos de dados, um MySQL para leituras e outro PgSQL para escrita. Procurei bastante e achei bastante material, mas nada completo envolvendo configurações dos data sources, das unidades de persistências e das transações num lugar só. Por isso venho tentar unificar isso e ajudar quem precise.

Ah, não irei demonstrar uma aplicação completa, como geralmente faria… Se precisarem de um projeto com as configurações básicas procurem pelo arquétipo do Maven “spring-mvn-jpa-archtype/”.

Bem, para inicio de conversa, nesse meu projeto compatível com Java 6, utilizei Spring 3.0.5, Hibernate 3.6.0 e a implementação do JPA 2.0 pelo Hibernate. Utilizarei annotations, mas não quero exagerar e abolir os XMLs ^^ .

Primeiramente a configuração dos bancos:

database.xml

<bean id="placeHolderDefault" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
		<property name="locations" value="classpath:db.properties" />
</bean>
 
<bean id="my_dataSource" class="org.apache.commons.dbcp.BasicDataSource"
		destroy-method="close">
	<property name="driverClassName" value="${my.driver}" />
	<property name="url" value="${my.url}" />
	<property name="username" value="${my.username}" />
	<property name="password" value="${my.password}" />
</bean>
 
<bean id="pg_dataSource" class="org.apache.commons.dbcp.BasicDataSource"
		destroy-method="close">
	<property name="driverClassName" value="${pg.driver}" />
	<property name="url" value="${pg.url}" />
	<property name="username" value="${pg.username}" />
	<property name="password" value="${pg.password}" />
</bean>
 
<bean id="my_entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="dataSource" ref="my_dataSource" />
	<property name="persistenceXmlLocation" value="classpath:META-INF/my_persistence.xml" />
	<property name="jpaVendorAdapter">
		<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
			<property name="showSql" value="false" />
			<property name="generateDdl" value="false" />
			<property name="databasePlatform" value="${my.dialect}" />
		</bean>
	</property>		
</bean>
 
<bean id="pg_entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="dataSource" ref="pg_dataSource" />
	<property name="persistenceXmlLocation" value="classpath:META-INF/pg_persistence.xml" />
	<property name="jpaVendorAdapter">
		<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
			<property name="showSql" value="false" />
			<property name="generateDdl" value="false" />
			<property name="databasePlatform" value="${pg.dialect}" />
		</bean>
	</property>		
</bean>
 
<bean id="my_transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="entityManagerFactory" ref="my_entityManagerFactory" />
		<qualifier value="my_transactionManager" />
</bean>
 
<bean id="pg_transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="entityManagerFactory" ref="pg_entityManagerFactory" />
		<qualifier value="pg_transactionManager" />
</bean>

Observe que criei uma série de recursos para cada banco, isolando assim as conexões a eles.

Nesse caso, referenciei 2 locais diferentes para as configurações do Persistence Unit. Por padrão, o arquivo “META-INF/persistence.xml” é carregado. Mas, como quero poder referenciar diferentes Unidades de Persistência por nome, criei dois arquivos diferentes com praticamente o mesmo conteúdo.

META-INF/my_persistence.xml

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
      http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
	version="1.0">
 
	<persistence-unit name="my_persistenceUnit" transaction-type="RESOURCE_LOCAL">
		<properties>
			<property name="hibernate.hbm2ddl.auto" value="update" />
			<property name="hibernate.show_sql" value="false" />
			<property name="hibernate.transaction.flush_before_completion"
				value="true" />
			<property name="hibernate.cache.provider_class" 
                                value="org.hibernate.cache.HashtableCacheProvider" />
		</properties>
	</persistence-unit>
</persistence>

META-INF/pg_persistence.xml

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
      http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
	version="1.0">
 
        <persistence-unit name="pg_persistenceUnit" transaction-type="RESOURCE_LOCAL">
		<properties>
			<property name="hibernate.hbm2ddl.auto" value="update" />
			<property name="hibernate.show_sql" value="false" />
			<property name="hibernate.transaction.flush_before_completion"
				value="true" />
			<property name="hibernate.cache.provider_class" 
                                value="org.hibernate.cache.HashtableCacheProvider" />
		</properties>
	</persistence-unit>
</persistence>

A única diferença é o nome da Unidade de Persistência. Para o mesmo efeito pode-se manter as definições acima no mesmo arquivo (por exemplo no padrão ”META-INF/persistence.xml”) e setar o nome das unidades nos beans LocalContainerEntityManagerFactoryBean.

Sobre o placeHolderDefault (PropertyPlaceholderConfigurer), serve para injetar valores de propriedades que utilizo depois (como ${my.driver}) obtidos de um simples arquivo de texto.

db.properties

#MySQL Options
my.username=myuser
my.password=mypass
my.url=jdbc:mysql://localhost/mydatabase
my.dialect=org.hibernate.dialect.MySQL5Dialect
my.driver=com.mysql.jdbc.Driver
 
#PostgreSQL Options
pg.username=pguser
pg.password=pgpass
pg.url=jdbc:postgresql://localhost/pgdatabase
pg.dialect=org.hibernate.dialect.PostgreSQLDialect
pg.driver=org.postgresql.Driver

Agora, para podermos utilizar as anotações @Transactional e @PersistenceUnit, temos que incluir:

<tx:annotation-driven />
<context:component-scan base-package="br.com.package" />

Observação: é comum a inclusão do PersistenceAnnotationBeanPostProcessor, mas isso é feito automaticamente quando usa-se context:component-scan ou context:annotation-config.

Agora basta definir os EntityManagers para permitir as operações em ambos os bancos e as Transactions para persistir corretamente.

No meu caso, utilizei uma classe abstrata BaseManager com algumas operações básicas. Nas classes filhas especifiquei as unidades de persistência.

BaseManager.java

public abstract class BaseManager {
 
    protected abstract EntityManager getEntityManager();
 
    public synchronized BaseModel persist(BaseModel model) {
        BaseModel returnValue;
        if(model.getId() == null) {
            getEntityManager().persist(model);
            returnValue = model;
        } else {
            returnValue = getEntityManager().merge(model);
        }
        return returnValue;
    }
 
    public BaseModel findById(Class clazz, Long id) {
        BaseModel model = (BaseModel)getEntityManager().find(clazz, id);
        return model;
    }
 
    public synchronized void delete(BaseModel model) {
        if(model.getId() != null) {
            getEntityManager().remove(model);
        }
    }
}

Observe que o getEntityManager(), essencial para as operações, é abstrato.

UserManager.java

@Service
public class UserManager extends BaseManager {
 
    @PersistenceContext(unitName="pg_persistenceUnit")
    protected EntityManager entityManager;
 
    @Override
    protected EntityManager getEntityManager() {
        return entityManager;
    }
 
    @Override
    @Transactional(value="pg_transactionManager")
    public BaseModel persist(BaseModel model) {
        return super.persist(model);
    }
 
    @Override
    @Transactional(value="pg_transactionManager")
    public void delete(BaseModel model) {
        super.delete(model);
    }
 
}

Assim, para a classe UserManager o banco usado será o PostgreSQL.

Note que as operações que precisam de uma transação foram sobrescritas para permitir a utilização de um @Transactional específico.

Done! Com isso feito, basta testar!

E por hoje é só pessoal.

Nas minhas buscas achei diversas soluções para esse fim em diversas condições. Tentarei listar aqui esses meios apontando a situação em que funcionam ou ajudam.

No meu caso, os testes foram feitos no SQL Server 2008 instalado no Windows 7. O problema real ocorreu em um servidor Windows Server 2008 R2 + SQL Server 2008 R2 onde eu não tinha a senha do usuário ‘sa’ (e nenhum outro usuário) e não tinha acesso pelo Windows Authentication.

Bem, o grande motivo desse post seria conseguir o acesso mesmo sem a possibilidade de usar a autenticação pela conta do Windows, mas começarei mostrando algumas formas de setar a senha tendo algum tipo de acesso… Pode ser útil no caso de automatizar esse processo ou fazer a alteração via linha de comando.

 _

Setar senha pela linha de comando tendo acesso pela autenticação do Windows

1. No prompt de comando (MS-DOS) abra o SQL Server Command Line Tool usando a autenticação do Windows:

sqlcmd -E

1.1. No caso de versões anteriores ao SQL Server 2008, use osql -E

2. Use o comando sp_password para setar a nova senha do usuário ‘sa’:

sp_password @old = null, @new = ‘novasenha’,  @loginame =’sa’
go

3. Basta sair usando o exit e testar o login:

exit

sqlcmd -U sa

 _

Setar a senha sem o acesso pela autenticação do Windows

No meu caso, algum problema que desconheço impediu o login no banco via Windows Authentication e eu não tinha o acesso do usuário ‘sa’. Pesquisei um pouco e consegui recuperar o acesso via login e senha. Seguem algumas possibilidades e solução de entraves.

 _

» Acesso ao SQL Server em modo local ou single-user mode

Startando o serviço do SQL Server em modo single-user permite que qualquer administrador do servidor conecte ao banco como um sysadmin. Isso pode ser feito executando o comando:

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn>sqlservr.exe -m

Com o parâmetro -m o administrador do servidor poderá logar no banco através da Autenticação do Windows (seja por linha de comando ou pela interface do gerenciador), mesmo se ela não tiver sido configurada previamente.

sqlcmd -E

Através desse acesso, pode-se alterar a senha conforme o item anterior.

 _

» Alteração da senha através do MS SQL Server Password Unlocker

Mesmo sem poder acessar o SQL Server, é possível forçar uma nova senha para um dado usuário usando o MS SQL Server Password Unlocker. É uma aplicação paga, mas para os meus testes usei uma versão “alternativa”…

A instalação é bem direta e não requer nada de especial. Depois de instalado, deve abrir o master.mdf e será exibido os usuários cadastrados. No meu caso, o local do arquivo era:

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\master.mdf

Basta alterar a senha e pronto!

 _

» Mudar o método de autenticação ao servidor com acesso pela autenticação do Windows

Mesmo alterando a senha do usuário, não será possível logar se o servidor estiver configurado para permitir apenas a Windows Authentication. Nesse modo, qualquer tentativa de login, mesmo com a senha correta, dará um simples “Login failed for user ‘sa’”. Essa configuração poderá ser feita pela interface do gerenciador (SQL Server Manegement Studio). Caso necessário, inicie o servidor em single-user mode.

Nessa interface, para chegar até a opção do tipo de autenticação, basta:

1. right-click na instância/servidor (no meu caso é “localhost (SQL Server 10.0.1600 – sa)”);
2. “Properties”;
3. “Security”;
4. Em “Server authentication” marque a opção “SQL Server and Windows Authentication mode”.
5. Reinicie o serviço.

 _

» Mudar o método de autenticação ao servidor nenhum acesso ao mesmo

Essa façanha pode ser feita através da edição de registro do Windows. o_O’

Abra o regedit do Windows e navegue até os registros do SQL Server. No meu caso o caminho é:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQLServer

Deverá haver o registro “LoginMode” no painel da direita. Se não encontrar o caminho correto, faça uma busca geral (CTRL+F) por “LoginMode” e deverá achar.

Edite esse registro com o valor hexadecimal “2″. O valor “1″ significa que o SQL Server está em Windows Authentication Mode apenas. Colocando “2″ será usado o ”SQL Server and Windows Authentication mode”. Reinicie o serviço para aplicar a alteração.

Por hora é isso. Espero que ajude alguém em momentos de desespero. =P

Fontes:
Suporte Microsoft
MSDN Library
MS SQL Password Unlocker
MSDN Forum
MSDN Library

O objetivo do Luminolaser foi, principalmente, estudar o uso de Servo Motores e o controle sob eles. Sempre tentando criar algo um pouco além do simples exemplo, procurei fazer uma espécie de scanner de ambiente que identifica o ponto mais luminoso (eu só tinha um sensor de luminosidade – LDR – a disposição) e marca esse ponto com um laser pointer.

Posteriormente incrementei um pouco mais de modo que fosse possível controlar o laser através de um controle analógico.

Bem, vamos aos materiais usados:

• Arduino “Brasileirino” (Duemilanove) ATMega328 [Arduino Uno];
• Bateria recarregável de 9V [Deal Extreme];
• Bateria de 4V de alta descarga para alimentar o módulo laser;
• Bateria de 7,4V de alta descarga para os servos;
• 2 Mini Servos Motores [Deal Extreme];
• Módulo de laser vermelhor 5mW [Deal Extreme];
• Botão de lanterna para mudar a função do protótipo [Deal Extreme];
• Muitos fios conectores para protoboard [Deal Extreme];
• Analógico do PSP [Deal Extreme];
• LDR (sensor de luminosidade) [Wiki].
• Transistor NPN Tip122 [Wiki];

Como pode-se notar, existem muitos componentes from China. Realmente acredito que valha a pena, principalmente quando não existe pressa para receber os produtos.

À esquemática:

Observem que, por não ter uma imagem do controle analógico para o Fritzing, acabei substituindo por 2 potenciômetros rotatórios… Até porque são equivalentes. Assim como o Led vermelho da imagem simboliza o módulo do laser.

E para simplificar a visualização, incluí apenas 1 servo motor na esquemática e separei os componente. Na versão final o laser e o LDR ficam juntos na ponta do segundo servo.

O botão incluí para alterar o modo de controle dos servos entre automático (busca o ponto mais luminoso do ambiente) e manual (permitindo o direcionamento do laser através do controle analógico).

Now it’s time to code!

#include <Servo.h> 
 
Servo servo_base;
Servo servo_upper;
 
//Posição dos servos inferior e superior
int servo_base_pos = 0;
int servo_upper_pos = 0;
 
//Posição para onde os servos devem se mover
//para apontar onde está a mais forte fonte de luz
int final_base_pos = 0;
int final_upper_pos = 0;
 
//Pinos dos servos, sensor ldr e sinal do laser
int servo_base_pin = 5;
int servo_upper_pin = 3;
int ldr_pin = 5;
int laser_pin = 13;
 
//Pinos do analógico e do botão
int dpad_x = 0;
int dpad_y = 1;
int button_pin = 8;
 
void setup() 
{ 
  servo_base.attach(servo_base_pin);
  servo_upper.attach(servo_upper_pin);
  pinMode(laser_pin, OUTPUT);
  pinMode(button_pin, INPUT);
} 
 
void loop() 
{ 
  if(verificaClick()) {
    //Função de direcionamento manual do laser
    ligarLaser();
    readAnalogPad();
    direcionaLaser();
  } else {
    //Busca automática pela maior luminosidade
    desligaLaser();
    buscaMaiorLuminosidade_1();
    direcionaLaser();
    ligarLaser();
    delay(10000);
  }
}
 
//Percorre todo o alcance dos servos buscando a maior luminosidade
//detectada pelo LDR e salva essa posição para mover depois
void buscaMaiorLuminosidade_1() {
  int maior_luminosidade = 0;
 
  for(servo_base_pos = 0; servo_base_pos < 180; servo_base_pos += 20) 
  {
    servo_base.write(servo_base_pos);
    delay(500);
    for(servo_upper_pos = 0; servo_upper_pos < 180; servo_upper_pos += 5) 
    {
      servo_upper.write(servo_upper_pos);
      delay(100);
      if(verificaClick()) {
        //Se o botão foi clicado, encerra a busca
        return;
      }
 
      int ldr = obtemLuminosidade();
      if(ldr > maior_luminosidade) {
        maior_luminosidade = ldr;
        final_base_pos = servo_base_pos;
        final_upper_pos = servo_upper_pos;
      }
    }
 
    servo_upper.write(0);
  }
 
  servo_base.write(0);
}
 
int obtemLuminosidade() {
  return analogRead(ldr_pin);
}
 
void direcionaLaser() {
  servo_upper.write(final_upper_pos);
  servo_base.write(final_base_pos);
}
 
void ligarLaser() {
  digitalWrite(laser_pin, HIGH);
}
 
void desligaLaser() {
  digitalWrite(laser_pin, LOW);
}
 
boolean verificaClick() {
  return digitalRead(button_pin) == HIGH;
}
 
//Obtem a leitura do controle analógico.
//Devido à baixa qualidade do mesmo, não foi possível fazer 
//simplesmente um mapeamento do sinal de entrada para a posição final.
void readAnalogPad() {
  int analog_x = analogRead(dpad_x);
  int analog_y = analogRead(dpad_y);
 
  int y = 0;
  int x = 0;
 
  if(analog_y > 620) {
    y = analog_y > 680 ? 5 : 1;
  } else if(analog_y < 540) {
    y = analog_y < 480 ? -5  : -1;
  } else {
    y = 0;
  }
 
  if(analog_x > 330) {
    x = analog_x > 380 ? 5 : 1;
  } else if(analog_x < 280) {
    x = analog_x < 190 ? -5 : -1;
  } else {
    x = 0;
  }
 
  final_upper_pos = final_upper_pos + y;
  final_base_pos = final_base_pos - x;
 
  final_upper_pos = final_upper_pos > 180 ? 180 : final_upper_pos;
  final_upper_pos = final_upper_pos < 0 ? 0 : final_upper_pos;
 
  final_base_pos = final_base_pos > 180 ? 180 : final_base_pos;
  final_base_pos = final_base_pos < 0 ? 0 : final_base_pos;
 
  delay(100);
}

Existem algumas melhorias para serem feitas no código, mas uma funcionalidade adicional que quero implementar é a capacidade de seguir. Imagino que seja possível fazer isso através de micro ajustes (ou micro buscas em uma área menor). Assim, teoricamente, seria possível seguir a fonte de luz mesmo se houver deslocamento da mesma. Além disso, pretendo trocar o sensor de luminosidade por um sensor de infra vermelho e, se funcionar como eu espero, poder detectar e seguir fontes de calor, como o corpo humano.

Bem, por fim vamos ao resultado final atual:

The video cannot be shown at the moment. Please try again later.

Por hora é só… Quando eu tiver tempo de dar um upgrade nesse protótipo, edito esse post para incluir as alterações.

Nos últimos meses estive consideravelmente ocupado (e preguiçoso) para voltar a escrever, principalmente devido ao padrão de post gigantes que habitam esse blog. Por isso, dessa vez, tentarei fazer algo mais resumido e, conseqüentemente, voltado a quem já possui o mínimo de conhecimento sobre o assunto.

Vou me ater a apresentar o protótipo que fiz, a esquemática e código fonte sem entrar em maiores explicações de funcionamento.

Bem, o Colorino, como foi nomeado pelo meu caro amigo @jopss, é um experimento que fiz com o Arduino para aprender sobre e testar um led RGB que comprei do Deal Extreme usando resistores variáveis, transistores e uma programação bastante simples. O objetivo era controlar a intensidade de cada cor do led (vermelho, verde e azul) através dos resistores deslizantes. Através do uso de transistores, pude controlar a intensidade da corrente através do sinal digital do Arduino.

Primeiramente vamos ao componentes usados:

• 1 Arduino Duemilanove ATMega328 (“Brasileirino”) [Arduino Uno];
• 1 Led RGB 5W 70 Lumen [Deal Extreme];
• 3 Potenciômetros deslizantes 20 kΩ [Google Images] [Wiki US];
• 3 Transistores NPN Tip122 [Wiki];
• 1 Bateria 4V de alta descarga (pode ser uma bateria de 3,7V de celular)*;
• 1 Bateria 9V convencional para alimentar o Arduino (opcional) [Google Images];
• Muitos fios.

* No caso da bateria de alta descarga, usei uma de 4V (de lítio) de um fone de ouvido bluetooth que eu tinha. Uma bateria de celular pode ser usada se retirado o limitador de descarga (fusível). Considerando uma fonte de 5V, o Led de 5W consumiria 1A (ampér), o que é bastante. Na prática, cheguei ao máximo de 0,5A.

Agora vamos à esquemática dos componentes.

Espero ter feito um bom trabalho ao desenhar esse esquema com o Fritzing.

Hora do código fonte feito na IDE do Arduino.

//Define as portas analógicas de entrada dos potenciômetros
const int pot_r = 2;
const int pot_g = 1;
const int pot_b = 0;
 
//Define as portas PWM de saída analógica para os transistores
const int led_r = 3;
const int led_g = 5;
const int led_b = 6;
 
//Flag para ativar o debug pelo monitor da porta serial
const boolean debug = true;
 
void setup() {
  pinMode(led_r, OUTPUT);
  pinMode(led_g, OUTPUT);
  pinMode(led_b, OUTPUT);
 
  if(debug) { Serial.begin(9600); }
}
 
void loop() {
  //Obtem a leitura dos potenciômetros nas portas analógicas
  int pot_r_signal = analogRead(pot_r);
  int pot_g_signal = analogRead(pot_g);
  int pot_b_signal = analogRead(pot_b);
 
  //Converte os sinais dos potenciômetros para a escala de escrita das PWM
  //O led vermelho recebe menos energia por ser naturalmente mais forte
  int pot_r_digital = map(pot_r_signal, 0, 1023, 0, 150);
  int pot_g_digital = map(pot_g_signal, 0, 1023, 0, 255);
  int pot_b_digital = map(pot_b_signal, 0, 1023, 0, 255);
 
  //Escreve o sinal convertido para os transistores que deverão liberar
  //a quantia equivalente de corrente ao led
  analogWrite(led_r, pot_r_digital);
  analogWrite(led_g, pot_g_digital);
  analogWrite(led_b, pot_b_digital);
 
  if(debug) {
    Serial.print("RED: ");
    Serial.print(pot_r_signal);
    Serial.print(" => ");
    Serial.println(pot_r_digital);
 
    Serial.print("GREEN: ");
    Serial.print(pot_g_signal);
    Serial.print(" => ");
    Serial.println(pot_g_digital);
 
    Serial.print("BLUE: ");
    Serial.print(pot_b_signal);
    Serial.print(" => ");
    Serial.println(pot_b_digital);
 
    delay(1000);
  }
}

Finalmente o resultado.

The video cannot be shown at the moment. Please try again later.

Por hora é só. Espero voltar logo com outro pequeno projeto de Arduino voltado a estudo de componentes. Fui!

Com as novas regras vigentes no mercado e a necessidade de adaptação, tanto por parte das empresas quanto dos funcionários, informamos aos nossos colaboradores as novas regras aprovadas pelo RH de nossa empresa, e vigente a partir desta data:

AUSÊNCIA DEVIDO À ENFERMIDADE:
Não vamos mais aceitar uma carta do médico como prova de enfermidade.
Se o funcionário tem condições de ir até o consultório médico, pode vir trabalhar.

CIRURGIA:
As cirurgias são proibidas. Enquanto o funcionário trabalhar nesta empresa precisará de todos os seus órgãos, portanto, não deve pensar em remover nada. Nós o contratamos inteiro. Remover algo constitui quebra de contrato.

AUSÊNCIAS DEVIDO A MOTIVOS PESSOAIS:
Cada funcionário receberá 104 dias para assuntos pessoais a cada ano…
Chamam-se sábado e domingo.

AUSÊNCIA DEVIDO À SUA PRÓPRIA MORTE:
Isto será aceito como desculpa. Entretanto, exigimos pelo menos 15 dias de aviso prévio, visto que cabe ao funcionário treinar o seu substituto.

O USO DO WC:
Os funcionários estão passando tempo demais no toalete. No futuro, seguiremos o sistema de ordem alfabética. Por exemplo, todos os funcionários cujos nomes começam com a letra ‘A’  irão entre 8:00 e
8:20, aqueles com a letra ‘B’ entre 8:20 e 8:40, etc. Se não puder ir na hora designada, será preciso esperar a sua vez, no dia seguinte. Em caso de emergência, os funcionários poderão trocar o seu horário com um colega.
Os supervisores dos funcionários deverão aprovar essa troca, por escrito.
Adicionalmente: agora há um limite estritamente máximo de 3 minutos no banheiro.
Acabando esses 3 minutos, um alarme irá tocar, o rolo de papel higiênico será recolhido, a porta do banheiro abrirá e uma foto será tirada. Se for repetente, a foto será fixada no quadro de avisos da empresa sob o título: “Infrator Crônico”.

INDUMENTÁRIA:
Informamos que o funcionário deverá trabalhar vestido de acordo com o seu salário.
Se o percebermos calçando um tênis Nike de R$ 350,00 e carregando uma bolsa Gucci de R$ 600,00 presumiremos que vai bem de finanças e, portanto, não precisa de aumento.
Se ele se vestir de forma pobre, será um sinal de que precisa aprender a controlar melhor o seu dinheiro para que possa comprar roupas melhores e, portanto, não precisa de aumento.
E, se ele se vestir no meio termo, estará perfeito e, portanto, não precisa de aumento.

A HORA DO ALMOÇO:
Os magros têm 30 minutos para o almoço, porque precisam comer mais para parecerem saudáveis. As pessoas de tamanho normal têm 15 minutos para comer uma refeição balanceada que sustente o seu corpo mediano. Os gordos têm 5 minutos, porque é tudo que precisam para tomar um “Slim Fast” e um remédio de regime.

Muito obrigado pela sua fidelidade à nossa empresa. Estamos aqui para proporcionar uma experiência empregatícia positiva. Portanto, toda dúvida, comentário, preocupação, reclamação, frustração, irritação, agravo, insinuação, alegação, acusação, observação, consternação e “input” deverá ser dirigida para qualquer outro lugar.

Atenciosamente,

Setor de Recursos Humanos

Fonte: Vila Vilão Viola Violão

Diferentemente do post anterior, terei que me ater a um ambiente específico, mas informarei quais as aplicações envolvidas e suas versões quando for o caso. No geral, utilizei o CentOS 5.3 para a instalação e configuração do Munin e seus plugins.

Desde já, informo que, na maioria das vezes, ler a documentação de um determinado plugin com problemas me ajudou muito. Geralmente a documentação está junto ao código, no próprio plugin. Então basta abri-lo com algum editor de textos.

1. Conceitos Básicos:

Não é necessário saber desenvolver plugins para conseguir instalá-los corretamente, mas alguns conceitos ajudarão muito a entender a documentação e os requisitos.

Primeiramente, os plugins são desenvolvidos em Perl. Com isso em mente, muitas vezes a solução de algum problema é simplesmente a instalação do pacote apropriado, como o perl-DBD-Pg para conexões com o PostgreSQL. USE O ‘YUM SEARCH‘ (ou ‘apt-get‘ ou whatever)!

Em alguns casos, serão necessários “variáveis de ambiente” para a correta execução do plugin. Por exemplo, um plugin para banco de dados precisa do usuário e senha de acesso; um plugin para o Tomcat precisará da porta de acesso.

Essas variáveis deverão ser configuradas no arquivo ‘/etc/munin/plugin-conf.d/munin-node‘. Por padrão, algumas configurações e documentações já estão inclusas. E cada configuração relaciona-se ao plugin através do nome. Por exemplo:

[mysql*]
user root
group wheel
env.mysqladmin /usr/bin/mysqladmin
env.mysqlopts -u munin -pmunin1234

As configurações acima servirão para todos os plugins cujo nome comece com “mysql“. Esse plugin rodará como o usuário root e terá as permissões de super usuário. Além disso, fornecemos ao plugins alguns dados através de variáveis de ambiente (env.). No caso, o plugin usará o mysqladmin do local informado e usará o usuário ‘munin’ para obter as informações necessárias.

Na documentação dos plugins geralmente é informado quais variáveis de ambiente devem ou podem ser setadas.

Além de configurações, existem alguns comandos úteis no processo de configuração de plugins. Através do “munin-run” podemos executar o plugin na hora, obtendo um valor numérico, se bem configurado, ou ‘U‘ se ocorrer algum problema interno. Por exemplo:

# munin-run  tomcat_jvm
free.value 42133328
used.value 301537456
max.value 775487488

Adicione o argumento “autoconf” para receber uma resposta booleana:

# munin-run mysql_queries autoconf
yes

2. Plugin: MySQL

Tratarei aqui sobre as configurações dos plugins “mysql_queries” e “mysql_threads“. O primeiro apresenta a quantidade de requisições ao banco por tipo (selects, updates, deletes, etc); o segundo mostra a quantidade de threads criadas internamento no MySQL.

mysql_queries

mysql_threads

Essencialmente, precisamos apenas criar um usuário do MySQL sem permissão alguma e informar os dados de acesso ao plugin. Então criemos um usuário:

mysql -uroot -p -e 'CREATE USER munin IDENTIFIED BY "munin1234"'

Adicione as informações de acesso no arquivo ‘/etc/munin/plugin-conf.d/munin-node‘:

[mysql*]
user root
group wheel
env.mysqladmin /usr/bin/mysqladmin
env.mysqlopts -umunin -pmunin1234

Através desse usuário o plugin obterá os dados necessários para geração do gráfico. Utilize o comando “munin-run” para testar:

# munin-run mysql_queries
delete.value 35756
insert.value 231054
replace.value 20
select.value 10460090
update.value 5261807
cache_hits.value 52529748

# munin-run mysql_threads
threads.value 14

Simples, não? Muitas vezes a dificuldade não é configurar, mas sim descobrir o que configurar.

3. Plugin: PostgreSQL

Dessa vez falarei sobre um plugin para PostgreSQL, o “postgres_connections_db“. Ele gera um gráfico com os valores de conexões por banco de dados.

postgres_connections_db

Dessa vez, além de criar um novo usuário para o Munin, temos que liberar o acesso livre desse usuário a partir do servidor. Então, primeiramente, criamos o usuário com senha aleatória (segura):

psql -U postgres -c "CREATE ROLE munin NOSUPERUSER NOCREATEDB
NOCREATEROLE NOINHERIT LOGIN ENCRYPTED PASSWORD 'LjkJ9JUha2';"

Utilizamos uma senha segura porque não usaremos ela na configuração do plugin. Ao invés disso, liberaremos o acesso sem senha para o usuário “munin” a partir do servidor para uma determinada tabela. Então, abriremos para edição o arquivo “/var/lib/pgsql/data/pg_hba.conf” e adicionamos a linha:

local   template1   munin   trust

Com isso, todas as conexões para o usuário “munin” na tabela “template1″ a partir do servidor local serão aceitas sem a necessidade de senha. Basta dar um reload no postgre e podemos incluir as configurações do plugin no arquivo “/var/lib/pgsql/data/pg_hba.conf” :

[postgres*]
user munin
env.dbuser munin

Depois disso, basta testar:

# munin-run postgres_connections_db
postgres.value 0
template1.value 0
...

Bem. Acredito que seja o suficiente por hora… Espero voltar logo com a continuação apresentando outros Plugins para o Munin, incluindo um plugin não oficial para monitorar memória usada pelo Passenger (RoR).

Estou há alguns poucos meses trabalhando nessa área, mas aprendi muito. Perdi o medo que tinha do Linux e agora configuro e monitoro servidores utilizando ferramentas que, uma vez configuradas corretamente, tornam a vida muito mais simples.

Não irei me focar em ensinar a configurar cada uma visto que as configurações variam de OS para OS e  existem tutoriais no site oficial da respectiva ferramenta e no Google. Simplesmente darei um overview apresentando as principais características, prós, contras e outras observações pertinentes.

Dividirei os posts, apresentando uma aplicação de cada vez. E começarei com o Munin.

1. Munin (http://munin.projects.linpro.no/)

É uma aplicação bastante simples de monitoramento de recursos de servidores. Permite a visualização via navegador de diversos gráficos referentes à uso de memória, espaço em disco, uso de CPU, tráfego de saída e entrada de dados, e outros. Sendo que cada fonte de dados, por padrão, é compilada em quatro gráficos (diário, semanal, mensal e anual). A coleta de dados é realizada através de um agendamento no cron do sistema, criado na instalação do Munin.

a. Instalação e configuração

No próprio site existe um guia abrangendo a instalação do Munin em diversas distribuições do Linux e até mesmo para o MacOS (no donuts for you, Windows users). Após esse processo, basta configurar o grupo e nome do servidor (como mostrado aqui) e configurar o Apache para permitir acesso ao “home” da aplicação (por padrão /var/www/munin/ ) através de algum URL.

O Munin é baseado em plugins, sendo que cada conjunto de gráficos é um plugin que pode ser instalado ou desinstalado fácil e independentemente. Basta criar ou excluir um link simbólico (atalho) na pasta /etc/munin/plugins do plugin desejado localizado em /usr/share/munin/plugins.

Além disso, é possível facilmente configurar o Munin para emitir alertas em certas condições como, por exemplo, quando o uso de CPU for maior que 80%. Isso pode ser feito integrando com o Nagios ou enviando e-mail através de do serviço sendmail ou um script externo.

b. Prós

• Simples, direto e rápido;
• Fácil configuração e permite a edição de plugins ou criação de novos;
• Possui opção de alertas em determinadas condições.

c. Contras

• A configuração do envio de alertas é muito básica, não permitindo controlar a quantidade ou a periodicidade dos envios. Se utilizado o Nagios, é possível configurá-lo para isso;
• Depende da disponibilidade do sistema para realizar o monitoramento. Se o servidor travar do nada, o Munin ficará travado também;
• Documentação online bagunçada e muitas vezes insuficiente para orientar novos usuários.

d. Observações adicionais

Por padrão, o Munin não apresenta um sistema de segurança para o acesso às suas informações. Uma forma bastante simples de fazer essa segurança é configurando o Apache para utilizar um arquivo de autenticação:

    <Directory /var/www/html/munin>
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
 
        AuthType Basic
        AuthName "My Server Munin"
        AuthUserFile /var/www/html/.htpasswd
        require valid-user
 
        Satisfy Any
    </Directory>

Então é isso. ^^

Espero em breve voltar com outro post sobre outra aplicação para o gerenciamento de servidores ou dando continuidade à série “Java para Web” =P

Neste post iremos ver como o Maven pode ajudar tanto na inclusão de dependências como em outras tarefas antes realizadas manualmente. Como o foco não será o projeto em si, utilizaremos o projeto do Teclado Virtual do post anterior.

Ao final do post existirão links para um pacote compactado com o projeto do tutorial e um exemplo (parcial) online do mesmo.

Ah… Quando criei esse blog alguns amigos de trabalho me disseram que logo logo eu pederia o ânimo pra postar… Pois é… >.<

1. Ambiente e Criação do Projeto

Primeiramente, utilizarei o NetBeans 6.5 com o plugin do Maven (basta buscar por “Maven” no filtro de plugin). E o Tomcat 6 (inclua-o no NetBeans). O código do teclado virtual será o mesmo do post anterior, com algumas pequenas alterações. Então vamos lá!

Tendo o plugin do Maven instalado, crie um novo projeto para o novo teclado virtual (Novo Projeto -> Maven -> Maven Project). Escolha o “Maven Quickstart Archetype” mesmo. Nomeei o meu projeto de “teclado-mvn” e coloquei o “Group Id” e o “Package” como “br.com.teclado.virtual.mvn”. Finalize.

Será criado um projeto java já nos moldes do Maven. Observe na pasta “Project Files” o arquivo “pom.xml”. Ele é o centro das configurações do Maven no seu projeto. Dentro da tag “dependency” haverá algumas entradas referentes ao “junit”. Isso quer dizer que o seu novo projeto é dependente do JUnit e tentará baixar o .jar referente do repositório padrão do Maven quando você for realizar algum teste (neste caso é em testes devido ao “scope” da dependência).

Agora vamos efetivamente “recriar” o teclado virtual. Apague as classes criadas automaticamente nos pacotes do projeto e copie a classe “TecladoVirtual.java” do projeto do post anterior para o pacote principal do novo projeto. Diversos erros deverão ser visíveis e, se você leu o post anterior, deverá saber o porquê.

No projeto original do teclado virtual, tínhamos que manualmente copiar o plugin.jar da pasta do JRE instalado para podermos utilizar a classe JSObject. Agora utilizaremos o Maven para fazer isso de uma maneira mais “elegante”.

2. Instalação e Utilização de Nova Dependência

Abra o “pom.xml” e vamos customizar a construção (build) do projeto. Em suma, o que faremos, é instalar o “plugin.jar” no repositório local e adicionar essa dependência ao teclado.

Para deixar mais claro, o que o Maven faz é, artravés do arquivo de configurações dele (pom.xml), identificar as dependências do projeto e baixar os seus jars do repositório remoto para uma pasta local na própria máquina (é chamado de “Repositório Local”). Então temos que incluir o “plugin.jar” no repositório local para podermos utilizá-lo.

No “pom.xml” adicione o seguinte treço dentro da tag <project>.

<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-install-plugin</artifactId>
         <version>2.3</version>
         <executions>
            <execution>
               <phase>generate-sources</phase>
               <id>generate-sources</id>
               <inherited>false</inherited>
               <configuration>
                  <groupId>java.plugin</groupId>
                  <artifactId>plugin</artifactId>
                  <version>1.6.0</version>
                  <packaging>jar</packaging>
                  <file>${env.JAVA_HOME}/jre/lib/plugin.jar</file>
               </configuration>
               <goals>
                  <goal>install-file</goal>
               </goals>
            </execution>
         </executions>
      </plugin>
      <plugin>
         <artifactId>maven-compiler-plugin</artifactId>
         <version>2.0.2</version>
         <configuration>
            <source>1.5</source>
            <target>1.5</target>
         </configuration>
      </plugin>
      <plugin>
         <artifactId>maven-compiler-plugin</artifactId>
         <version>2.0.2</version>
         <configuration>
            <encoding>ISO-8859-1</encoding>
         </configuration>
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
         <version>2.2</version>
         <configuration>
            <encoding>ISO-8859-1</encoding>
         </configuration>
      </plugin>
   </plugins>
</build>

Observando apenas a primeira tag <plugin>, temos que durante a fase (<phase>) do clico de vida de construção do projeto “generate-sources” (antes da compilação), irá executar a tarefa (<goal>) “install-file” da entidade (<artifactId>) “maven-install-plugin”. O arquivo a ser instalado (<file>) será o “plugin.jar” da JRE instalada e referenciada pela variável de ambiente “JAVA_HOME”. Após instalado, o jar poderá ser encontrado no repositório local pelo grupo “java.plugin”, artefato “plugin” e versão “1.6.0″.

Os plugins restantes na tag “build” são necessário para a execução completa do ciclo de vida da compilação feita pelo Maven.

Agora dê um “Limpar e Construir” (Clean and Build) no projeto e verifique se os erros no TecladoVirtual.java permanecem. Se sim, então está correto! =P

O que nós fizemos foi incluir o “plugin.jar” no repositório local, mas ainda não o incluimos no projeto. Antes disso, vamos conhecer o repositório local. Abra no Windows a sua pasta do “Documents and Settings” (C:\Documents and Settings\Usuario) e verá uma pasta “.m2″. Nela está o seu repositório local do Maven. Todas as dependências de projeto são baixadas para esta pasta de modo que não seja necessário baixar tudo novamente caso um novo projeto seja criado. Se você tentou construir o nosso novo projeto do teclado virtual, então já deve exisitir a pasta “.m2\repository\java\plugin\plugin\1.6.0″ com o “plugin-1.6.0.jar”. Agora, adicione esta dependência ao projeto.

No “pom.xml”, dentro da tag <dependencies>:

    <dependency>
       <groupId>java.plugin</groupId>
       <artifactId>plugin</artifactId>
       <version>1.6.0</version>
    </dependency>

Salve, limpe, compile e veja os erros do TecladoVirtual.java sumirem. Caso algum erro tenha ocorrido até este ponto, verifique se a variável de ambiente “JAVA_HOME” está devidamente setada e o caminho no “pom.xml” até o “plugin.jar” está correto.

Uma pequena alteração deve ser feita em relação ao projeto anterior do teclado virtual. Através do Windows, crie a pasta “resources” (“teclado-mvn\src\main\resources”) no novo projeto e copie as imagens do teclado para esta pasta. No NetBeans deverá aparecer a pasta “Other Sources”. E no “TecladoVirtual.java” altere o caminho à imagem de “/resources/teclado1.JPG” para “/teclado1.JPG”.

Veja a imagem de como ficou:

(abrir em nova janela)

3. Codificação da Senha do Teclado

O que faremos agora é uma alteração no código do teclado virtual para que a senha copiada ao campo oculto do formulário HTML seja previamente codificada com MD5 impossibilitando a obtenção da senha original mesmo que o valor do campo oculto seja lido.

Mas antes precisamos incluir uma dependência ao projeto; é o “commons-codec”. Se você está utilizando o NetBeans e ainda não descobriu a grande vantagem da IDE sobre a edição de XMLs, tente usar agora o auto-completar (CTRL+espaço) para encontrar o <groupId> e o <artifactId> desta nova dependência. Assim que o projeto foi criado, o plugin do Maven deve ter baixado (ou tentado baixar) um índice de dependências do repositório remoto contendo os grupos e artefatos disponíveis. A única demora deverá ser para encontrar as versões (<version>) disponíveis, pois ele precisará procurar em tempo real no repositório remoto.

Então adicione dentro da tag <dependencies>:

    <dependency>
       <groupId>commons-codec</groupId>
       <artifactId>commons-codec</artifactId>
       <version>1.3</version>
    </dependency>

Com isso, podemoremos usar o pacote “java.security.MessageDigest” para codificar a senha. Sem maiores explicações (para não fugir do foco e para não me estender demais), o métodos para codigicação de Strings em MD5 deverá ficar assim:

   /**
    * Encripta um texto em MD5
    *
    * @param texto
    * @return String
    */
    private String md5Encrypt(String texto)
    {
       String encripted = null;
       try{
          MessageDigest md = MessageDigest.getInstance( "MD5" );
          md.update( texto.getBytes() );
          BigInteger hash = new BigInteger( 1, md.digest() );
          encripted = hash.toString( 16 );
       }
       catch(NoSuchAlgorithmException ns)  {
          ns.printStackTrace();
       }
       return encripted;
    }

Agora basta utilizar este método codificar a senha no momento de enviar ao HTML:

    win.eval("recebeSenha('" + md5Encrypt(senha) + "'," + senha.length() + ")");

4. Criação do Projeto Web para Utilização do Teclado Virtual

Vamos criar outro projeto Maven seguindo os mesmos passos do projeto anterior, mas escolheremos “Maven Webapp Archetype” depois de Arquivo -> Novo Projeto -> Maven -> Maven Project. Os nomes que utilizei foram “teste-teclado-mvn” no nome e “br.com.teclado.virtual.mvn” como nome de grupo e empacotamento.

Alguém notou alguma semelhança dos dados que incluímos na criação de um projeto Maven com os dados utilizados para a adição de uma dependência? Pois é, quando compilamos um projeto, uma das fases executada é a instalação desse projeto no repositório local, sob o Grupo e Artefato utilizados na criação do mesmo. Assim, outros projetos podem ser dependentes do projeto instalado. Mas não é exatamente este o caso da relação Teclado Virtual – Projeto Web.

O projeto web não é exatamente dependente do Teclado Virtual para realizar alguma tarefa ou utilizar algum método. O jar do teclado deve apenas estar presente para que o navegador do usuário possa baixar e executá-lo. Então, ao invés de simplesmente adicioná-lo como um dependência, iremos copiar o jar que se encontra no repositório local para uma pasta do projeto web, tornando-o diponível ao usuário.

Sem mais enrolação, insira o trecho a seguir dentro da tag <project> do “pom.xml” do projeto web.

 <build>
    <finalName>teste-teclado-mvn</finalName>
    <plugins>
       <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-dependency-plugin</artifactId>
          <version>2.1</version>
          <executions>
             <execution>
                <phase>compile</phase>
                <id>copy-teclado</id>
                <inherited>false</inherited>
                <configuration>
                   <artifactItems>
                      <artifactItem>
                         <groupId>br.com.teclado.virtual.mvn</groupId>
                         <artifactId>teclado-mvn</artifactId>
                         <version>1.0-SNAPSHOT</version>
                         <destFileName>teclado-mvn.jar</destFileName>
                      </artifactItem>
                      <artifactItem>
                         <groupId>commons-codec</groupId>
                         <artifactId>commons-codec</artifactId>
                         <version>1.3</version>
                         <destFileName>commons-codec.jar</destFileName>
                      </artifactItem>
                   </artifactItems>
                   <overWriteIfNewer>true</overWriteIfNewer>
                   <overWriteSnapshots>true</overWriteSnapshots>
                   <overWriteReleases>true</overWriteReleases>
                   <outputDirectory>/src/main/webapp/applet</outputDirectory>
                </configuration>
                <goals>
                   <goal>copy</goal>
                </goals>
             </execution>
          </executions>
      </plugin>
   </plugins>
</build>

Em suma, durante a fase (<phase>) de compilação o Maven irá copiar (<goal>) as dependências (<artifactItems>) referentes ao projeto do Teclado Virtual e ao pacote do “commons-codec”, renomeando-os para “teclado-mvn.jar” e “commons-codec.jar”, para a pasta (<outputDirectory>) “/src/main/webapp/applet”. Esta pasta estará no mesmo nível do “index.jsp” do projeto.

O “commons-codec” teve que ser copiado também pois onde o jar do teclado executará (no navegador do usuário) nem sempre existe esta biblioteca. Se quiser testar sem a instrução para copiar este pacote, não tem problema, a princípio.

Por último, podemos alterar o “index.jsp” para utilizar o Teclado Virtual. Vamos simplesmente copiar o código do HTML de teste do post sobre o Teclado Virtual, lembrando de alterar os valores da variáveis “clazz” e “jar” para “br.com.teclado.virtual.mvn.TecladoVirtual.class” (ou como você nomeou sua classe/pacote) e “applet/teclado-mvn.jar”, respectivamente.

Se deu tudo certo, ao executar o projeto web, deverá aparecer o teclado virtual e, ao submeter a página, no endereço da mesma deverão estar o nome do usuário e a senha codificada.

Então é isso! Finalmente consegui publicar um post depois de tanto tempo! \o/

Para encontrar outras operações disponíveis pelo Maven, tente o Oráculo ou tente explorar os artefatos do Grupo “org.apache.maven.plugins” (incluso em ambas operações descritas anteriormente).

cya.

Projeto do Teclado Virtual com Maven compactado e configurado no NetBeans: teclado-mvn

Exemplo Online do teclado com a codificação da senha: teclado-mvn-online

Vai ter palestras com gente que manja do assunto como Luli Radfahrer, Interney e Marcelo Tas.

Você pode Conferir uma das palestras do Luli aqui no blog do focezar mesmo, enjoy!

O Evento:

Workshop de Mídias Sociais

A programação do Evento está aqui!

E as inscrições para as palestras gratuitas podem ser feitas por aqui! (Tem que fazer inscrição para cada uma das palestras desejadas)

A palestra do Marcelo Tas custa 30 reais, 15 reais para estudantes, e os ingressos podem ser adquiridos direto no Sebrae.

Além das palestras, vão ocorrer oficinas de diversos temas.

É isso, até lá!

PS: Post kibado do focezar ^^