Shared publicly  - 
 
"And then — anyone who’s ever actually released software will recognise this — then in a sense the actual work begins. For the program to stop being a private project and become a public product, it needs documentation — APIs, command-line manuals, tutorials. It needs unit tests. It needs a home on the web. It needs checking for portability. It needs changelogs and a release history. It needs tweaking, and quite possibly internal reorganisation to make it play nicer with other programs out there."

É, essa é a parte chata. É a que leva mais tempo, é a que desanima, é a que faz você nunca lançar publicamente aquele programinha bacana que funciona na tua máquina.
8
Alfredo Kojima's profile photoDenilson Sá's profile photoThiago Galesi's profile photoAurelio Jargas's profile photo
12 comments
Translate
Translate
 
Como o GitHub resolve esta lista de pendências pré-release?
Translate
 
Github parece diminuir essa frustação que é a que faz você nunca lançar publicamente aquele programinha bacana que funciona na tua máquina porque no pior dos casos, se passou o fim de semana brincando em algo e tá sentindo isso aí você pode ir lá e fazer um dump mental sem muitas obrigações de release e/ou maintainer. Se um dia quiser promover o resultado do tal fim de semana lá também tem as ferramentas pra tudo isso. Conheço muita gente que não bota coisas online porque ainda não tá bom suficiente pra release ou virar projeto e que caem nessa situação.
Translate
 
Na minha visão, se eu colocar um projeto cru no GitHub, isso vai me dar paz de espírito e vou considerar "tá, liberei" e aí sim com certeza eu nunca mais vou mexer naquele treco.

Sim, há a possibilidade de outra pessoa querer tocar o projeto, mas como joguei ele lá, cru, sem documentação, sem faxina, sem nada, acho muito difícil captar qualquer interesse.

Não considero o GitHub uma solução pra esse problema. A solução é alguém fazer as tarefas, e sendo o projeto ainda um feto, só o próprio criador mesmo pra ter motivação pra encarar essa chatice :)
Translate
 
O Github não resolve mas pelo menos ameniza o problema: pelo menos agora as coisas ficam esquecidas em um canto público do Github e não num canto do seu HD. Mas realmente deixar algo "pronto pra usar" dá muito trabalho.

O autor do blogpost parece ter a ilusão de que no passado não era assim; mas isso é um problema desde os anos 70: http://smartcomputing123.files.wordpress.com/2011/08/brooks-tmmm-01-thetarpit.pdf

"Moving down across the horizontal boundary, a program becomes a programming product. This is a program that can be run, tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. To become a generally usable programming product, a program must be written in a generalized fashion. In particular the range and form of inputs must be generalized as much as the basic algorithm will reasonably allow. Then the program must be thoroughly tested, so that it can be depended upon. This means that a substantial bank of test cases, exploring the input range and probing its boundaries, must be prepared, run, and recorded. Finally, promotion of a program to a programming product requires its thorough documentation, so that anyone may use it, fix it, and extend it. As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function."

O que ele chama de "program" é o que chamamos de "aquele programinha bacana que funciona na sua máquina". Tornar ele usável pelo resto do mundo (transformar no que é chamado de "programming product") levava 3x mais tempo, segundo o Fred Brooks—e IMO essa rule of thumb é válida até hoje.
 
Pode crer, na minha experiência, sempre foi 3x ou mais. E sempre foi um saco. A parte divertida dura pouco, depois vem o trabalho burocrático e sacal :(

Estou exatamente nesta experiência agora com o MoneyLog versão 5, que está "pronto" no SVN, aguardando a polida final e o lançamento. Mas claro, só depois que eu reescrever todo o site dele, fazer o Changelog, atualizar o FAQ, preparar screenshots, talvez um vídeo, blablablabla que saco já fiquei desanimado só de escrever esse parágrafo...

Mas voltando ao GitHub, creio que na prática não há diferença alguma entre um código prematuro abandonado no meu HD ou na internet. Não há utilidade prática, para ninguém. Ninguém vai conseguir usar porque não há instruções. Ninguém vai aprender nada pois o código é apenas um rascunho cheio de rabiscos. Não despertará interesse, não ganhará tração, não terá utilidade alguma.

Só se o código 0.0.0.0.0.0.1 de vocês é legível, mas o meu, sem chance :)
Translate
 
Teoricamente tornar um programinha usável fora da sua máquina é uma tarefa mais ou menos one-time. Mas aí no Linux, tem o problema de que versões novas de tudo saem todo mês (ou no mínimo 2x por ano) sem nenhuma preocupação com compatibilidade retroativa. É o gcc estragando a compilação, função de biblioteca sendo deprecada, ferramenta sendo arrancada da distro, linguagem que muda o tempo todo etc etc. Aí, dependendo do tipo de programa, ou o teu esforço acaba tendo um tempo de validade bem curto ou tu é obrigado a ficar mantendo o negócio pra no mínimo continuar funcionando como estava no começo.
Translate
 
Sobre o moneylog: pelo menos a documentação é importante. Pense no seguinte: que tipo de coisa você gostaria de ler caso você encontrasse esse projeto?

Como essa parte costuma ser chata, normalmente eu evito de deixá-la para o final. Algumas vezes, escrevo o comentário de uma função ou o --help de um script antes mesmo de começar a escrever o código.

Quando eu penso no quão ruim é pegar um código sem documentação, é motivação suficiente para eu fazer direito. :)

Aliás, tentar não ficar lembrando muita coisa do código também é bom. "Esquecer" o que o código faz é uma boa forma de se forçar a ler os comentários, e portanto a escrever bons comentários.
Translate
 
+Alfredo Kojima verdade, eu já tinha esquecido como no Linux esse problema é multiplicado a níveis insanos.

+Denilson Sá no caso do MoneyLog, o código está bem comentado, pois ele já é um programa estável, o problema é mesmo a documentação para o usuário. Como o programa mudou muito nesta versão, vou ter que refazer muita coisa: site, FAQ. O Changelog já tentei dos dois jeitos: fazer uma "retrospectiva" agora no final ou ir salvando num TXT os logs mais importantes durante o desenvolvimento. De um jeito ou de outro, é um saco.
Translate
 
+Eduardo Habkost bem lembrado do MMM tem até um gráfico sobre isso no livro, fazer uma coisa 'na sua máquina' é uma ordem de magnitude mais simples do que fazer 'para todos'

Ou você pega o seu programinha, coloca um alto preço nele e ainda vende suporte a preços de 'empresas famosas' coff*coff
Translate
Translate
Add a comment...