Jenkis Meetup / Vídeo da palestra de Liquibase

Em primeiro lugar, peço desculpas aos meus leitores (todos os 5 deles) por não ter postado nada nos últimos 5 meses.
Acontece que o FreedomSponsors tem tomado praticamente todo o tempo que eu estou no computador e não estou trabalhando no meu emprego primário :-).

Há 15 dias participei de um evento muito legal, o Jenkins Meetup São Paulo – um encontro pra falar de Jenkins e tecnologias relacionadas.
Lá conheci o Kohsuke Kawaguchi pessoalmente! Pra quem não sabe:

* Kohsuke Kawaguchi: criador do Jenkins (antigamente conhecido como Hudson)
* Jenkins: Um excelente servidor de integração contínua usado por milhares de empresas no mundo todo.

Tomei cerveja com o cara, rá! 🙂

O evento foi muito legal, as palestras foram muito boas. A que eu mais gostei foi a do próprio Kohsuke.
O Kohsuke gravou todas as palestras e está tudo no Youtube (uhuuuu!), veja:
http://t.co/QO9EAmps

Eu tb dei aquela minha palestrinha de liquibase, e agora tem o videozinho dela aqui pra vcs:

Anúncios

Configurando o liquibase num projeto pequeno usando maven

Oba, código pronto!

Olha eu gosto de escrever sobre essas coisas, tecnologia e tal.
Mas faz tempo q não atualizo o blog por falta de tempo.
Peço desculpas à multidão dos meus 5 seguidores por isso 🙂

Anyway, eu preparei um exemplinho aqui de como estruturar um projeto pequeno, usando maven e liquibase.
(É bom quando a gente tá procurando na internet como fazer alguma coisa e tem o código pronto né? Eu gosto!)

Estou assumindo que vc leu os posts anteriores e possui um conhecimento básico de maven (sabe o que é um pom, já fez alguns “clean install” na vida, etc).
Se não, veja:
1) Esse link; e
2) esse outro link; e

O código tá lá no bitbucket. Se vc tem um clientezinho GIT, clone o repositório:

git clone https://bitbucket.org/tonylampada/tonylampada_examples.git

Se não, vai lá e clica em “get source” e baixa o zip.

Lá dentro tem uma pasta LIQUIBASE/exemplo.

A estrutura é mais ou menos assim:

exemplo
-- pom.xml //pom que agrega os 2 sub-módulos
-- exemplo-liquibase
---- liquivai.vat
---- mostrabanco.bat
---- pom.xml
---- src/main/resources
------ master.xml
------ exemplo
-------- 1.0
---------- master.xml
---------- (outros changelogs)
-------- 1.1
---------- master.xml
---------- (outros changelogs)
-- exemplo-web
---- pom.xml
---- src //faz de conta que isso aqui é uma aplicação web

Os xmls estão numa estrutura tal que os patches são executados na ordem cronológica das versões.
A hora que vc for criar sua estrutura, sugiro não inventar muita moda não: segue essa mesma receitinha aí que deve dar certo. E lembre-se de não renomear os arquivos e pastas, conforme mencionado no post anterior.

Esse módulo maven “exemplo-liquibase” é um cara que se vc fizer um “clean install” nele, ele vai simplesmente gerar um jar com esse monte de xml dentro. Não é esse o maior objetivo da vida dele.

Tem outra coisa bem mais interessante que ele sabe fazer: aplicar esse conjunto de changelogs no banco.
Pra isso vc deve rodar o seguinte comando (no diretorio exemplo-liquibase)

mvn clean package liquibase:update 

Ou simplesmente roda esse “liquivai.bat” que tem aí.

O que torna isso possível é a configuração do pom dele, através do uso do liquibase-maven-plugin.
A parte relevante do pom é a seguinte:

  <plugin>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-maven-plugin</artifactId>
    <version>2.0.1</version>
    <configuration>
      <changeLogFile>master.xml</changeLogFile>
      <driver>org.hsqldb.jdbcDriver</driver>
      <url>jdbc:hsqldb:file:banquinho;shutdown=true</url>
      <username>sa</username>
      <password></password>
      <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
      <verbose>true</verbose>
    </configuration>
  </plugin>

O que acontece na hora que vc roda esse comando é o seguinte:

Na hora do “package”, uma das coisas que o maven faz é copiar o conteúdo do src/main/resources pra dentro de target/classes.

O diretório target/classes é que é levado em consideração pelo liquibase-plugin na hora de buscar os arquivos changelog.
Ou seja, essa configuração “master.xml” se refere ao caminho do arquivo relativo a esse diretorio, blz?

Aí, depois do goal “package”, o liquibase:update aplica os patches no banco.
Que banco? Esse banco “banquinho” aí, que vai ser criado em HSQL no seu disco a primeira vez que vc rodar.
Por isso o plugin precisa tb da dependência do driver do hsql.

<dependency>
  <groupId>org.hsqldb</groupId>
  <artifactId>hsqldb</artifactId>
  <version>2.2.8</version>
</dependency>

Pra quem não conhece, o hsql é um banco de dados “pure java” que pode rodar em memoria ou persistido no disco.
É muito bom pra fazer testes em ambiente de desenvolvimento, e há quem use até em produção tb.

Depois de rodar o liquibase:update, tem um outro “mostrabanco.bat” que vc pode rodar – esse cara executa um utilitário do hsql que abre uma tela de administracao do banco. Vc pode executar comandos SQL aí (dá uma olhada aí no bat e no pom pra entender como que eu configurei isso – é bem simples)

Se vc usa outro banco diferente desse (provavelmente é o caso né…), vc já deve saber o que fazer: colocar a dependência pro driver do seu banco e mexer nas configurações de url, driver, usuario e senha.

Mais detalhes sobre a configuração do plugin no maven, lá no site do liquibase.

Ah, já acabou?

É, esse post era pra ser curtinho mesmo.
O que interessa mesmo é o código pronto que tá lá pra vc baixar.
Essa estrutura simples aí deve ser suficiente pra uma aplicação pequena.

Se vc precisa disso pra uma aplicação maiorzinha, com diferentes módulos, que lidam com partes diferentes do banco, e tem diferentes equipes desenvolvendo, então a solução pra vc precisa de uma estrutura mais complexa…
Cada módulo vai ter que ter o seu jarzinho de xmls liquibase, e depois vc vai ter que dar um jeito de juntar tudo e executar no banco. Mas isso já é assunto pro próximo post…

É isso aí.
Bubble sorte!

[ ]’s
O Lâmpada

Não perca nos próximos posts:

  • Estendendo a estrutura anterior para um projeto grande e modular
  • O que fazer quando houver dependências cíclicas entre os módulos no nível do BD
  • Incluindo testes para os patches liquibase no processo de integração contínua
  • Use o liquibase para reduzir drasticamente o tempo de deploy de novas versões em um ambiente de produção

Lista de boas práticas de codificação


A idéia deste blog é que seja em português.

Este post, excepcionalmente, vai em inglês mesmo, simplesmente pq o conteúdo original está assim.

É que o conteúdo abaixo é uma compilação de boas práticas que eu fiz há um tempo, tirado de várias fontes: o livro Code Complete, o StackOverflow, e uma ou outra coisinha da minha experiência mesmo.

É o tipo da coisa que uma empresa do software pode dar um ctrl+chups e estabelecer como “conjunto de diretrizes” para os programadores, ou então usar como checklist pra atividades de revisão de código.

Segue abaixo parte do conteúdo.
Veja o bicho inteiro aqui.

Enjoy the free lunch 🙂

[ ]’s
O Lâmpada

Best practices for software coding.

Good coding practices help avoiding having a bad design.
There are some important characteristics of a good design that we should strive to achieve:

  • Flexibility – It is easy to change code because it is possible to alter behaviour of a single part of the system, without affecting too many other parts of the system.
  • Robustness – When you make a change, no unexpected parts of the system break.
  • Mobility – It is easy to reuse in another application because it can be easily disentangled from the current application.
  • Readability – It is easy to modify code that is easy to understand.

Coding in General

01 – Self documenting code
Improves: readability

“Any fool can write code that a computer can understand.Good programmers write code that humans can understand.”
— Martin Fowler, Refactoring: Improving the Design of Existing Code

Rather than trying to document how you perform a complex algorithm, try to make the algorithm easier to read by introducing more identifiers. Also, always try to make sure that you are using identifiers that makes the purpose very straightforward. This helps in the future in case the algorithm changes but someone forgets to change the documentation.

Here´s an example that should not be followed:

//Please don't do this
for ( i = 1; i <= num; i++ )
{
meetsCriteria[ i ] = True;
}
for ( i = 2; i <= num / 2; i++ )
{
j = i + i;
while ( j <= num )
{
meetsCriteria[ j ] = False;
j = j + i;
}
}
for ( i = 1; i <= num; i++ )
{
if ( meetsCriteria[ i ] )
{
System.out.println ( i + " meets criteria." );
}
}

Now, what do you think this routine does? It’s unnecessarily cryptic. It’s poorly documented not because it lacks comments, but because it lacks good programming style. The variable names are uninformative, and the layout is crude. Indentation also does not reflect the flow of code. Here’s the same code improved.
Just improving the programming style makes its meaning much clearer

//Yes, do it like this
for ( primeCandidate = 1; primeCandidate <= num; primeCandidate++ ) {
	isPrime[ primeCandidate ] = True;
}
for ( int factor = 2; factor < ( num / 2 ); factor++ ) {
	int factorableNumber = factor + factor;
	while ( factorableNumber <= num ) {
		isPrime[ factorableNumber ] = False;
		factorableNumber = factorableNumber + factor;
	}
}
for ( primeCandidate = 1; primeCandidate <= num; primeCandidate++ ) {
	if ( isPrime[ primeCandidate ] ) {
		System.out.println( primeCandidate + " is prime." );
	}
}

The difference between the two code fragments has nothing to with comments. Neither fragment has any. The second one is much more readable, however, and approaches the Holy Grail of legibility: self-documenting code. Such code relies on good programming style to carry the greater part of the documentation burden.
In code well written like this one, comments are often unneccessary.

(etc etc etc)
Clique no link acima (no começo do post) pra ver o documento inteiro.