TDD Monitor

[Rodolfo Carvalho]

Alo galera,

Encotrei agora a pouco um script para facilitar o TDD com Python e nose... quem sabe tentar usar isso num dojo :P

https://code.launchpad.net/~objarni/+junk/pytddmon

Junta-se ao timer e daqui a pouco teremos um dojo-suite...


[]'s

Rodolfo Carvalho

[Israel da Silva Teixeira]

Maneiro!!
Precisamos inclui-lo ao nosso ambiente.

2009/12/16 Rodolfo Carvalho <rhcar...@gmail.com>

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
Israel Teixeira

[Hugo Lopes Tavares]

Lembram-se do projeto pydojo[1] ? Parece muito mais interessante, mas
acho que abandonaram o projeto.
É uma coisa bem interessante de ter nos dojos! Talvez fosse legal a
galera pegar e contribuir com o projeto pra não deixar morrer.
Algumas screenshots podem ser vistas em http://www.async.com.br/~romaia/pydojo/

Abraços.

[1] - https://launchpad.net/pydojo

2009/12/17 Israel da Silva Teixeira <isra...@gmail.com>:

[Alex]

Eu estava conversando com o Flávio Amieiro e ele estava pensando em fazer um software que integrasse PyDojo e DojoTimer. Eu mesmo já comecei a fazer uma versão do DojoTimer usando TDD. Podemos juntar essas idéias e desenvolver um projeto que atenda às nossas necessidades do Dojo Rio.

Abraços,
Alex Tercete

2009/12/17 Hugo Lopes Tavares <hlt...@gmail.com>

[Rodrigo Pinto]

2009/12/17 Alex <alext...@gmail.com>

Eu estava conversando com o Flávio Amieiro e ele estava pensando em fazer um software que integrasse PyDojo e DojoTimer. Eu mesmo já comecei a fazer uma versão do DojoTimer usando TDD. Podemos juntar essas idéias e desenvolver um projeto que atenda às nossas necessidades do Dojo Rio.

Acho excelente.. ontem mesmo no dojo, sentimos falta de um VCS para verificarmos como o código evoluiu, que foi muito porém não temos o registro disso, ai Flavio comentou sobre esta idéia.

To dentro;
 

--
Rodrigo Pinto
"Usar software livre é igual a usar uma cirola. Me deixa com a mesma sensação de liberdade."

[Flávio Amieiro]

2009/12/17 Rodrigo Pinto <rodri...@gmail.com>

Acho excelente.. ontem mesmo no dojo, sentimos falta de um VCS para verificarmos como o código evoluiu, que foi muito porém não temos o registro disso, ai Flavio comentou sobre esta idéia.

Então vamos lá.

Como vamos fazer?

Vamos pegar o pydojo e tentar usar ele? Sinceramente eu não gosto muito da idéia.

Acho que a lógica de monitoração é mole de fazer com o stat[1] e resolve nosso problema (tinha pensado em usar o inotify do kernel, mas é exagero total e nos prenderia ao linux).

O timer é outra história, mas é simples pra carabamba de fazer.

Temos que escolher as outras ferramentas.

O ideal, eu acho, seria um tray icon verde se os testes estiverem passando e vermelho caso não passe. GTK? QT? Me disseram por aí que dá pra simplesmente fazer um tray icon que aparece caso exista um tray! Vou ver se dou uma olhada mais tarde na documentação da stalonetray, ver se lá tem algo assim...

Vamos discutir esses detalhes e jogar esse troço no github logo!

Abraços, 

Flávio

[1] http://docs.python.org/library/stat.html

[Rodrigo Pinto]

2009/12/18 Flávio Amieiro <flavio...@gmail.com>

2009/12/17 Rodrigo Pinto <rodri...@gmail.com>

Acho excelente.. ontem mesmo no dojo, sentimos falta de um VCS para verificarmos como o código evoluiu, que foi muito porém não temos o registro disso, ai Flavio comentou sobre esta idéia.

Então vamos lá.

Como vamos fazer?

Vamos pegar o pydojo e tentar usar ele? Sinceramente eu não gosto muito da idéia.

Acho que a lógica de monitoração é mole de fazer com o stat[1] e resolve nosso problema (tinha pensado em usar o inotify do kernel, mas é exagero total e nos prenderia ao linux).

O autotest do ruby é interessante, pois ele test qual é o ambiente e usa p notify de acordo com o "os".
podemos fazer para qualquer máquina. por exemplo, se for win usamos um alert do gtk.
 

O timer é outra história, mas é simples pra carabamba de fazer.

Temos que escolher as outras ferramentas.

O ideal, eu acho, seria um tray icon verde se os testes estiverem passando e vermelho caso não passe. GTK? QT? Me disseram por aí que dá pra simplesmente fazer um tray icon que aparece caso exista um tray! Vou ver se dou uma olhada mais tarde na documentação da stalonetray, ver se lá tem algo assim...

Vamos discutir esses detalhes e jogar esse troço no github logo!

também alguém cria a a gente forka e usa a issue page do projeto ou o gdocs compartilhado para colocar as idéias.

Abraços, 

Flávio

[1] http://docs.python.org/library/stat.html

--

* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

Abraços

[Flávio Amieiro]

2009/12/18 Rodrigo Pinto <rodri...@gmail.com>

2009/12/18 Flávio Amieiro <flavio...@gmail.com>

Vamos discutir esses detalhes e jogar esse troço no github logo!

também alguém cria a a gente forka e usa a issue page do projeto ou o gdocs compartilhado para colocar as idéias.

http://github.com/flavioamieiro/dojotools/

 

Abraços, 

Flávio

[Alex]

Bom nome!

2009/12/18 Flávio Amieiro <flavio...@gmail.com>

--

[Flávio Amieiro]

Galera,

Já que ninguém mais falou nada sobre o assunto, eu resolvi dar o pontapé inicial.

Criei lá uma parada MUITO simples, que monitor o diretório atual, e comita no git. Não tem timer, por enquanto...

Um problema que eu já encontrei é que não consegui achar uma biblioteca para usar o git dentro do Python. A única que eu consegui importar (!) serve pra manipular direto os objetos do git, e não é o que eu queria. As outras, instalando pelo easy_install, não funcionam de jeito nenhum.

O workarround foi usar o subprocess.Popen mesmo, e chamar o git pela linha de comando mesmo. O problema é que eu não sei se funciona no windows (vocês que são masoquistas, testem por favor).

Tá lá no github[1]

Ainda tem muuuita coisa pra fazer, então não fiquem mais quietos, falem. Vamos usar o pydojo pro que ele já faz ou não? Qual vai ser a interface?

Abraços,

Flávio Amieiro

[1] http://github.com/flavioamieiro/dojotools

[Denilson Figueiredo de Sá]

On Sat, 09 Jan 2010 14:13:24 -0200, Flávio Amieiro
<flavio...@gmail.com> wrote:

> Um problema que eu já encontrei é que não consegui achar uma biblioteca
> para usar o git dentro do Python. A única que eu consegui importar (!)
> serve pra manipular direto os objetos do git, e não é o que eu queria.
> As outras, instalando pelo easy_install, não funcionam de jeito nenhum.
>
> O workarround foi usar o subprocess.Popen mesmo, e chamar o git pela
> linha de comando mesmo. O problema é que eu não sei se funciona no
> windows (vocês que são masoquistas, testem por favor).

Possível solução: usar Hg (mercurial) no lugar do Git. ;)

Mercurial é escrito em Python, e roda em qualquer plataforma.

Existe também um "github"-like para mercurial: http://bitbucket.org/

--
Denilson Figueiredo de Sá
Vialink
Rio de Janeiro - Brasil

/"\
\ / ASCII Ribbon Campaign
X against HTML e-mail
/ \

[Flávio Amieiro]

2010/1/9 Denilson Figueiredo de Sá <denil...@gmail.com>

Possível solução: usar Hg (mercurial) no lugar do Git.  ;)

Eu cheguei a pensar nisso, mas tem alguns motivos pra não usar outro scm.

O mais importante é que eu só usei até hoje o git. Por mais que eu não esteja fazendo nada mais complicado do que um commit ali, é natural que eu use ele. 

Além disso, isso era uma das coisas que a gente deveria ter discutido antes (mas tava parada essa thread) e que ainda pode mudar.

Eu devo continuar usando o git pra versionar o código do projeto em si, mas aí por que eu gosto do git, uso ele todo dia etc. Uso ele pra todo o resto.

Eu sei que pode ter uma discussão grande aqui sobre qual scm é melhor, mas isso é completamente desnecessário. Por enquanto é uma coisa muito simples mudar isso. O scm usado no código pode ser até o svn se acharem melhor, ele só faz um commit e acabou!

Abraços, 
Flávio

[Juan Pedro A. Lopes]

Li seu código e não entendo por que você varre os arquivos para pegar o sum dos horários dos arquivos. Porque não usar file monitoring?

Em Mono eu usaria a FileSystemWatcher, que no linux usa "inotify". Acredito que seja melhor que varrer os arquivos. Não duvido que exista algo assim em python (algo como http://pyinotify.sourceforge.net/, mas sem depender da inotify diretamente).

2010/1/9 Flávio Amieiro <flavio...@gmail.com>

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

"E se o mundo não corresponde em todos os aspectos a nossos desejos, é culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl Sagan

[Flávio Amieiro]

2010/1/9 Juan Pedro A. Lopes <zero...@gmail.com>

Li seu código e não entendo por que você varre os arquivos para pegar o sum dos horários dos arquivos. Porque não usar file monitoring?

Por incrível que pareça, minha primeira reação foi usar o inotify. O pydojo usa o gnomevfs (que não serve pra mim, por exemplo). Mas o inotify não serve pra qualquer um que use o windows ou o mac. Eu procurei um pouco por uma solução que fosse independente de plataforma, mas não achei (se alguém souber de uma, avisa, seria ótimo). Alguém no stackoverflow chegou a sugerir usar a Qt[1], mas aí já acho demais (a não ser que a gente acabe usando a Qt pra escrever a interface).

Como a idéia é usar no dojo, performance não vai ser um problema. Nós geralmente temos dois arquivos em um diretório. 

Assim, eu resolvi fazer a coisa mais simples que funcionaria. Concordo que usar alguma coisa pronta seria melhor, mas é pra isso que o código tá no github. Quem conhecer uma solução melhor cria um fork e coloca. Se não quiser fazer isso, pelo menos avisa aqui que eu tento fazer o possível.

Bom que a galera tá dando sugestões. Continuem, por favor. E quem puder, contribua!

Abraços,

Flávio

[1] http://stackoverflow.com/questions/155490/os-independent-api-to-monitor-file-system

[Ingo Hoffmann]

O code.google.com também suporte Mercurial :)

[Henrique Bastos]

Boa Flávio!

1) Concordo com a estratégia de varredura. Me parece a solução mais
simples que funciona em múltiplas plataformas.

2) Pelo que entendi, a questão de comitar o código é para manter os
passos que descrevem a evolução do código. Isso é independente de SCM,
logo poderíamos evoluir conforme a necessidade isolando esta questão
para suportar subversion, mercurial e git. (acredito que são os
principais)

3) Por outro lado, comitar a cada SAVE pode ser exagerado. Talvez
devesse comitar a cada vez q o teste é rodado E há uma modificação no
arquivo.

[]'s,
--
Henrique Bastos
henr...@bastos.net
http://henriquebastos.net
+55 21 9618-6180

[Flávio Amieiro]

2010/1/9 Henrique Bastos <henr...@bastos.net>

1) Concordo com a estratégia de varredura. Me parece a solução mais simples que funciona em múltiplas plataformas.

Na verdade, se você olhar no commit vai ver que foi baseado no seu script de autotest, com poucas mudanças...

 

2) Pelo que entendi, a questão de comitar o código é para manter os passos que descrevem a evolução do código. Isso é independente de SCM, logo poderíamos evoluir conforme a necessidade isolando esta questão para suportar subversion, mercurial e git. (acredito que são os principais)

É o que eu quis dizer. Podemos até usar o svn, não faz a menor diferença.

 

3) Por outro lado, comitar a cada SAVE pode ser exagerado. Talvez devesse comitar a cada vez q o teste é rodado E há uma modificação no arquivo.

Concordo, mas é que essa foi a primeira versão, mais simples possível, e que não tem o código que roda os testes ainda.

O problema é que teoricamente, os testes deveriam rodar automaticamente quando salva, então simplesmente rodar os testes E ter alterações talvez não seja o suficiente. Talvez a abordagem seja fazer o commit toda vez que os testes mudarem de estado (de verde pra vermelho), mas não sei se essa granularidade é suficiente.

Isso é uma coisa a se pensar melhor, sem dúvida.

Abraços,

Flávio

[Henrique Bastos]

On 10/01/2010, at 05:14, Flávio Amieiro wrote:

> 3) Por outro lado, comitar a cada SAVE pode ser exagerado. Talvez
> devesse comitar a cada vez q o teste é rodado E há uma modificação
> no arquivo.
>
> Concordo, mas é que essa foi a primeira versão, mais simples
> possível, e que não tem o código que roda os testes ainda.
>
> O problema é que teoricamente, os testes deveriam rodar
> automaticamente quando salva, então simplesmente rodar os testes E
> ter alterações talvez não seja o suficiente. Talvez a abordagem seja
> fazer o commit toda vez que os testes mudarem de estado (de verde
> pra vermelho), mas não sei se essa granularidade é suficiente.

Ah, blz! Concordo! Acho que faz sentido manter a sua linha atual e
incluir a execução automática dos testes no save. Para o Dojo isso faz
muito sentido e vai economizar muito tempo durante a pilotagem.

[Rodrigo Pinto]

Flavio,

forkei o projeto e estava començando a escrever uns teste, para algo que eu não havia gostado que é o fato de quando não existir .git ele cai no process.wait() == 128 e para por ai.

Então pensei lógicamente se não existe, chama o "git init" ai deu PAM ..o comando entra em loop e fica fazendo reinitalizing  no repositório. Você passou por isso ?

Outro problema é chamar o subprocess no unittest, da erro por causa do cwd... ai malandro eu pensei tira o cwd e da um "cd pasta; git init;" antes do git init.. e PAM de novo e eu não sou tão malandro rs.. da o mesmo erro do cwd.. É como se não houvesse permissão para caminhar para um diretório de dentro de um unittest.


e ai alguém tem alguma sugestão?

Abraços;

2010/1/10 Henrique Bastos <henr...@bastos.net>

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
Rodrigo Pinto

[Henrique Bastos]

On 10/01/2010, at 12:58, Rodrigo Pinto wrote:

> Flavio,
>
> forkei o projeto e estava començando a escrever uns teste, para algo
> que eu não havia gostado que é o fato de quando não existir .git ele
> cai no process.wait() == 128 e para por ai.
>
> Então pensei lógicamente se não existe, chama o "git init" ai deu
> PAM ..o comando entra em loop e fica fazendo reinitalizing no
> repositório. Você passou por isso ?

Rodrigo, acho que neste caso vc misturaria 2 propósitos distintos em
uma mesma funcionalidade.

Pelo que o Flávio comentou, o propósito do projeto é agilizar a rotina
de pilotagem do Dojo commitando o código nos saves. Portanto, se o
diretório do projeto não é um repositório GIT, acredito que, faz mais
sentido falhar a inicialização do script que verificaria (antes do
loop) se está sendo executado a partir de repositório válido. Afinal o
propósito de registrar os commits seria violado neste caso. Desta
forma, o loop fica enxuto, sendo executado somente se pré-requisitos
forem atendidos.

> Outro problema é chamar o subprocess no unittest, da erro por causa
> do cwd... ai malandro eu pensei tira o cwd e da um "cd pasta; git
> init;" antes do git init.. e PAM de novo e eu não sou tão malandro
> rs.. da o mesmo erro do cwd.. É como se não houvesse permissão para
> caminhar para um diretório de dentro de um unittest.

Com a solução econômica sugerida anteriormente, o git init seria de
responsabilidade do piloto. Como um setup do dojo.

Mas se vc quiser implementar esse bootstrap, manda os detalhes do erro
que você obteve (copia e cola o terminal). Não to conseguindo
visualizar o problema.

[Flávio Amieiro]

Com a solução econômica sugerida anteriormente, o git init seria de responsabilidade do piloto. Como um setup do dojo.

A idéia é mais ou menos essa aí. Mas isso pode ser uma opção na linha de comando. --create cria um repositório se não houver um...

 

Mas se vc quiser implementar esse bootstrap, manda os detalhes do erro que você obteve (copia e cola o terminal). Não to conseguindo visualizar o problema.

Eu não entendi o erro direito. O problema que eu tive que caia em loop é quando ele levava em consideração as mudanças no diretório .git. Já que cada commit altera esse diretório, ele commitava, aí commitava de novo etc. Tenta descrever melhor, mandar o output, qualquer coisa assim.

Além disso, não sei se pra rodar o unittest precisa rodar no shell. Dá uma olhada na documentação do unittest [1]. É só instanciar um TextTestRunner, que nem em [2]. A gente pode até criar uma classe nossa baseada nessa aí pra fazer o output ficar do nosso jeito. Usar o subprocess pro commit foi só um workaround mesmo por que não achei uma biblioteca boa pra rodar isso de dentro do python.

Abraços,

Flávio

[1] http://docs.python.org/library/unittest.html

[2] http://docs.python.org/library/unittest.html#basic-example

[Hugo Lopes Tavares]

Eu clonei o repositório e estava lendo o código agora.
Vocês estão questionando qual (D)VCS usar e tal, mas eu tenho um questionamento:
Quantas vezes vocês realmente usaram versionamento num dojo? Eu nunca
participei de um em qual foi necessário backups ou versões antigas do
código em questão.

Será que isso é realmente necessário? Eu entendo que seria legal pra
ver a evolução do problema. Mas, fora isso, teria sentido?

Talvez eu aproveite os dias que ainda me restam das férias pra
acompanhar o projeto e quem sabe conseguir ajudar de alguma forma.

Abraços.

[Flávio Amieiro]

2010/1/10 Hugo Lopes Tavares <hlt...@gmail.com>

Será que isso é realmente necessário? Eu entendo que seria legal pra
ver a evolução do problema. Mas, fora isso, teria sentido?

A questão é exatamente essa: ter um histórico da evolução.

Além disso, a idéia é ter um conjunto de ferramentas para usar no dojo (timer, autotest etc), o versionamento é só uma espécie de log.

Abraços, 

Flávio

[Claudio Berrondo]

Ô Hugo,

que em me lembre, a ideia por trás da parada é poder reproduzir uma seção de dojo. seria como filmar o dojo: poder andar pra frente e pra trás e acompanhar a maneira como o problema foi enfrentado, diferentemente de deixar apenas um registro de onde o código parou e só...

não era isso?

><>

2010/1/10 Hugo Lopes Tavares <hlt...@gmail.com>

Eu clonei o repositório e estava lendo o código agora.

[Rodrigo Pinto]

Pessoal,

em relação ao problema, tentarei explicar depois com mais calma, mas acho a argumentação do Henrique válida, e sendo assim se levada em consideração o meu refactory seria desnecessário.


Abraços.

2010/1/10 Claudio Berrondo <claudio....@gmail.com>

Ô Hugo,

que em me lembre, a ideia por trás da parada é poder reproduzir uma seção de dojo. seria como filmar o dojo: poder andar pra frente e pra trás e acompanhar a maneira como o problema foi enfrentado, diferentemente de deixar apenas um registro de onde o código parou e só...

não era isso?

Exatamente Berrondo.. a idéia é como ser um "filme" do acontecido, pois, ter somente o código final não deixa explicito o que se passou durate o dojo, muito menos a evolução do código, como aconteceu no dojo em que o problema era o redimensionamento da imagem, era um simples metodo de um módulo que adotou algumas regras de solid e O.O. e deixou o código maravilhoso em relação ao inicial.



 

><>

2010/1/10 Hugo Lopes Tavares <hlt...@gmail.com>

Eu clonei o repositório e estava lendo o código agora.

Vocês estão questionando qual (D)VCS usar e tal, mas eu tenho um questionamento:
Quantas vezes vocês realmente usaram versionamento num dojo? Eu nunca
participei de um em qual foi necessário backups ou versões antigas do
código em questão.

Será que isso é realmente necessário? Eu entendo que seria legal pra
ver a evolução do problema. Mas, fora isso, teria sentido?

Talvez eu aproveite os dias que ainda me restam das férias pra
acompanhar o projeto e quem sabe conseguir ajudar de alguma forma.

Abraços.

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
Rodrigo Pinto

[Vinicius Manhaes Teles]

Confesso que estava me sentindo pouco à vontade para levantar essa
questão, considerando-se o esforço que já foi colocado no projeto.
Entretanto, me vi fazendo exatamente o mesmo questionamento.

Tenho a impressão que versionamento no Dojo parece interessante, mas
tenho minhas dúvidas se seria usado de fato.

Grande abraço,

Vinícius Teles

Em 10/01/2010, às 17:20, Hugo Lopes Tavares <hlt...@gmail.com>
escreveu:

[Flávio Amieiro]

2010/1/10 Vinicius Manhaes Teles <vinicius...@gmail.com>

Confesso que estava me sentindo pouco à vontade para levantar essa questão, considerando-se o esforço que já foi colocado no projeto. Entretanto, me vi fazendo exatamente o mesmo questionamento.

Não questionar essas coisas é muito pior! Imagina se a gente gasta muito tempo fazendo um negócio que não serve pra nada? Por enquanto eu só gastei uma manhã...
 

Tenho a impressão que versionamento no Dojo parece interessante, mas tenho minhas dúvidas se seria usado de fato.

A questão não é usar o versionamento como usaríamos em um projeto, mas sim guardar o histórico do código durante um dojo, um log para podermos voltar caso seja interessante - como no caso citado pelo Rodrigo, em que a evolução do código foi muito interessante e surgiu essa idéia.

De qualquer forma, a idéia é fazer um conjunto de ferramentas. O versionamento é só uma das coisas que a gente tinha pensado, mas pensamos também em incorporar pelo menos mais duas funcionalidades: autotest e o timer. Comecei pelo versionamento por que ainda acho que a gente tem que discutir se vamos modificar o pydojo[1] ou escrever de outro jeito (o maior problema com o pydojo é a dependência com o gnomevfs). Tirar, ou tornar opcional, a funcionalidade de versionamento é simples!


Abraços,
Flávio


[1] https://launchpad.net/pydojo

[Rodolfo Carvalho]

Se me permitem, também tenho minhas dúvidas quanto a utilidade do controle de versão....

Até quando participei toda semana dos dojos, nunca houve o caso de uso de querer olhar o código. Não sei se nos ultimos meses isso mudou.
E pra mim que to de fora, teria pouca utilidade ver um monte de commits [automaticos] sem ter participado da sessão.

O grande barato do Dojo é a interação que rola entre as pessoas... sempre quis levar isso para a web, mas não encontrei jeito :P [ainda].

Entretanto, como até agora não contribuí com nenhuma manhã, não quero dar asas a um bate papo sem fim.


Se é para sermos pragmáticos, seria mais interessante levantar na próxima semana no Dojo qual é a funcionalidade que traz mais valor de negócio pro Dojo, e qual pode ser usada já na próxima semana.
Assim tem-se 1 semana para dar o pontapé inicial, e tem também usuários ávidos pra por o software em ação. Na semana seguinte, discute-se o que foi bom e o que não foi, e passa a próxima iteração. Até que uma nova funcionalidade seja implementada... e todos estejam felizes com o projeto e ... final feliz :D


Já são 2:42 em Lisboa... será que consigo terminar meus exercícios de Polonês? Ah, sábado comecei efetivamente meu curso de Turco!!!
Quando eu voltar vamos ter Dojo numas linguagens novas...


Dobranoc
Iyi günler

[]'s

Rodolfo Carvalho

[Henrique Bastos]

On 11/01/2010, at 00:50, Rodolfo Carvalho wrote:

> Se me permitem, também tenho minhas dúvidas quanto a utilidade do
> controle de versão....
>
> Até quando participei toda semana dos dojos, nunca houve o caso de
> uso de querer olhar o código. Não sei se nos ultimos meses isso mudou.
> E pra mim que to de fora, teria pouca utilidade ver um monte de
> commits [automaticos] sem ter participado da sessão.

Não acho que o grupo se beneficie dos commits. Acredito que servirá
apenas para eventuais consultas de visitantes que querem conhecer
melhor o dojo. Mas tb não sei se isso de fato acontecerá.

> Se é para sermos pragmáticos, seria mais interessante levantar na
> próxima semana no Dojo qual é a funcionalidade que traz mais valor
> de negócio pro Dojo, e qual pode ser usada já na próxima semana.
> Assim tem-se 1 semana para dar o pontapé inicial, e tem também
> usuários ávidos pra por o software em ação. Na semana seguinte,
> discute-se o que foi bom e o que não foi, e passa a próxima
> iteração. Até que uma nova funcionalidade seja implementada... e
> todos estejam felizes com o projeto e ... final feliz :D

Sem dúvidas o que precisa acontecer é *autotest*. Programar sem sair
do editor é fundamental para fazer a pilotagem fluir.

> Já são 2:42 em Lisboa... será que consigo terminar meus exercícios
> de Polonês? Ah, sábado comecei efetivamente meu curso de Turco!!!
> Quando eu voltar vamos ter Dojo numas linguagens novas...

To ligado na _língua_ que vc tá aprendendo! :-P

[Denilson Figueiredo de Sá]

On Mon, 11 Jan 2010 08:23:29 -0200, Henrique Bastos wrote:
> On 11/01/2010, at 00:50, Rodolfo Carvalho wrote:
>
>> Até quando participei toda semana dos dojos, nunca houve o caso de
>> uso de querer olhar o código. Não sei se nos ultimos meses isso mudou.
>> E pra mim que to de fora, teria pouca utilidade ver um monte de
>> commits [automaticos] sem ter participado da sessão.
>
> Não acho que o grupo se beneficie dos commits. Acredito que servirá
> apenas para eventuais consultas de visitantes que querem conhecer
> melhor o dojo. Mas tb não sei se isso de fato acontecerá.

Eu acho interessante manter o histórico do código do dojo, será útil para
ver a evolução do código (como já mencionaram), especialmente nas
refatorações. Provavelmente será mais útil para aqueles que não
participaram do dojo, mas acredito ser útil para todos.

Por outro lado, não tenho certeza se commits automáticos são a melhor
solução. Talvez um commit (semi-manual?) a cada vez que troca o piloto?
Neste caso, a msg do commit poderia conter os nomes do piloto e do
co-piloto.

Não sei como é no git, mas no mercurial há algumas interfaces gráficas que
tornam bem "fácil" a navegação pelo histórico. Exemplos: "hg view",
"hgview"

[Flávio Amieiro]

Fala pessoal,

Eu fiz algumas pequenas modificações no script. Agora comitar o código e opcional, e fica desabilitado por padrão. Além disso, qualquer argumento posicional que for passado na linha de comando vai ser passado para um shell cada vez que houver uma alteração em um dos arquivos, então

$ dojotools.py "python test.py"

vai rodar os testes a cada alteração. Do mesmo jeito,

$ dojotools.py "clear" "python test.py"

vai limpar a tela, e depois rodar os testes.

Se alguém quiser usar, tá lá no github[1]

----

Eu quero começar a pensar em como vai ser o timer, e como ele vai se apresentar. Vai ser um ícone na barra de tarefas? Vai usar o GTK? QT?

Mandem idéias, por favor.

Abraços, 

Flávio

[1] http://github.com/flavioamieiro/dojotools

[Rodolfo Carvalho]

- O Timer -

Se a partirmos do pressuposto que a máquina tem speaker (nao necessariamente placa de som, mas só aquele "pi-pi"), então é possível ter uma solução semi-multiplataforma.

Ao invés de usar notificação visual, seria apenas um sonzinho engraçado -- como um alarme.

Vou contribuir com algum código que já escrevi um dia para brincar com som em Linux/Windows. Só nunca testei no Mac :D

[]'s

Rodolfo Carvalho

2010/1/17 Flávio Amieiro <flavio...@gmail.com>

[Álvaro Justen [Turicas]]

Li toda a discussão mas acabei não falando nada...
Sobre os commits, eu comentei essa ideia que tive no DevInRio e a
galera gostou. Eu acho legal termos o histórico de como a coisa
evolui, seja pra pessoas que não foram ao dojo entenderem qual caminho
seguimos, para 'voltarmos no tempo' em caso de troca de estratégia ou
apenas para fins "educacionais" (são ótimos exemplos para se mostrar o
que acontece em um dojo, falar de baby steps em palestras etc.).
Sinceramente, não acredito que essa funcionalidade será largamente
utilizada, porém como é só fazer um commit (funcionalidade
razoavelmente simples e rápida de se codificar), acredito que possamos
implementar sem problemas.

Acho que as funcionalidades mais importantes são:
1- Timer (já temos o dojotimer, eu só acrescentaria opções por linha
de comando e tempo padrão de 5min);
2- auto test: acho a mais importante pois contribuiria com o
desempenho dos pilotos; ao ser efetuada alguma alteração em arquivo
(teste ou código), roda os testes e mostra visualmente o resltado
(parecido com aquele pra Ruby que vimos no DevInRio).

Sinceramente acho que estamos indo longe demais com a discussão sobre
portabilidade. Atualmente utilizamos Gnome (Niterói) e Windows (Lapa),
então acho que devemos começar suportanto apenas essas plataformas.

Pra mostrar se os testes passaram ou não poderíamos utilizar o
notify-send (como no pomamonitor[1]).

[1] http://code.google.com/p/pomamonitor/

2010/1/17 Flávio Amieiro <flavio...@gmail.com>:

> --
> * Coding Dojo Rio *
> dojo...@googlegroups.com
> http://groups.google.com/group/dojo-rio
> http://code.google.com/p/dojo-rio
> http://dojorio.wordpress.com
>

--
Álvaro Justen
Peta5 - Nós fazemos TV digital
http://www.peta5.com.br/
21. 3021-6001 / 9898-0141

[Rodolfo Carvalho]

Tai galera,

Finalmente uma tarde de domingo me divertindo, programando e tocando uns sons bizarros :P

http://github.com/rhcarvalho/sound_alarm


O sound_alarm.py pode ser usado assim:

./sound_alarm.py -p SuperNintendo

E vai tocar uma musiquinha estilo SuperNintendo...


Também podem verificar todo o resto rodando ./sound_alarm.py --test



Se gostarem eu integro com o dojotools :D

[]'s

Rodolfo Carvalho

2010/1/17 Rodolfo Carvalho <rhcar...@gmail.com>

[Flávio Amieiro]

2010/1/17 Álvaro Justen [Turicas] <alvaro...@gmail.com>

2- auto test: acho a mais importante pois contribuiria com o
desempenho dos pilotos; ao ser efetuada alguma alteração em arquivo
(teste ou código), roda os testes e mostra visualmente o resltado
(parecido com aquele pra Ruby que vimos no DevInRio).

Eu fiz um branch que já mostra a saída do comando através de uma notificação[1].

 

Sinceramente acho que estamos indo longe demais com a discussão sobre
portabilidade. Atualmente utilizamos Gnome (Niterói) e Windows (Lapa),
então acho que devemos começar suportanto apenas essas plataformas.

Pra mostrar se os testes passaram ou não poderíamos utilizar o
notify-send (como no pomamonitor[1]).

Eu usei o pynotify, que é muito simples, mas infelizmente não tem documentação em lugar nenhum. Pelo que sei isso é específico do linux (do X11, se não me engano), mas não achei a documentação pra provar.

Ainda não fiz o merge com o master por que eu tô sem tempo, e quero dar um jeito de pelo menos não tornar impossível de rodar no windows. Tem que tentar importar, se não conseguir dar um aviso e continuar sem a notificação.

--

Rodolfo, ficou irado o programinha pra tocar o som.

Eu não testei no Mac OS, mas no linux rolou tranquilo. Como eu falei, hoje eu tô sem tempo, mas se você quiser (e puder), coloca lá no dojotools. Dá uma olhada no branch da notificação, acho que a boa é colocar lá na função que roda o comando mesmo.

Aliás, assim que eu conseguir um tempinho tenho que rever essa estrutura. O código tá começando a ficar zoneado..

Abraços, 

Flávio

[1] http://github.com/flavioamieiro/dojotools/commits/feature/notification

[Denilson Figueiredo de Sá]

2010/1/17 Rodolfo Carvalho <rhcar...@gmail.com>:

>
> Se a partirmos do pressuposto que a máquina tem speaker (nao necessariamente
> placa de som, mas só aquele "pi-pi"), então é possível ter uma solução
> semi-multiplataforma.

Esta suposição não serve: meu note não tem speaker.

Porém, considerando que qualquer computador possui placa de som, então
o speaker interno torna-se realmente desnecessário (exceto na bios...
mas isso é outra história).