[SP-pm] Teen sells Perl cloud startup to ActiveState

[Andre Carneiro]

Em 14 de junho de 2011 20:11, Thiago Rondon <thiago at aware.com.br> escreveu:

> On Tue, Jun 14, 2011 at 07:40:36PM -0300, Andre Carneiro wrote:
> > Por favor, nada de flames por bobagens como essa q eu escrevi...
> >
> >
>
> Andre,
>
> Olha, este papo de depedencia é bem complicado de argumentar, vou
> colocar aqui minha visão sobre isto e um exemplo com o próprio
> Mojolicious.
>
> Mas, o simples fato de ter depedencia não é um problema, e porque não
> é um problema ?
>
> 1 - Você esperar um pouco mais para instalar não é um problema.


Bom, sinto dizer q não é pouco...


> 2 - Você só vai instalar uma vez, ou em algum deploy.
>

Pois é, se eu tiver um monte de clientes, é bom eu me planejar bem como vou
distribuir esses deploys. Caso contrário posso morrer de tédio! E não, não
consigo escrever coisa melhor!


> 3 - Você esta adquirindo um conhecimento e materia prima desenvolvida.
>

Do que vc está falando? Eu só tö falando de instalar o Catalyst + plugins
que eu preciso. Conhecimento do q??

4 - Você esta na maioria dos casos como 'deploy' usufruindo de testes novos.
> 5 - Maturidade, código utilizado e compartilhado por mais ambientes.
> 6 - (...)
>
>
Certo, certo...

Bom, como eu disse, isso ME incomoda. Logo não era para incomodar VOCÊ. Não
precisa me explicar nada.  Eu sei perfeitamente que o Catalyst é muito bem
escrito, e tem um cacetilhão de plug-ins e blablabla...


> E quando pode ser um problema ter dependencias ? Na minha opinião,
> apenas quando você esta utilizando um módulo mal escrito,
> e para isto é importante que você saiba onde esta pisando, saber
> da qualidade das dependencias é importante.
>
>
Nunca falei q o Catalyst é mal escrito. Tão pouco que a qualidade das
depências é ruim. Eu só... a, deixa vai... falaê!


> Por isto criar componentes e abstrações pode ser uma boa saída para
> que isto fique mais saúdavel, veja por que alguns módulos hoje são
> mais utilizados, tais eles como o DBI que é uma camada para os bancos
> de dados, o AnyEvent que é uma camada para os módulos de evento, o
> Cache que é abstração para os módulos de cache.
>
>
Dessa vez eu lembrei de guardar pra mim... :-p


> Por exemplo, veja o exemplo do Cache: http://lmctfy.org/Cache/
>
> Veja que existem vários módulos que seguem esta mesma interface, e
> isto ajuda o ecosistema dos módulos de cache serem mais saúdavel e
> funcionarem de forma orgânica. (edenc++ pela expressão).
>
> Não quero jogar pedras, mas apenas explicar por que o argumento
> de dependencias e falta de componentes fazem falta em um framework
> e por que na minha humilde opinião acredito que ele deva melhorar
> com o desenvolvimento:
>
>
> https://github.com/kraih/mojo/commits/507ece232a8975d1626263cc4d875f13148fa1e7/lib/Mojo/JSON.pm
>
> Existem módulos de JSON que são utilizados por muitos outros módulos,
> frameworks e etc... já prontos e com uma perfomace muito aceitavel
> (JSON::XS).
>
> Porém, por algum motivo (alguém sabe pq ?) o pessoal do Mojolicious
> resolveu escrever o seu próprio, veja a quantidade de bugs que eles
> estão arrumando ainda. (vide histórico)
>
> Vale apena re-inventar a roda neste caso ? Para você não ter mais uma
> dependencia (para o JSON neste caso), existe um módulo novo sendo utilizado
> e com bugs "já velhos" sendo consertado o tempo todo ?
>
> Agora fica minha pergunta, neste caso dependencias é bom ou ruim ?
>
>
TIrando o fato de ser um excelente sonífero( o que menos importa de qualquer
forma ), não vejo problemas.


> Abs,
> -Thiago Rondon
>
>




-- 
André Garcia Carneiro
Analista/Desenvolvedor Perl
(11)82907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110614/4918124c/attachment.html>