[SP-pm] Pronto Para Produção (was Re: Parse de Linguagens)

Blabos de Blebe blabos at gmail.com
Mon Oct 17 16:23:18 PDT 2011


> 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 <tiago.peczenyj em gmail.com>:
>
>
> 2011/10/17 Alexei Znamensky <russoz em gmail.com>
>>
>>
>> 2011/10/17 Tiago Peczenyj <tiago.peczenyj em gmail.com>
>>>
>>> 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 <dan.vinciguerra em gmail.com>
>>>
>>> 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
>>> <daniel.oliveira.mantovani em gmail.com>
>>>>
>>>> Você pode usar o perl -c foo.pl
>>>> 2011/10/17 Daniel Vinciguerra <dan.vinciguerra em gmail.com>
>>>>>
>>>>> 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: SaoPaulo-pm em pm.org
>>>>>  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: SaoPaulo-pm em pm.org
>>>>  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: SaoPaulo-pm em pm.org
>>>  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: SaoPaulo-pm em pm.org
>>  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: SaoPaulo-pm em pm.org
>  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: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>


More information about the SaoPaulo-pm mailing list