Dorneles Treméa wrote:
> [ Aviso: mensagem longa a seguir, mas de leitura recomendada... :-) ]
>
> Opa Cleber,
>
>   
>>> no caso dos produtos CMFPhoto{,Album}, eles foram descontinuados
>>> por uma razão bem simples: a funcionalidade deles foi incorporada
>>> ao ATFolder e ATImage do ATContentTypes.
>>>       
>> É que neste caso o problema seria outro, um exemplo, como é que a galera
>> que já usava o CMFPhoto(, Album) ficariam? Ou seja, para migrar diversos
>> albúns seriam algo mais doloroso, claro que não tão doloroso quanto
>> migrar um Plone heheheh, mas doi!
>>     
>
> nem tão doloroso assim, pois basta instalar o produto:
>
> http://plone.org/products/cmfphoto-album-to-folders-and-images
>
> ...para migrar todos os conteúdos para os novos content-types... ;-)
>
>   
Hehehe, dessa eu não sabia,e olha que googlei mas não achei nada :D
>>> E o pessoal em praticamente todas as vezes indicou como fazer no
>>> Plone para ativar isso... :-)
>>>       
>> Mas será que indicar é o bastante? Já que estamos falando de algo que é
>> usado por todos?
>>     
>
> Eu não assumiria que estamos falando de algo que é usado por todos.
> Obviamente ele é usado por alguns, mas é bem complicado mensurar um
> percentual nisso...
>
>   
Éh, tenho que concordar :)
>>> Entretanto, eu gostaria de ressaltar que eu particularmente acredito
>>> que teria sido melhor incorporar ao Plone o que ele ainda não tem,
>>> em comparação aos produtos citados. Se não me falha a memória, um
>>> dos templates era um pouco mais elaborado, ou coisa assim...
>>>       
>> Hehehe, pois é, é ai que eu queria chegar, temos necessidades como essa
>> que você citou, mas nós como comunidade não a fazemos, parece que
>> ficamos esperando alguém fazer algo saca?...
>>     
>
> Concordo contigo. Esse pensamento pode vir a partir dessas origens:
>
> a) o cara pensa: não vou fazer, porque eu acho que alguém logo vai
> fazer isso por mim;
>
> b) o cara pensa: não vou fazer, porque eu acho que eu ainda não tenho
> experiência suficiente para fazer isso;
>
> É esse tipo de coisa que temos que tentar minimizar...
>
> Para resolver o item (b), temos que continuar fazendo o que vêm
> sendo feito a anos tanto nessa lista de discussão, quanto no canal
> de IRC: ajudar o pessoal a resolver os seus problemas e incentivá-los
> a resolver as coisas da forma correta.
>
> A forma correta pode ser abrindo um bug report, fazendo um comentário
> com uma proposta de solução num bug já existente, ou mesmo fazendo um
> commit nos repositórios, caso você tenha acesso.
>
> Em relação ao item (a), não tem muito o que podemos fazer, afinal o
> brasileiro tem uma péssima mania de achar que o problema não é com
> ele e na maior parte das vezes apenas se finge de morto... :-)
>
>   
Pois é, isso é muito complicado, pois ao mesmo tempo que queremos ajudar 
fica um pouco de revolta... Realmente não dá para entender a galera que 
se diz atuar com SL ou OpenSource, acho que muitos ainda não entenderam 
que a idéia de SL não é apenas o compartilhamento do conhecimento, mas 
que também temos que saber contribuir para que o conhecimento seja 
expandido.

>>>> Acho que temos que voluntariamente buscar manter projetos
>>>> atualizados, sei que é difícil, mas 30 minutinhos de cada
>>>> um de nós seria o bastante ;)
>>>>         
>>> Meia hora de cada um é muito mais do que suficiente, a questão é
>>> que a maior parte do pessoal quer apenas resolver os seus problemas
>>> mais imediatos e da forma mais rápida possível.
>>>       
>> Sem querer ser chato, mas o que você acha disso? Ou seja, o que você
>> acha de uma comunidade querer apenas resolver seus problemas e não
>> pensar em resolver um problema que pode ser o seu problema amanhã?
>>     
>
> Eu acho isso errado, claro...
>
> Confere o meu raciocínio: você tem um problema hoje. Se você corrigir
> ele apenas localmente, você resolve o seu problema. A questão é que
> esse mesmo problema pode se repetir mais tarde em um outro servidor,
> ou em um outro cliente, de forma que você vai ter que fazer a mesma
> coisa lá, novamente, para resolver aquilo que você já havia resolvido.
>
> Se, desde o princípio, a solução já tivesse sido aplicada na origem
> (e não apenas localmente), muito provavelmente você não precisaria
> desperdiçar o seu tempo fazendo a mesma coisa mais uma vez...
>
>   
Realmente, você disse tudo, concordo com seu raciocínio, inclusive 
existem pessoas que por achar que tudo roda em volta de uma linguagem 
(Inglês), não tem como passar o conhecimento para frente, este é o tipo 
de raciocínio que também temos que mudar.

Recentemente lancei junto com uma amigo que trabalha comigo (Thiago) um 
Produto Chamado PloneSlideShow, que na verdade foi usado em um projeto 
específico para um site de notícias (http://www.brasildefato.com.br), 
como começou a haver demandas para outros clientes, acabava-mos caindo 
no problema que você citou em seu raciocínio, simplesmente tinha-mos que 
replicar exatamente os mesmos passos para o outro site, até que veio a 
idéia de fazer o produto, pois além de poder usar com facilidade para 
qualquer cliente, ainda poderia-mos dar uma solução para ser usado em 
qualquer outro site de qualquer pessoa.

Mesmo com um inglês péssimo iniciamos o desenvolvimento, depois tive 
ajuda de uma amiga que deu uma garibada no inglês :D e pronto...!

>>> São poucos os que, quando estão atacando o problema, pensam na
>>> solução considerando o que seria melhor a médio e longo prazo, além
>>> de levar em consideração como beneficiar a comunidade...
>>>
>>> Mas é isso mesmo, ninguém é obrigado a contribuir nada, por outro
>>> lado, é de bom tom dar um pouco de si, principalmente quando a
>>> comunidade já lhe deu tanto de si... ;-)
>>>       
>> Concordo e assino em baixo :D, eu realmente gostaria de chamar a atenção
>> da comunidade, pois percebo que diferente de muitas comunidades, um
>> exemplo, a comunidade PHP, nós não desenvolvemos em conjunto (Muitas
>> vezes)
>>     
>
> Seria ótimo se cada um que ler essa lista, desse uma passada nos
> bugs abertos no Plone/Collective/[Seu projeto preferido] para ver
> se tem algo que ele possa fazer... mas sendo realista eu acho isso
> meio utópico... :-(
>
> Sabe por quê? Simplesmente porque muitos de nós vieram do mundo
> proprietário onde você paga pela licença de uso de um software (ou,
> sendo bem realista, pirateia ele...) e depois disso você o utiliza
> para resolver os seus problemas, sem se importar (ou sem ter como)
> com o futuro dele.
>   
Concordo contigo, isso é um empecilho que infelizmente muitos ainda tem, 
e que na verdade muitos apenas migram para SL por conta do valor...! 
Pagar menos para ter suporte gratuito de uma comunidade e não precisar 
se preocupar com licenças, isso deve ser o raciocínio de muitos.
> No mundo do software livre, as coisas são bem diferentes. Primeiro
> você não precisa comprar a licença de uso, ele é livre. Segundo,
> caso algo não funcione da forma esperada, você tem a possibilidade
> de corrigir o que está errado. Isso muitos de nós faz, mas esquece
> que temos ainda um terceiro passo, que seria fazer com que essa
> correção já viesse aplicada nas versões futuras...
>
> O pessoal pára no segundo passo, mas precisa estar ciente que o
> terceiro é fundamental... :-(
>
>   
Exatamente, mas a questão é: "Como fazer para que as pessoas não parem 
no segundo passo?", é meio complicado já que estamos falando de uma 
maioria que prefere copiar e colar,e que os poucos que querem ajudar a 
arrumar não são o bastante, então nem sempre dá para fazer a diferença.
>> se formos colocar na mesa só para ter idéia, não temos uma
>> alternativa ao *phpPgMyAdmin* que é código aberto, claro que para meu
>> uso isso não seria necessário já que tenho o ZSQL Methods que me atende
>> bem, mas e o resto do pessoal?
>>     
>
> Você tocou num ponto interessante aqui, que eu gostaria de comentar.
>
> Só porque usamos Zope/Plone/Python isso não significa que nós devemos
> competir com PHP/Ruby/Perl/[...] para ter uma alternativa para cada
> uma das soluções existentes!
>
> Nada impede que surja algo melhor que o php{,Pg}MyAdmin em PZP, mas
> nada nos obriga a faze isso, entende?
>
>   
Sim, entendo e concordo até, mas o que ocorre é que se você vai 
trabalhar com PZP e decide implementar em seu servidor php por exemplo, 
isso vai significar ter mais falhas de segurança no servidor, claro que 
isso não é o fim do mundo, mas se tivesse-mos uma solução voltada para 
PZP, nossa isso seria maravilhoso, não necessitaria ter que usar mais de 
uma aplicação no servidor apenas para rodar um cliente pgAdmin saca ;)

Acho que quanto mais alternativas nós tivermos para PZP melhor para 
manter nosso pão de cada dia heheheheh :D
>> Procure no google por exemplo, sistemas de boleto em Php... Inclusive
>> rolou na lista recentemente algo sobre sistema de boleto, e qual foi a
>> solução dada? Algo que não tem um código fonte, nada contra, mas não
>> temos alternativas a isso... E muitas aplicações que o PHP tem e nós
>> não! Claro que isso é um exemplo, mas que deve valer para que possamos
>> correr atrás como comunidade e fazer com que o PZP realmente possam
>> superar nossas expectativas.
>>     
>
> Sobre código de barras, temos um exemplo no site PythonBrasil:
>
> http://www.pythonbrasil.com.br/moin.cgi/CodigoBarras
>
> Ele é para apenas 1 dos diversos[1] tipos diferentes de código
> de barras. Infelizmente não é o utilizado nos boletos, mas depois
> de dar uma calibrada no Google achei essa maravilha, com os 3 tipos
> mais comuns (incluindo o 2-de-5-intercalado, usado em boletos):
>
> http://pythonreports.cvs.sourceforge.net/pythonreports/PythonReports/PythonReports/barcode.py?view=markup
>
> HTH,
>
> [1] http://en.wikipedia.org/wiki/Barcode
>
>   
Hum, isso é bacana, eu havia achado uns bem zuados :)


At,


-- 
#!/bin/bash
# Name: Cleber J Santos
# Email: [EMAIL PROTECTED]
# Icq: 200007837

Responder a