Basta que não tenha um packer encriptador pra atrapalhar a jogada. 2011/10/17 Blabos de Blebe <[email protected]>
> > Cobol e .Net vão no mesmo barco, quase. Mas quanto ao requisito de > > "obfuscação de código"? Isso ainda é muito forte? Lembro de um projeto > que > > foi feito em C++ pq ruby tinha o código "exposto", como se isso fosse > > dificultar uma engenharia reversa naquele caso. > > Um amigo meu que até acompanha a lista uma vez me disse: > > "Pra quem fala assembly não existe código fechado". > > []'s > > 2011/10/17 Tiago Peczenyj <[email protected]>: > > > > > > 2011/10/17 Alexei Znamensky <[email protected]> > >> > >> > >> 2011/10/17 Tiago Peczenyj <[email protected]> > >>> > >>> Claro Daniel, > >>> Eu percebo que a pergunta sobre "esta pronto para usar em produção" tem > 2 > >>> vertentes (que eu inventei agora). Uma vertente é generalista, que uma > dada > >>> linguagem ou ferramenta tem que servir para muita coisa. Deve ser por > isso q > >>> muito projeto é feito em Java, por exemplo. A outra é especialista: > nesse > >>> meu problema em específico eu posso usar? > >> > >> Pacman, > >> Eu acrescentaria uma outra perspectiva também à questão. A expressão > >> "Pronto para Produção" pode variar bastante dependendo do contexto no > qual > >> está inserido. Por exemplo, aqui no âmbito da lista, o que eu vi > gravitou > >> (como sempre, e como esperado) em torno da robustez técnica da linguagem > >> e/ou dos componentes do meio-ambiente que a cerca (grammar, rakudo, > etc...). > >> No entanto, levar um produto a produção, até onde eu enxergo, é uma > decisão > >> de negócio, não é uma decisão do time técnico de computação > >> (desenvolvimento/suporte/whatever), e o papel deste último grupo é > prover ao > >> primeiro a maior quantidade possível de informações para que eles possam > >> tomar essa decisão minimizando os riscos e/ou impactos para a empresa. > > > > Perfeito > >> > >> Isso dito, eu diria que "Pronto Para Produção" precisa de muito mais que > a > >> maturidade técnica do produto, precisa também, por exemplo, ter > mecanismos > >> de suporte bem definidos e ágeis. É preciso ter alguém, em algum lugar, > >> comquem você possa abrir um chamado e essa entidade de suporte tenha a > >> obrigação de atender tão rápido quanto possível. Tipo, chamar o Larry > Wall > >> no IRC???? Quanto tempo se gastaria para conseguir fazer o Larry Wall > parar > >> o que está fazendo e atender a VOCÊ? E se ele tiver outras prioridades, > ou > >> estiver dando uma palestra na Guiné Bissau, o que você faz? Pede para o > >> cliente esperar com o site fora do ar "somente por alguns dias"? Fora o > fato > >> de que, você estaria pedindo a ele (ou a qualquer outra pessoa da > >> comunidade) para resolver de graça um problema, para o qual você está > >> recebendo. Quão justo é isso? > > > > É verdade. Utilizei o exemplo do Larry Wall mais como um exemplo extremo > mas > > não soou como tal. > > > >> > >> Mais: se houver uma empresa que preste suporte para Perl, por exemplo. > >> Imagine que o cliente tenha um problema gravíssimo no site, está fora do > ar, > >> aciona o suporte com a empresa, mas eles não conseguem atender a tempo > dos > >> seus SLAs combinados. O cliente processa. Se a empresa de suporte for > muito > >> pequena, o fim dessa história é a sua morte súbita: ela vai ter de pagar > >> tanto dinheiro em multa(s) que vai falir em seguida. Não há empresas > grandes > >> atendendo Perl em escala e profundidade necessários para dar segurança > legal > >> (as in "the law", modafoca) e técnica aos clientes. > > > > Fico pensando em como isso afeta outras linguagens como Python, Ruby, > etc. > > Provavelmente ficam de fora desses nichos (acredito que o seu exemplo é > de > > prestação de serviços a TI corporativa, que além de recursos tecnicos > ainda > > faz uso de coisas como ITIL, etc). > > > >> > >> Um dos motivos pelos quais muitos projetos são feitos em Java é porque > tem > >> muita gente estudando JAva, e tem muita empresa (e grandes) dando > suporte a > >> coisas feitas em Java. Isso não é necessariamente bom, mas atende à > >> necessidade de segurança das pessoas que estão a comprar, seja essa > >> necessidade fundamentada ou não. > > > > Cobol e .Net vão no mesmo barco, quase. Mas quanto ao requisito de > > "obfuscação de código"? Isso ainda é muito forte? Lembro de um projeto > que > > foi feito em C++ pq ruby tinha o código "exposto", como se isso fosse > > dificultar uma engenharia reversa naquele caso. > > > >> > >> > >>> > >>> Eu não colocaria um software marcado como beta em produção, mas para > >>> outras coisas temos formas de avaliar melhor. Por exemplo eu procuro > >>> exemplos internos e indiretos para usar Perl no trabalho. Vou parsear > log? > >>> Vou usar Perl. Vou criar um deamon que lida com filesystem diretamente, > vou > >>> usar Perl. Isso cria uma bagagem para poder mostrar que tem X sistemas > >>> rodando por Y meses sem incidentes e, então, posso considerar. Mas isto > só > >>> rola na vertente especialista. > >> > >> No frigir dos ovos, é uma decisão de negócio porque a única forma de > >> conseguir decidir se usamos um software marcado como "beta" em produção > ou > >> não se resume a: quanto vamos ganhar/perder com isso, qual o risco de > dar > >> merda, e quanto custa se der merda? Se as respostas forem, > respectivamente, > >> uma alta e duas baixas, não há nenhum motivo pelo qual NÃO colocar em > >> produção!!! Quem decide é a grana!! > > > > Claro. Mas se quem fez marcou como beta o fez com alguma razão. Fico com > > medinho. :) > > my $twocents; > > []s > > Russo > > > >> > >> Eu não tinha pensando em usar Perl 6 ainda, nem para esse tipo de coisa. > >> Seu post me dá até mais segurança para tentar :) > >> > >> 2011/10/17 Daniel Vinciguerra <[email protected]> > >>> > >>> Tiago, > >>> Gostei muito do comentário e do seu ponto de vista e entendo > >>> que perl6 tem todas as features de que vou precisar ou no mínimo > >>> me atende de forma mais que satisfatória. > >>> A linguagem é nova ainda e as vms que estão saindo (... começando > >>> a engatinhar) estão ganhando cada vez mais poder (features, > >>> performance, etc). > >>> O fato é que, como responsável pelo projeto, que possivelmente virá > >>> a ser um produto da empresa, devo tomar algumas decisões e cuidados > >>> mínimos com este tipo de escolha, afinal de contas, tenho que usar a > >>> melhor tecnologia para atender as expectativas/necessidades. > >>> Me empolguei com o fato de poder usar perl6 para este projeto pois até > >>> então só tinha brincado com as vms para conhecer a linguagem e como > >>> o rumo das coisas é a evolução constante das vms que estão sendo > >>> desenvolvidas não vejo problemas (...ao menos graves) em usar > >>> perl6+rakudo > >>> para encarar esta empreitada. :) > >>> Obrigado a todos, e um forte braço! :) > >>> Daniel Vinciguerra > >>> Web Solutions Architect and Co-Owner at Bivee > >>> http://github.com/dvinciguerra > >>> > >>> > >>> 2011/10/17 Daniel de Oliveira Mantovani > >>> <[email protected]> > >>>> > >>>> Você pode usar o perl -c foo.pl > >>>> 2011/10/17 Daniel Vinciguerra <[email protected]> > >>>>> > >>>>> Bom dia senhores, > >>>>> Iniciei um projeto a pouco e um dos requisitos é que eu deveria fazer > >>>>> parse de de uma linguagem > >>>>> de programação. A ideia é criar uma espécie de syntax validator... > >>>>> Como não tenho experiencia com isso pensei em perguntar para ver > >>>>> se alguém tem alguma dica > >>>>> ou um módulo que eu pudesse usar. > >>>>> > >>>>> Forte abraço a todos, > >>>>> > >>>>> Daniel Vinciguerra > >>>>> Web Solutions Architect and Co-Owner at Bivee > >>>>> http://github.com/dvinciguerra > >>>>> > >>>>> =begin disclaimer > >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>> SaoPaulo-pm mailing list: [email protected] > >>>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>>>> =end disclaimer > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> "If you’ve never written anything thoughtful, then you’ve never had > any > >>>> difficult, important, or interesting thoughts. That’s the secret: > people who > >>>> don’t write, are people who don’t think." > >>>> > >>>> =begin disclaimer > >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>> SaoPaulo-pm mailing list: [email protected] > >>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>>> =end disclaimer > >>>> > >>> > >>> > >>> =begin disclaimer > >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> SaoPaulo-pm mailing list: [email protected] > >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>> =end disclaimer > >>> > >> > >> > >> > >> -- > >> Tiago B. Peczenyj > >> Linux User #405772 > >> > >> http://pacman.blog.br > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: [email protected] > >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> =end disclaimer > >> > > > > > > > > -- > > Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org > > GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C > > http://www.flickr.com/photos/alexeiz | http://github.com/russoz > > "I don't know... fly casual!" -- Han Solo > > > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: [email protected] > > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > > =end disclaimer > > > > > > > > > > -- > > Tiago B. Peczenyj > > Linux User #405772 > > > > http://pacman.blog.br > > > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: [email protected] > > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > > =end disclaimer > > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > -- Tiago B. Peczenyj Linux User #405772 http://pacman.blog.br
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
