bah, esse SVN::Core eu NUNCA consegui instalar :/ e preciso dele pra testar algumas coisas subversion+perl<br><br><div><span class="gmail_quote">On 4/24/07, <b class="gmail_sendername">Adriano Ferreira</b> <<a href="mailto:a.r.ferreira@gmail.com">
a.r.ferreira@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 4/24/07, Eden Cardim <<a href="mailto:edencardim@gmail.com">
edencardim@gmail.com</a>> wrote:<br>> On 4/24/07, Thomas Britis <<a href="mailto:thomas@tcnet.com.br">thomas@tcnet.com.br</a>> wrote:<br>><br>> > > <trecho de código de um .cgi do bugzilla><br>
> > > use strict;<br>> > ><br>> > > use lib qw(.);<br>> > ><br>> > > require "globals.pl";<br>> > > </trecho de código de um .cgi do bugzilla><br>> > >
<br>> > > Realmente tá feia a coisa... Desisti de ler o resto do código depois<br>> > > de ler essas três linhas iniciais...<br><br>Olha o exagero, pessoal! O BugZilla é um projeto open-source e se não<br>
tem dinheiro custeando o desenvolvimento, trabalha-se nele quando<br>possível e quando é agradável. Ah, e também do jeito que a experiência<br>dos desenvolvedores em atividade favorece. Refactoring de código nunca<br>foi agradável - a tendência do "se funciona, vamos em frente" é muito
<br>grande.<br><br>Se tem dinheiro custeando o desenvolvimento, pode ser que o<br>patrocinador não insista no melhoramento da qualidade do código e<br>assim o foco pode cair na evolução e criação de novas funcionalidades.
<br>Claro que de remendo em remendo, um dia a casa cai e alguém vai<br>precisar abrir um outro projeto para refazer o BugZilla e tantos<br>outros projetos.<br><br>Os pecados do código fonte estão por todos os lados, principalmente
<br>nos projetos maiores. Como o próprio interpretador Perl, por exemplo.<br>Por exemplo, eu me lembro de alguns desenvolvedores do core que<br>abominavam as partes do PerlIO. E não foi qualquer um que escreveu o<br>PerlIO, foi o falecido Nick Ing-Simmons que escreveu o módulo Tk
<br>também.<br><br>> > Eden,<br>> ><br>> > Boa tarde.<br>> ><br>> > Qual seria(m) o(s) problema(s) desse trecho de código?<br>> ><br>> > Atenciosamente,<br>
><br>> - falta um < use warnings > depois do < use strict > para evitar dores<br>> de cabeça num projeto do tamanho do bugzilla<br><br>Este problema acompanha de perto o terceiro que comento logo abaixo.
<br><br>> - < use lib qw(.) > ao meu ver, está sendo usado para adaptar a<br>> estrutura mal-definida (segundo os meus critérios individuais) do<br>> código, que mistura bibliotecas (.pl = perl library) com executáveis
<br>> (.cgi). Se não me falha a memória, ter o diretório atual no @INC dá<br>> vazão a falhas de segurança, tanto é que Perl não coloca o '.' no @INC<br>> se o taint mode estiver ligado.<br><br>Este eu não consigo justificar não.
<br><br>> - < require "globals.pl" > tem dois problemas. Primeiro, usar globais<br>> é má prática vastamente conhecida. Nem abri o arquivo globals.pl, mas<br>> se por acaso ele não contém nada global, o nome não suficientemente
<br>> descritivo, o que é ruim do mesmo jeito. Segundo, "globals.pl" está<br>> escrito com aspas duplas, o que obriga o compilador a analisar<br>> inutilmente a string em busca de candidatos a interpolação. Isso
<br>> prejudica bastante o desempenho de uma aplicação cgi, já que o<br>> programa inteiro é recompilado cada vez que se faz uma requisição.<br><br>< require "globals.pl" > é coisa de Perl 4, o que sugere que o
<br>BugZilla já está com os cabelos brancos e, na sua evolução, não foi<br>modernizado para Perl 5. Acho que são problemas comuns em<br>distribuições que não estão no formato comum utilizado no CPAN<br>onde o mantra deve valer
<br><br> perl Makefile.PL<br> make<br> make test<br> make install<br><br>Não estar no CPAN é o caso de alguns projetos importantes: como o<br>binding Perl ao Subversion, WebGUI, Movable Type e outros. E para
<br>dizer a verdade, depois que você se acostuma a comodidade das<br>distribuições CPAN, é aborrecido por exemplo conseguir os bindings<br>Perl para Subversion de uma outra forma que não "cpan install<br>SVN::Core".
<br><br>Mas assim é a vida. Melhorem os seus projetos open-source favoritos.<br>Continuem a falar daqueles que os incomodam.<br><br>Adriano.<br><br>> --<br>> Eden Cardim<br>> Instituto Baiano de Biotecnologia<br>
> Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas<br>> Laboratório de Bioinformática<br>> _______________________________________________<br>> Cascavel-pm mailing list<br>> <a href="mailto:Cascavel-pm@pm.org">
Cascavel-pm@pm.org</a><br>> <a href="http://mail.pm.org/mailman/listinfo/cascavel-pm">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br>><br>_______________________________________________<br>Cascavel-pm mailing list
<br><a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/cascavel-pm">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br></blockquote></div><br><br clear="all"><br>
-- <br>Lindolfo "Lorn" Rodrigues<br>- <a href="http://www.slackwarezine.com.br">www.slackwarezine.com.br</a><br>- <a href="http://lornlab.org">http://lornlab.org</a><br>- <a href="http://sao-paulo.pm.org">http://sao-paulo.pm.org
</a><br>use Catalyst;