Trabalhando com 2 repositórios Git

Pessoal.. temos um repositório Git na minha empresa e todos os desenvolvedores fazem commit e push lá. E de tempos em tempos fazemos o push desses fontes para o repositório Git que fica no nosso cliente.

Vou explicar uma estratégia simples e comumente usada nesse cenário.

Com essa estratégia que vou explicar você mantém o histórico de commits e permite a realização de merges caso outras pessoas commitem no mesmo projeto no repositório do cliente.

Seguinte:

No Git, cada commit tem um id.. que é um hash único...

Quando você tem 2 repositórios, um commit deve ter o mesmo id nos 2 repositórios...

O histórico de commits de um, será o mesmo no outro... geralmente é muito importante manter o histórico dos commits...

Para isso, você adiciona dois remotes no seu projeto (no nosso caso era só adicionar o segundo, já que o primeiro já tínhamos)

git remote add origin http://www.minhaempresa.com.br/git/projeto.git
git remote add cliente http://www.meucliente.com.br/git/projeto.git

Depois é só você escolher onde quer fazer push

git push origin master

ou

git push cliente master

Você pode até dar um git config e definir qual dos dois remotes é o padrão para quando você digitar apenas "git push" ele saber qual usar.

É isso!

Abraços!
Adriano Schmidt

Seminário JBoss/WildFly - Avançado

Nesse sábado (14/06/2014) aconteceu o primeiro Supero TechDay!

Estou muitíssimo feliz pelo evento! Todo mundo muito empolgado trocando conhecimentos e experiências.

Valeu muito à pena! Estou muito orgulhoso e feliz por trabalhar na Supero TI (www.supero.com.br) e muito satisfeito por estar numa equipe com tanta gente bacana!

Neste evento fiz uma apresentação onde explanei sobre o JBoss e sua mais nova versão o WildFly. Abordei a história, arquitetura, funcionamento e dicas sobre o JBoss/WildFly e mostrei em funcionamento um ambiente com um Apache HTTP Server como load balancer e proxy reverso com vários JBoss em cluster.



Não poderia deixar de agradecer ao JBUG Brasil e todos os seus membros, especialmente ao Maurício Magnani (https://jbossdivers.wordpress.com/), que me ajudaram muito a ter o conhecimento que tenho hoje sobre JBoss.

Cuidados ao entrar num projeto novo

Pessoal... queria dar algumas dicas para quando você for entrar um projeto novo...

1) Ctrl+Shift+F
Nunca dê um Ctrl+Shift+F no projeto inteiro.. nem na classe que você está alterando...

Um Ctrl+Shift+F atrapalha muito a realização de merges e de certa forma faz você perder o histórico de alterações no controle de versão, pois vai ser difícil comparar algo com uma versão antiga pois vai estar com uma formatação toda diferente.

Se você está criando uma classe nova, tudo bem, mas muito cuidado ao mexer em códigos já existentes.

Caso você crie um método novo, você pode selecionar esse método, e dar um Ctrl+Shif+F, pois vai formatar apenar o trecho de código selecionado, mantendo intacto o resto da classe.

Tem até como criar um xml de formatação no eclipse e depois as outras pessoas podem importar em seus eclipses, mas acho muito trabalhoso manter isso.

Caso seja decidido aplicar algo no projeto inteiro, isso deve ser bem pensado, nunca é só chegar e fazer.

2) Encoding no eclipse
Antes de salvar uma classe verifique se o encoding do projeto no seu eclipse está correto, veja se os acentos não vão virar caracteres estranhos..
Isso é muito comum quando uma equipe usa windows e entra alguém que usa linux ou vice-versa.
Para mudar o encoding do seu projeto no eclipse é só ir nas propriedades do projeto no eclipse.

Caso você ache que o encoding poderia ser outro, converse com a equipe, nunca chegue e mude por conta própria.

3) Encoding no maven
Nunca altere o encoding do projeto no maven colocando no pom a linha abaixo:
UTF-8

Se for fazer isso converse com alguém que já está no projeto ou então você deve saber o que está fazendo.. uma dica é, se for fazer, faça apenas local.

4) Não use acentos em comentários
O título é auto explicativo, a ideia é simples, se não tem acentos, diminui a probabilidade de problemas com encoding. Ah, e sempre é bom falar, em nome de variável também não se deve usar ç ou coisas assim.

Essas simples ações tornam o ambiente de trabalho melhor, faça o bem sem olhar a quem! :D

PS: Escrevi tudo isso e mandei para todos os desenvolvedores da empresa que trabalho depois de passar muitas horas (muitas mesmo) fazendo um merge de um projeto gigante e corrigindo caracteres especiais. Então, não falo por mal, falo para evitar que outras pessoas passem por esse sofrimento.

Abraços!
Adriano Schmidt

Deletar todas as tabelas de um banco de dados Oracle

Script que deleta todas as tabelas do banco:

begin
 for deleta in (select table_name, 'DROP TABLE '||table_name||' cascade constraints' AS dropar from user_tables) loop
 BEGIN
  EXECUTE IMMEDIATE deleta.dropar;
  dbms_output.put_line('DROP TABLE '||deleta.table_name||' cascade constraints;');
  EXCEPTION WHEN OTHERS THEN
  dbms_output.put_line('Erro ao tentar dropar a tabela:'||deleta.table_name);
 END;
 end loop;
end;

Simples e rápido!

Para deletar todas as sequences do banco é só rodar o seguinte comando:

begin
 for deleta in (select sequence_name, 'DROP SEQUENCE '||sequence_name||' ' AS dropar from user_sequences) loop
 BEGIN
  EXECUTE IMMEDIATE deleta.dropar;
  dbms_output.put_line('DROP SEQUENCE '||deleta.sequence_name||' ;');
  EXCEPTION WHEN OTHERS THEN
  dbms_output.put_line('Erro ao tentar dropar a tabela:'||deleta.sequence_name);
 END;
 end loop;
end;

Fonte: http://golker.blogspot.com.br/2009/05/dropar-todos-os-tipos-e-tabelas-no.html

Abraço!
Adriano Schmidt

Dividir arquivos grandes no windows ou linux

Hoje precisava alterar um arquivo .SQL de 1,2GB e não conseguia abri-lo.

Então tive que dividi-lo.

No linux é só você rodar o comando

split -b 30720k nome_do_arquivo_grande.sql

E ele vai dividir o arquivo grande em arquivos de 30MB, você pode alterar o tamanho, alterando o comando acima.

No windows, você pode usar o mesmo comando, mas para isso precisa instalar o MobaXTerm ( http://mobaxterm.mobatek.net/ )

Após instalar, é só ir até a pasta do arquivo (a unidade C fica em /mnt/c/) e rodar o comando split:

cd /mnt/c/pasta_onde_esta_o_arquivo_grande
split -b 30720k nome_do_arquivo_grande.sql

Fonte: http://www.vivaolinux.com.br/dica/Como-dividir-arquivos-grandes-(split)

Abraços!
Adriano Schmidt

Renomear arquivo com caracteres especiais no linux

Pessoal, estava apanhando aqui para um arquivo cujo nome tinha caracteres especiais: (ConfiguraçoÌes_de_Acesso).pdf

Renomeá-lo não foi fácil. Consegui essa proeza rodando comando "ls -i" que exibe uma espécie de id do arquivo:

[user@MAQUINA01 PASTA]$ ls -i
5835097 Arquivo01.sql
5835105 (ConfiguraçoÌes_de_Acesso).pdf
5835101 Log_01.txt

E com o id do arquivo usei o comando abaixo para renomeá-lo:

[user@MAQUINA01 PASTA]$ find . -inum 5835105 -exec mv {} Configuracoes_de_Acesso.pdf \;

Pronto, arquivo renomeado :)

Fonte: http://www.unix.com/tips-and-tutorials/198879-how-manage-file-names-special-characters.html

Abraços!
Adriano Schmidt

show_sql=true não exibe os parâmetros

Após setar o show-sql como true no meu persistence.xml no meu projeto que roda no JBoss EAP 6.2 (ou Jboss AS7, ou WildFly) as queries apareceram no log, mas o valor dos parâmetros não. Aparecia somente assim:

21:10:03,314 INFO  [stdout] (http-/0.0.0.0:8080-3) Hibernate: select exemplo0_.COL_X from EXEMPLO exemplo0_ where exemplo0_.COL_Y =?

Para fazer os valores aparecerem entrei no arquivo standalone.xml do meu JBoss e fui no subsystem logging (esse arquivo tem várias tags subsystem, uma delas tem o name logging)

Então, junto com os outros loggers adicionei o logger abaixo:

<logger category="org.hibernate.type.descriptor.sql.BasicBinder">
     <level name="TRACE"/>
</logger>

Após reiniciar o JBoss, o log ficou assim:

21:15:04,234 INFO  [stdout] (http-/0.0.0.0:8080-3) Hibernate: select exemplo0_.COL_X from EXEMPLO exemplo0_ where exemplo0_.COL_Y =?
21:15:04,234 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-/0.0.0.0:8080-3) binding parameter [1] as [BIGINT] - 600

Fonte: http://stackoverflow.com/questions/9159752/how-to-get-jdbc-binding-parameters-from-hibernate-in-jboss-7

"A melhor tecnologia é a que eu domino!"

Hoje venho divagar sobre a questão: "Devo usar a tecnologia que domino mais ou o a mais adequada ao projeto?"

Essa é uma decisão difícil e alguns fatores devem ser considerados.

Cada tecnologia tem suas vantagens e desvantagens..
JSF tem as suas.. Flex tem as suas.. HTML5 tem as suas.. PHP tem as suas..
Cada tecnologia tem situações em que ela se encaixa melhor..

Muitas empresas decidem usar tecnologias com base na experiência dos desenvolvedores, é uma decisão comum e muitas vezes assertiva... mas algumas vezes isso não se conjectura como melhor escolha e é necessário tomar outra decisão...

Uma grande empresa que trabalhei desenvolveu muitos sistemas em Flex.. e agora está reescrevendo tudo... (Não quero julgar esse caso em específico, só estou dando um exemplo).

Nesta mesma empresa iríamos desenvolver um sistema de ponto eletrônico e controle de acesso (catracas)... na época estava surgindo o JSF2.. todo mundo falou pra usar o JSF 1.2 até porque haviam outros sistemas em JSF 1.2 na equipe.. eu contrariei o que as pessoas falaram e desenvolvi em JSF 2... recebi muitas críticas por isso, mas permaneci firme porque sabia que era o mais acertado.. esses outros sistemas já existentes usavam Spring e eu coloquei EJB/JPA no projeto mesmo que ninguém na equipe conhecia isso... Usei JBoss ao invés de Tomcat... Enfim, a arquitetura mudou bastante em relação aos projetos existentes.
Seis meses depois.. todos os sistemas desenvolvidos em JSF 1.2 e Spring foram reescritos em JSF 2 e EJB...

Em outra empresa, entrei em um cliente e começamos a usar o Git ao invés de SVN.. fui muito criticado por causa disso pelos desenvolvedores que apenas conheciam SVN... e hoje está mais que provado que foi a melhor escolha...

Em um projeto novo que está começando agora e estou envolvido surgiu a discussão HTML5xJSF... Queriam utilizar JSF pois a equipe atual domina mais esta tecnologia.. Caso seja escolhido HTML5 muita gente vai criticar, no primeiro problema que alguém tiver vai reclamar e vai falar "Se fosse JSF já estaria pronto", porém, com JSF também teríamos problemas..

Entendo que no início a produtividade seja mais baixa com HTML5, porém em pouco tempo isto mudará.

Neste projeto em específico acredito que não devemos usar JSF só por que conhecemos mais, não seria a melhor escolha para esse projeto pois JSF foi criado para sistemas corporativos.. enterprise... Para um número não muito grande de usuários simultâneos. Que não é o cenário do novo projeto.

Claro que outros fatores como prazo, orçamento, se os envolvidos querem pensar a curto ou longo prazo, abertura a assumir riscos, entre outros, vão influenciar na escolha também, mas escolher a tecnologia mais adequada deve pelo menos entrar nas discussões.

Enfim, a frase "A melhor tecnologia é a que eu domino" é muito comum, porém, nem sempre funciona.

JBoss x Tomcat

Por que usar JBoss ao invés de Tomcat?

Primeiramente é bom explicar que o Tomcat é um Web Container (contém engines para Servlet e JSP), já o JBoss é um Application Server (container para a plataforma JEE, contém um Web Container, porém tem um EJB container e outras engines).

Para aplicações simples você consegue utilizar um Web Container, para aplicações com mais tecnologias (EJB por exemplo), você até consegue usar um Web Container, porém, terá que adicionar muitas bibliotecas e configurações nele. Em um Application Server tudo é nativo.

Em 2010 por exemplo, fazia muito sentido utilizar apenas um Web Container para uma aplicação simples pois os Application Servers eram muito pesados, consumiam muitos recursos computacionais, demoravam para iniciar e eram difíceis de manter, porém os Application Servers em 2014 não tem mais estes problemas. A própria Apache, criadora do Tomcat, criou seu próprio Application Server chamado TomEE para ser usado no lugar do Tomcat. (http://tomee.apache.org/apache-tomee.html)

Os Application Servers trabalham com profiles, que define o que será carregado, o profile mais leve dos Application Servers é como um Web Container, por isso, não existe mais a necessidade de se trabalhar com Tomcat em projetos novos, a não ser que você queira manter padrão com outras aplicações da empresa ou algo assim, porém, essa decisão traria muitas outras dificuldades para o desenvolvimento e controle da infraestrutura de uma aplicação JEE.

Abraços!
Adriano Schmidt

Instalando JRockit no RHEL

Sempre em ambientes de produção em clientes costumo usar a JDK JRockit, ela é melhor para ambientes de missão crítica pois utiliza melhor a memória, garbage collector, entre outras coisas...

Mais detalhes em: http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

Para instalar é muito simples:

* Baixe o JRockit
http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

* Vá até a pasta onde está o instalador (arquivo .bin) (troque o /app pelo caminho onde está o .bin que você baixou)
$ cd /app

* Dê permissão de execução para esse arquivo (coloque o nome do arquivo que você baixou)
$ sudo chmod +x jrockit-jdk1.6.0_45-R28.2.7-4.1.0-linux-x64.bin

* Execute o .bin
$ sudo ./jrockit-jdk1.6.0_45-R28.2.7-4.1.0-linux-x64.bin

* Então é só ir apertando enter, ou caso queira mudar diretório de instalação, instalar os fontes da JDK entre outras coisas é só ir escolhendo, caso contrário é só apertar enter até o final.

Caso tenha alguma dúvida sobre o "sudo", ele serve para você poder executar um comando como se você fosse o usuário root, o seu usuário deve ter permissão para poder usar o "sudo".

Enfim, é isso! : )

Abraço!!!
Adriano Schmidt