[SP-pm] Resultado parcial do Survey Monkey...

Eden Cardim eden at insoli.de
Thu Jul 19 09:51:31 PDT 2012


>>>>> "Nelson" == Nelson Ferraz <nferraz em gmail.com> writes:
    Nelson> Eu tenho usado o Mojolicious em aplicacoes web, mas nada de muito
    Nelson> sofisticado ate' agora.

A pergunta é: se sua aplicação não é sofisticada, porque não usar um CMS?

    Nelson> Ate' agora nao tenho nada a reclamar -- ele simplesmente funciona. :)

Bom, na minha experiência, todas as apps que eu escrevi nele precisaram
ser re-escritas pra acompanhar os caprichos do sri. Sério, se nenhuma
das suas apps quebraram com os trocentos rewrites e quebras de
retrocompatibilidade ao longo da história do projeto mojo, você
provavelmente deveria estar usando um CMS.

    Nelson> (E e' por isso que muita gente usa PHP. Se o projeto der certo -- e
    Nelson> essa e' uma questao de mercado, nao de tecnologia -- o codigo pode ser
    Nelson> reescrito mais tarde.)

Engano seu. Sistemas raramente são re-escritos na prática porque é
difícil justificar o custo do re-trabalho pro departamento financeiro,
principalmente quando o "departamento financeiro" é a poupança de uma
empresa pequena e iniciante. Talvez no seu universo seja fácil
justificar isso ou os recursos sejam abundantes aí, ou sei lá. No meu
não é. E mais especificamente, quando se trata de um sistema escrito em
perl, boa parte das considerações de re-escrita geralmente envolvem
re-escrever em outra linguagem "mais simples".

    Nelson> Se eu fosse desenvolver um ERP, consideraria o Catalyst -- por causa
    Nelson> da maneira como ele estimula a separacao em varias camadas.

Isso é um engano *tremendo* da sua parte, ele não estimula nada,
inclusive, não tem nada pré-implementado nele que faça ou estimule esse
tipo de separação no código do end-user e a doc é bem clara quanto a
isso:

https://metacpan.org/module/Catalyst::Manual::Tutorial::02_CatalystBasics#The-Simplest-Way

O Dancer e o Mojolicious é que já vem com camadas pré-implementadas de
funcionalidades semi-prontas, como renderização de templates, cookies,
etc. que ele acha que você vai precisar.

    Nelson> O que me faz pensar que talvez possamos separar os casos de uso da
    Nelson> seguinte forma:

    Nelson> 1) Uso corporativo -> enfase no planejamento, na construcao de bases
    Nelson> solidas -> Catalyst, Java

Não, não precisa planejar nada porque 90% da sua app vai estar
pré-implementada através dos componentes disponíveis. Inclusive, existem
já trocentas apps cujo desenvolvimento envolve a mera instalação de
alguns componentes, com *zero* de código. É igual instalar word, excel,
outlook, open office, etc. Exceto que você tem os fontes se precisar
customizar depois.

    Nelson> 2) Startups, hobbies -> enfase na experimentacao, nas possibilidades
    -> Mojolicious, Dancer, PHP

Talvez hobbies sim, mas no caso de startups o que eu vejo é exatamente o
contrário, ninguém quer "explorar possibilidades", todo mundo quer
solução pronta, zero de desenvolvimento e 100% de foco no negócio. Não
considero que o PHP entre nessa categoria, no mundo do PHP quase ninguém
monta um sistema do zero usando só usando frameworks, geralmente é um
CMS abarrotado de plugins e customizações, e não é isso que o mojo e o
dancer oferecem, e eu sei porque eu os uso.

    Nelson> Esta divisao nao e' rigida, mas talvez explique porque os usuarios de
    Nelson> (2) reclamam da "complexidade" de (1).

O que não entra na minha cabeça de jeito nenhum é porque existem pessoas
no mundo que consideram que instalar e configurar alguns componentes
usando *zero* de código é algo "complexo" e "corporativo".

    Nelson> Obviamente os usuarios de (1) nao vem complexidade nenhuma, pois estao
    Nelson> habituados com a linguagem/framework.

Você está enganado, e essa afirmação ressalta o fato de que você não
conhece nem o framework nem o eco-sistema.

-- 
Eden Cardim
+55 11 9644 8225


More information about the SaoPaulo-pm mailing list