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:

  1. Escreva comentários que realmente descrevam a alteração efetuada;
  2. Não efetue commit de tarefas inacabadas;
  3. 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:

http://code.google.com/p/android-scripting/

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.