03 3 / 2013
Open Source License Generator
Gere a licença para seu projeto “de boa”!
Exemplos com MIT:
Terminal:
curl http://oss-license-generator.herokuapp.com/index.php/generate/mit -d licenser="Seu nome aqui" -d year="2013" > LICENSE
Browser:
"http://oss-license-generator.herokuapp.com/index.php/generate/mit/Seu nome aqui/2013"
Source:
https://github.com/jgskin/oss-license-gen https://packagist.org/packages/keep/oss-license-gen
Obs: No heroku o código foi ligeiramente alterado. tsc…
28 10 / 2012
Utilizando git para construir o changelog do projeto
O CHANGELOG é um documento importante para qualquer projeto, pois nele podemos observar exatamente o que foi alterado em cada release.
Fiz um pequeno passo a passo com o git e compartilharei com vocês:
- Escreva comentários que realmente descrevam a alteração efetuada;
- Não efetue commit de tarefas inacabadas;
- Utilize o comando “rebase” ao invés do “merge” após o lançamento de uma nova versão.
Exemplo de utilização do “rebase”
Nosso projeto teve sua primeira versão lançada.
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
E então, começamos a trabalhar na próxima versão com a branch “newrls”.
commit 1f894549fd5c551fb32557c14cc6ea3e78ead67a
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:07:11 2012 -0200
b2
commit c678cf3a776316e97a9d9b759a0f0e7cdd0c2257
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:04:49 2012 -0200
b1
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
Porém, antes de entregarmos a nova versão, descobrimos um bug que deveria ser resolvido antes da entrega. Criamos, então, a branch “fixsomthing” e fizemos o deploy da versão “0.2”.
commit a1ff9f207e9428e67cf65932aa0fdd47e2572f40
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:08:53 2012 -0200
c1
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
A Maneira incorreta
Agora, observe bem: Se ao voltarmos a trabalhar no nosso próximo release utilizarmos o comando “merge”, teriamos a seguinte resposta do comando “log”:
commit c60538eda31bc57c6024a3a1cd910c9fdd86e6d8
Merge: 1f89454 a1ff9f2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:51:14 2012 -0200
Merge branch 'fixsomething' into newversion
Conflicts:
unique
commit a1ff9f207e9428e67cf65932aa0fdd47e2572f40
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:08:53 2012 -0200
c1
commit 1f894549fd5c551fb32557c14cc6ea3e78ead67a
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:07:11 2012 -0200
b2
commit c678cf3a776316e97a9d9b759a0f0e7cdd0c2257
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:04:49 2012 -0200
b1
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
Observaram o problema? “c1” deveria vir antes de “b1”, pois ele foi lançado antes.
A maneira correta
À partir da branch “newrls” executamos o rebase:
git rebase 0.2
Nosso log, agora, mostra a timeline correta dos releases:
commit a3b0a3d25c80453acace1778b53b90cac3693f57
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:07:11 2012 -0200
b2
commit cdd41db6244e5c6424609d634792765eb19301e5
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:04:49 2012 -0200
b1
commit a1ff9f207e9428e67cf65932aa0fdd47e2572f40
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:08:53 2012 -0200
c1
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
A partir daí, gerar o changelog é apenas uma questão de executar o comando log com os argumentos corretos.
git log 0.1
git log 0.1..0.2
git log 0.2..HEAD
CHANGELOG
**v 0.3**
commit a3b0a3d25c80453acace1778b53b90cac3693f57
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:07:11 2012 -0200
b2
commit cdd41db6244e5c6424609d634792765eb19301e5
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:04:49 2012 -0200
b1
**v 0.2**
commit a1ff9f207e9428e67cf65932aa0fdd47e2572f40
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:08:53 2012 -0200
c1
**v 0.1**
commit f0bffcefe121d8dbd20e6f80b456798df8db36e2
Author: Jessé Alves Galdino <galdino.jesse@gmail.com>
Date: Sun Oct 28 12:02:33 2012 -0200
a1
02 9 / 2012
NoteWorthy
Criei um projeto novo no github, o NoteWorthy (python/django) (https://github.com/jgskin/noteworthy).
O intuito é “brincar” com testes unitários a fim de descobrir até aonde vale a pena fazê-los.
27 8 / 2012
Ambiente de desenvolvimento Python no Android
Sem um notebook por perto?
Configure um ambiente para desenvolvimento em Python no seu Android.
Instale os seguintes pacotes:
SL4A:
Python for Android:
http://code.google.com/p/python-for-android/
O programa é um instalador. Você deverá executa-lo e seguir as instruções para realmente instalar o Python.
DroidEdit:
Esse último não é necessário, porém é um editor de texto razoável com python synthax highlight.
https://play.google.com/store/apps/details?id=com.aor.droidedit.pro&feature=search_result#?t=W251bGwsMSwxLDEsImNvbS5hb3IuZHJvaWRlZGl0LnBybyJd
Obs:
- A partir do SL4A você poderá executar alguns scripts para teste ou chamar o Python Interpreter.
- O DroidEdit possui um atalho para executar os scripts.