[Recife-pm] Digest Recife-pm, volume 12, assunto 1

Cleber Morais cmorais em gmail.com
Quarta Junho 9 10:15:37 PDT 2010


Ok, agora deu.

O que tu ganhas ofendendo as pessoas? CARAMBA

Em nenhum momento eu direcionei nada para a sua pessoa e no entanto
sempre ao invés de discutir ideas, você fica agredindo? É falta de
argumento racional? Sinceramente, desisto de conversar ou até mesmo
interagir com isso.

Sobre leitura, já leu isso?
http://smeira.blog.terra.com.br/2009/10/22/espaos-criatividade-inovao-e-gambiarra/

"A despeito das depreciações que se costumam atribuir a alguns destes
tipos de procedimentos – em muitos casos com total fundamento, na
qualidade de “precário”, “feio”, “malandro”, “tosco”, o termo
gambiarra recebe também conotações positivas. Acompanhando um momento
de mudança na maneira como alguns pensadores e a própria população
brasileira têm enxergado sua cultura e identidade, o termo gambiarra
tem sido remetido à idéia do pronunciado “jeitinho brasileiro”, numa
visão que busca enfatizar em seu próprio povo, uma propensão ao
espírito criativo, à capacidade inventiva e inovadora, à inteligência
e dinâmica da cultura popular; levando em consideração a conjuntura de
adversidades e vicissitudes às quais todos nós (muitos evidentemente
mais) estamos expostos; entendendo-a como uma prática que se aproxima
de conceitos como reutilização/reciclagem ou bricolagem."

Sobre me educar, não se dê esse trabalho. Uma educação como a sua não
me serviria para nada. Pode ficar com ela TODINHA para você. E se você
acha que pessoas como eu que "queimam" a linguagem Perl, tenho pena de
você, pela ingenuidade e da linguagem, pela fraqueza.

Também espero nunca trabalhar com você e que você nunca administre uma lista.
Lamento você não ter nenhuma abertura em seu pensamento hermético, mas
isso é um problema integral e absoluto seu. Logo vocẽ que fique com
ele e suas consequências.

Até mais

Cleber M



2010/6/9 Andre Carneiro <andregarciacarneiro em gmail.com>:
>
>
> Em 9 de junho de 2010 07:45, Cleber Morais <cmorais em gmail.com> escreveu:
>>
>> Oooeee
>>
>> Que bom que um tópico simples animou tudo. Pena que a pessoa que
>> postou não falou  mais. E ai, Bruno da Fonte, o que acha de tudo isso?
>>
>>
>> Não vou entrar nesse flame wars, apesar da ENORME vontade. Só acho que
>> não é necessário ficar provocando com essas coisas de "vai estudar"...
>> Porque eu estudo. Eu leio e sei, com o limite da minha opinião, o que
>> estou falando. Programo em Perl há 9 anos e já mantive um sistema web
>> com mais de 8000 usuários cadastrados e mais de 300 acessos por dia.
>> Ah, e sou formado, ok? E com Mestrado. (Já imagino o comentário Troll:
>> "Putz, pior ainda!"). Defendido minha pessoa, continuemos.
>>
>
> Isso não tem nada a ver com ser formado ou não. Tem a ver com
> profissionalismo e caráter...
>
>
> 'Eu leio e sei, com o limite da minha opinião, o que
> estou falando. Programo em Perl há 9 anos e já mantive um sistema web
> com mais de 8000 usuários cadastrados e mais de 300 acessos por dia.'
>
> A parte dos 9 anos .. Nem vou comentar !
>
>
>> Mas o ponto que levanto é: é mais fácil aprender Perl programando ou
>> aprender Perl aplicando restrições?(Antes de mais nada, aprenda boas
>> práticas; leia o perldocs -- preferencialmente todo--, levante bom
>> requisitos, documente corretamente, use a metodologia adequada, passe
>> pelos momentos de iteração... para fazer sua calcuradora).
>>
>>
>
> Não tem nada a ver com restrições, novamente você está usando desculpas
> esfarrapadas. Como eu já disse, código bem-feito não é luxo, é obrigação!
> Você pode fazer um código decente sem aplicar metodologia alguma, apenas
> seguindo bom-senso e boas práticas de programação. Agora, não tem como você
> aprender e aplicar isso se não ler a respeito e se não usar no dia-dia, e
> isso eu faço questão de passar na lista sim, ao invés de código pronto,
>  porque entregar coisas de mão-beijada é errado, e acostuma mal pessoas como
> você.
> E mesmo que não seja de mão beijada, sou contra estimular a preguiça. E
> considerando que faz 9 anos que você trabalha com isso, já deveria estar
> mais do que familiarizado e identificando a cultura Perl, e do significa é
> bom-senso quando se desenvolve;
> Lembrando é claro, emergências existem, assim como exceções, mas são
> emergências e exceções. Tornar código 'suíno' um hábito é um mal-hábito, não
> importa o que você diga, ou a desculpa que você arrume. É simplesmente
> inaceitável pensar dessa maneira e deixar pra deixar coisas mal-feitas, e é
> um absurdo e uma falta de respeito aos iniciantes que você tente estimular
> as pessoas a fazer o mesmo. Portanto, enquanto fizer isso vai ser comida de
> trolls.
>
>>
>> Acho que o mais importante é, desculpem a lista, é aprender a
>> programar. Qualquer coisa, de qualquer jeito.
>
> cmorais -- # Meus pêsames para você! Espero que nunca venhamos a trabalhar
> juntos.
>
>>
>> Por sorte nossa, usamos
>> Perl, que possui um monte de coisas que facilitam a aprendizagem e o
>> modelo mental de cada um. Algumas linguagens não são tão fáceis assim,
>> tão mnemónicas (toda vez que uso C tenho que ficar xingando o fato de
>> não poder atribuir simplesmente um valor a um array). Mas o objetivo é
>> PROGRAMAR, não aprender Perl. E eu venho de uma "linhagem" de caras
>> que aprendem fazendo. Teorizar é ótimo, mas nem sempre aprende-se onde
>> coloca isso no mundo. Prática é legal, mas esvazia o conhecimento. Por
>> isso acredito que começamos com a prática e depois vamos para o estudo
>> para melhorar a prática...e entra em loop.
>>
>
> Ferramentas diferentes para propósitos diferentes. As particularidades são
> algo que simplesmente você tem que lidar. C veio de uma época bem diferente
> de Perl. Quando ela surgiu mal se falava em coisas como orientação a
> objetos, por exemplo. Se você não é capaz de lidar com isso, então mude de
> ferramenta, ou mude a ferramenta! Reclamar é fácil...
>
>>
>> Meu objetivo quando falei era fazer o Bruno programar, numa abordagem
>> top-down. Todo mundo na lista estava falando bottom-up (leia o
>> perldocs, veja o CPAN...). Mas isso não é a parte mais legal (pelo
>> menos para mim) do Perl. A parte mais legal é funcionar.
>>
>
> Não, teu objetivo é convencer as pessoas a serem medíocres enquanto for
> conveniente! Isso me revolta, e se você postar isso em outras listas talvez
> seja até banido, e garanto que você não sobrevive um semana trabalhando numa
> empresa séria dessa maneira. E nem deveria mesmo!
>
>>
>> É fácil dizer que o código é uma desgraça. E é mesmo. Não é uma obra
>> de arte e nem pretende ser. Mas eu asseguro que funciona. Asseguro que
>> pode ser melhorado e asseguro que foi o único (e até agora, quando
>> mandei essa mensagem) que mandou código para a lista.
>
> 'Funciona' não é desculpa pra deixar mal-feito, tão pouco ensinar a fazer
> errado, menos ainda estimular os iniciantes a fazer o mesmo. Aquele código é
> uma desgraça, e repitirei isso quantas vezes for necessário.
>
> Só pra deixar bem claro a diferença, e o quanto de 'trabalho extra' você
> teria, Bruno. Aqui embaixo tem um código que é meramente didádico, mas
> semanticamente correto, e segue as boas práticas de programação.
> <code>
>
> #! /usr/bin/perl
> use strict;
> use DBI;
> use Config::General; #Modulo extremamente poderoso para tratar arquivos de
> configuração.
> my $cobj = Config::General->new('meuarquivodeconfiguracao');
> my %config =$cobj->getall;
> my $dsn = 'DBD:Meudriver;infodeconexcao';
> my( $user,$pass) = ( $config{user} , $config{passwd} );
> my $dbh = undef;
> #Tentando a conexão com tratamento de erros básico.
> eval{DBI->connect($dsn,$user,$passw,
>                                                          { ShowError => 1 ,
>                                                            RaiseError => 1 ,
>                                                            AutoCommit => 0 ,
>  #se for fazer INSERT, UPDATES ou DELETES, vai precisar tratar isso com
> transações. A não ser que esteja trabalhando com bancos que não lidam com
> transações.
>                                                            #... várias
> outras opções. Veja a documentação!
>                                                          } );
> };
> if($@){ #Se der problema, Perl vai jogar o erro em $@. Para saber o que
> significa, RTFM em perlvar
>            print "\nErro de conexão: $@\n";
>            exit 0;
> }
>  else{  #a conexão está ok.
>           my $sth = undef;
>           my $query = 'SELECT * FROM SOMETABLE WHERE ID = ? '; #A
> interrogação é o 'place holder' que eu mencionei. Mais detalhes na
> documentação do DBI.
>           eval{
>                     $sth = $dbh->prepare($query); #Sempre bom dizer ao DBI
> que tipo de query você vai querer executar. Assim ele pode tomar algumas
> providências...
>                     $sth->execute('algumvalor'); #Executa efetivamente o
> SQL. Repare que 'algumvalor' é o valor que será substituido em '?'.
>           };
>           if($@){ #Se der problema, novamente, tratar aqui, utilizando $@
> como referência.
>                  print "\nNAO FOI POSSIVEL RECUPERAR A INFORMACAO! $@\n";
>                  exit 0;
>           }
>           else { #meus dados estão acessíveis através de sth. Só preciso de
> um método para iterar as tuplas.
>                  while(my $result = $sth->fetchrow_hashref){
> #fetchrow_hashref é o meu método preferido para iterar tuplas. Existem
> outros. RTFM DBI.
>                        my $dado = $result->{alguma_coluna_do_BD};
> #fetchrow_hashref me retorna os dados no contexto de referência para um
> hash. Difícil de entender? Pergunte, que eu respondo.
>                  }
>                 $query = 'INSERT INTO SOMETABLE (id , field1) VALUES(?,?);
>                 eval{
>                      $sth = $dbh->prepare($query);
>                     $sth->execute(1,'somevalue');
>                 };
>                  if($@){
>                       print "\nERRO! Nao foi possivel executar o INSERT:
> $@\n";
>                       $dbh->rollback; #cancela a transação!
>                       exit(0);
>                   }else{
>                       print "\nINSERT OK!";
>                       $dbh->commit; #confirma a transação!
>                      exit(1);
>                   }
>            }
>            $sth->finish; #Se nao vai mais usar esse 'Statement Handle', ou
> seja, o cara que efetivamente busca os resultados das suas 'queries', então
> você deve finalizá-lo! Caso contrário pode continuar usando sem ter que
> refazer a conexão. Você pode fazer isso quantas vezes quiser.
>      }
>      if(defined($dbh){
>           $dbh->disconnect; #Se não vai mais usar a conexão, em hipótese
> alguma deixe aberta, mesmo sabendo que alguns SGBDS utilizam timeout para
> fechar conexões inativas...
>      }else{
>          exit 0;
>      }
>
> </code>
> OBS: Alguns bancos exigem um comando 'start_transaction', ou algo do tipo,
> mas nem todos...
> Esse é um código decente(embora básico), mas não tem POG nenhum, tem um
> nível de segurança razoável(mas dá pra melhorar).
> Você pode separar as operações em métodos/funções, pode criar um módulo DAO
> e abstrair essas coisas, enfim... tudo sem POG!
> Percebe que não é difícil e não é sacrifício nenhum fazer esse tipo de
> coisa?
>
>
>
>> Espera, é uma
>> lista de boas práticas e leitura comentada ou de programação? Ou
>> existe uma metodologia para falar disso? Primeiro manda o cara ler
>> tudo que vier pela frente... Se ele continuar na lista, manda ele ler
>> mais outras coisas, se realmente o cara for chato suficiente para
>> continar, mandamos algum código para ele calar a boca </trolling>.
>> [Não resisti a essa provocação...]
>>
>
> Se você não está familiarizado com a cultura Perl, mesmo trabalhando a 9
> anos com a linguagem, nem vou perder meu tempo tentando te explicar o motivo
> de ter postado as sugestões de leitura. Se um dia mostrar algum interesse e
> vontade de aprender de verdade, terei prazer em passar o que eu sei, mas não
> sem que você me mostre estar disposto a procurar as respostas e tentar de
> verdade a fazer as coisas direito. Caso contrário pode continuar falando
> besteira, prometo que não vou mais responder, a não ser quando tentar passar
> isso adiante como se fosse o modo como todos deveriam trabalham com Perl.
> Nesse caso vou arrancar árvores e bater em você com elas, como é de costume
> dos Trolls...
>
>>
>> Concordo com o Breno e o MACAE. E, acho importante frizar, não sou
>> contra POG. Só acho que você não deve vender gato por lebre. Não venda
>> POG como se fosse ouro, não venda documentos quando o que você precisa
>> é uma coisa muito simples.
>>
> POG é algo que simplesmente não deve existir em um ambiente de produção. Se
> existe, tem algo errado, ou na abordagem do problema, ou no projeto, ou em
> algum momento onde o foco do projeto se perdeu. Em resumo, quando não se
> sabe mais o que está fazendo e o prazo aperta, aparecem os POGS! Não saber
> não fazer algo não é pecado nenhum. Todo mundo tem 'gaps' de aprendizado.
> Mas isso não é desculpa para abandonar a idéia de fazer as coisas
> corretamente e sair fazendo besteira e depois vir dizer que 'funciona', isso
> é de uma mediocriade atroz, e é punível na maioria das listas principalmente
> fora do país. Hoje eu me sinto na obrigação de tentar orientar pessoas como
> você, não porque eu me simpatize com você,  mas primeiro porque é como o
> desenvolvedor Perl é 'educado e disciplinado' por default e em qualquer
> lista, e porque atitudes como a sua infelizmente refletem na comunidade como
> um todo, e acabam prejudicando a linguagem e queimando Perl no mercado de
> trabalho, e isso, no final, indireta, ou diretamente, refletirá em mim no
> futuro.
> Agora se você quer continuar sendo medíocre, então seja medíocre, não vou
> mais te incomodar com as minhas 'chatices'. Mas não permito que você tente
> passar esse tipo de mentalidade adiante. Então vou censurá-lo sim toda a vez
> que você tentar dizer algo tão estúpido quanto 'Não é seguro, mas funciona.'
>
> Ficou ofendidinho? Ao invés disso reflita, converse com o Macaé, e vai ver
> que ele concorda com boa parte das bobagens que eu escrevi...
>
>
> Cheers!
>
>
>>
>> But... With that being said... I'll probably goes with the tomatoes.
>> It'll be a lot of rain in your area latter this year and that will
>> help the crop. Next caller! [1]
>>
>>
>>
>> Cleber M
>>
>>
>> [1] Calls for Cthullu http://www.youtube.com/watch?v=-DsgZ4JXXB8
>>
>>
>>
>> 2010/6/8 Andre Carneiro <andregarciacarneiro em gmail.com>:
>> >
>> >
>> > Em 8 de junho de 2010 17:05, Cleber Morais <cmorais em gmail.com> escreveu:
>> >>
>> >> Hmmm
>> >>
>> >> Bem, uma das coisas que eu gosto em Perl é que existe inúmeras
>> >> maneiras de programar.
>> >> De certa forma, isso diz que cada programador de Perl segue uma forma
>> >> diferente de escrever
>> >> E literalmente pensar. Eu por exemplo, oriento meu códigos a sujeira
>> >> que funciona até
>> >> limpeza artística. Má prática de programação? Poderia ser, se os
>> >> códigos não funcionassem.
>> >> Para facilitar a manutenção, organizo depois que o sistema funciona.
>> >
>> > Que medo!
>> > Desde que você aplique isso para scripts descartáveis eu até posso
>> > concordar.
>> > Mas num projeto maior, se você usa esse tipo de mentalidade, só posso
>> > dizer
>> > que sinto muito pelo seu patrão e pela empresa onde você trabalha. E se
>> > o
>> > seu patrão pensa assim também, pobre dos clientes.
>> > Duvido que você chegue ao que você mencionou de 'limpeza artística'.
>> > Mesmo
>> > porque isso tá me parecendo mesmo é conversa mole!
>> > Qualidade não é luxo da empresa, é DEVER do desenvolvedor. Por favor não
>> > trate com desdém essas coisas. Dizer que programar de qualquer jeito e
>> > melhorar depois é 'conversa pra boi dormir' !! Com o tempo( e já vi
>> > acontecer muito por aqui ), profissionais/empresas que trabalham assim
>> > logo
>> > perdem credibilidade e/ou clientes( salvo as raras exceções ).
>> > Se você faz bem-feito logo de início, não precisará se preocupar tanto
>> > com
>> > manutenção no futuro, isso é fato! Se não fosse asim não existiriam
>> > padrões
>> > de projeto, nem seriam necessárias as criações de padrões de
>> > desenvolvimento. Todos os desenvolvedores ganhariam bem e fariam orgias
>> > com
>> > seus códigos...
>> > Então não me venha com essa, e seja profissional por favor! Atitudes
>> > como
>> > essa só queimam o filme da linguagem e da comunidade.
>> >
>> >
>> >>
>> >> Ruim, para mim,  é fazer um código perfeito documentado em cinco
>> >> camandas... que não roda direito.
>> >>
>> >
>> > Se você fez isso e mesmo assim o código não roda direito, então o
>> > problema é
>> > o seu projeto, não o fato de você usar programação em camadas. Você é
>> > que
>> > não sabe fazer, portanto pare de falar besteira vai estudar!
>> >
>> >>
>> >> Para quê todo esse preâmbulo? Para dizer que você pode aprender DB
>> >> fácil e rápido com Perl.
>> >
>> >
>> > A questão não é aprender rápido, mas superficialmente. Se você aprende
>> > algo
>> > superficialmente, vai ter resultados superficiais, ou seja, código POG,
>> > armengues, ou sei lá mais o q...
>> >
>> >
>> >>
>> >> E depois você incrementa, melhora, desenvolve, em conjunto com sua
>> >> capacidade de programação.
>> >>
>> >
>> > Sinto muito, mas desculpa de alejado é muleta!!!
>> > Não, meu caro! Uma coisa é você começar com algo simples, outra é
>> > começar
>> > com algo errado, continuar fazendo errado, e sugerir que façam errado !
>> > Existem várias maneiras 'certas' de se resolver um problema, não precisa
>> > dar
>> > relaxo só porque tá com preguiça fazer, ou com preguiça de ensinar.
>> >
>> >>
>> >> Porque isso? Quanto menos dificuldade você tiver para COMEÇAR em Perl,
>> >> mais fácil será para você FICAR usando. Perl tem uns truques que são
>> >> realmente muito legais, porque não aproveitar isso?
>> >>
>> >
>> > Ninguém falou nada sobre 'não usar truques', truques != "ARMENGUE" ,
>> > como se
>> > diz por aí... Armengue é coisa de amador preguiçoso, aceitável somente e
>> > em
>> > casos extremos e temporários, e olhe lá... E isso não tem nada a ver com
>> > ser
>> > um programador 'preguiçoso', como disse Larry Wall.
>> > Resumindo, seja, acima de tudo, PROFISSIONAL. Ame o que faz e faça
>> > direito!
>> > Perl dá muitos atalhos para resolver as coisas, de muitas maneiras
>> > diferentes. No entanto você é quem precisa decidir se o seu código vai
>> > ser
>> > reaproveitável, de fácil manutenção( ou nenhuma, se possível ),
>> > escalável,
>> > elegante, e não menos importante, robusto, e você deve cuidar disso,
>> > pois
>> > Perl não vai cuidar pra você!!!
>> >
>> >>
>> >> No caso de um DB, muito provavelmente tanto faz se for Windows ou
>> >> Linux. O código é extremamente portável... Não chega a ser uma
>> >> dificuldade. Normalmente eu uso Perl para Web, o que para mim é
>> >> incrivelmente mais fácil pensar front-end. Mas terminal também rola e
>> >> muito legal.
>> >>
>> >
>> >
>> > E você ainda programa para web pensando desse jeito? E no WIndows?????
>> > Só pelo fato de você trabalhar com Windows, já deveria estar 10000x mais
>> > preocupado com questões de segurança, no windows + web nem se fala!!
>> > Bruno,
>> > não escute o que esse homem diz. Ele precisa de mais orientação que
>> > você!
>> >
>> >>
>> >> Saca só esses dois códigos: http://codethe.net/codigo/perlDB.zip
>> >> É esperado, se você tiver todos os pacotes, que esse código funcione
>> >> tanto no Windows como no Linux. Eu uso Linux, mas já rodei esses
>> >> carinhas ai no Windows...No Windows, eu uso normalmente o ActivePerl,
>> >> que acho bem arrumado e já vem com PerlPackageManager2 (ppm) vulgo
>> >> "cpan" no linux. Você diz qual é o pacote, ele instala. Simples assim.
>> >>
>> >
>> >
>> > Você precisa realmente se atualizar e ler mais a documentação do DBI,
>> > principalmente sobre 'placeholders'. E com certeza precisa aprender
>> > sobre
>> > tratamento de erros e transações. Esse código é uma desgraça! Totalmente
>> > sujeito a falhas de segurança e crash. E isso não é algo que se deva
>> > tratar
>> > 'melhorando depois'...
>> >
>> >>
>> >> É tudo o que você precisa, o resto é melhorar e aplicar.
>> >>
>> >
>> > Não, com certeza não é. Meu conselho é que não se siga esse caminho,
>> > pois
>> > vai dar tiros no pé, e vai se arrepender muito depois. Sem mencionar que
>> > vai
>> > acabar sendo demitido mais cedo ou mais tarde por uma malfadada cagada.
>> > Ou
>> > pior, vai acabar se decepcionando injustamente com a linguagem.
>> >
>> >>
>> >> Com esses códigos ai você já pode fazer um sistema que funcione em
>> >> rede conectando a DBs remotos... Não é seguro, mas funciona =D
>> >>
>> >
>> >
>> > 'Não é seguro, mas funciona' . Você é parente do Maluf ?? Trágico que
>> > você
>> > pense assim. Espero que mude de atitude um dia.
>> >
>> > É nessas horas que dá vergonha de ser brasileiro.
>> >
>> >
>> >>
>> >> Precisas estudar SQL e alguma coisa sobre Hashes e iteração neles...
>> >>
>> >> No mais, mão a obra!
>> >>
>> >
>> > Essa aqui é piada, né?
>> >
>> >>
>> >> 2010/6/7 Bruno da Fonte <brunodafonte em gmail.com>:
>> >> > Boa tarde,
>> >> > gostaria de ter "aula particular" de Perl, na verdade quero aprender
>> >> > a
>> >> > utilizar o perl em windows com algum banco de dados, já peguei vários
>> >> > tutoriais na net más não dá, pois não sou programador por profissão e
>> >> > sim
>> >> > por hobbye.
>> >> > Se souber de alguem que cobre para ensinar, gostaria do contato. Acho
>> >> > que em
>> >> > uma manhã já daria pra pegar.
>> >> > Obrigado
>> >> > Bruno da Fonte
>> >> > brunodafonte em gmail.com
>> >> > 81.9232.4444
>> >> > _______________________________________________
>> >> > Recife-pm mailing list
>> >> > Recife-pm em pm.org
>> >> > http://mail.pm.org/mailman/listinfo/recife-pm
>> >> >
>> >> _______________________________________________
>> >> Recife-pm mailing list
>> >> Recife-pm em pm.org
>> >> http://mail.pm.org/mailman/listinfo/recife-pm
>> >
>> >
>> > Cheers!
>> >
>> > --
>> > André Garcia Carneiro
>> > Analista/Desenvolvedor Perl
>> > (11)82907780
>> >
>
>
>
> --
> André Garcia Carneiro
> Analista/Desenvolvedor Perl
> (11)82907780
>


Mais detalhes sobre a lista de discussão Recife-pm