[SP-pm] Produtividade em projetos de software (era: Duvida como usar CatalystX::AuthenCookie)

[Hernan Lopes]

Na dúvida e na certeza entre catalyst, mojo ou dancer, prefiro
desenvolver novas aplicacões como um 'modulo' independente, ou seja,
desacopladas de framework e até da web... em outras palavras: como um
modulo normal para uso via cli/terminal/outras-app. Obviamente com
testes no módulo, e outros no framework web.

E com o módulo da minha app em mãos, eu consigo adicionar uma camada
web, ex catalyst, mojo, dancer... e fazer:

use My::Cool::App;

my $app = etc...

junto com as urls acessando $app->whatever

assim fica mais fácil mudar e testar diferentes frameworks

abs,

Hernan

On 7/23/13, Nelson Ferraz <nferraz at gmail.com> wrote:
>>>> Esse argumento de ser "fácil" e "rápido" é o mesmo argumento que o
>>>> pessoal
>>>> do PHP usa, e no final pela linguagem não ter uma série de features os
>>>> códigos acabam se tornando obscuros por mais que o programador use
>>>> Design
>>>> Patterns.
>>>
>>> Eu conheço mais projetos web bem-sucedidos que começaram com PHP do
>>> que em Java: Twitter e Facebook, para citar dois casos.
>>
>> Sua visão está voltada para quantas teclas você aperta no ciclo
>> inicial do desenvolvimento, e não no ciclo inteiro do software. Como
>> eu já disse antes, usamos o  Catalyst por produtividade a curto, médio
>> e longo prazo.
>
> Eu volto a citar alguns dos projetos mais bem sucedidos do mundo:
> Twitter e Facebook, que começaram em PHP. E posso falar em primeira
> mão da Booking.com, que foi inteiramente desenvolvida em Perl.
>
> Em todos estes casos as "melhores práticas" estiveram sujeitas a um
> imperativo maior: getting things done!
>
> No ano passado eu participei do Amsterdam Startup Weekend. O principal
> objetivo do evento é desenvolver, em apenas três dias, um MVP --
> Minimum Viable Product -- que possa ser testado no mercado.
>
> Sem esta visão pragmática uma pode investir meses em um protótipo que
> no final das contas vai ser jogado fora.
>
> A nossa equipe começou com uma idéia que se mostrou inviável, e no
> segundo dia decidimos começar um novo projeto do zero (o que eles
> chamam de "pivoting"). Por causa disso ganhamos o prêmio especial (ok,
> inventado na hora pelos organizadores :D) de "Spirit of the Startup
> Weekend".
>
> Para concluir...
>
> Não estou dizendo que você deve escrever código ruim. O que eu defendo
> é um equilíbrio entre "melhores práticas" e "produtividade".
>
> Se você consegue ser ágil com Catalyst, ótimo. Mas eu vejo muita gente
> perdendo semanas para conseguir entender uma linguagem ou framework,
> quando podiam estar lançando o protótipo da aplicação em dois ou três
> dias.
>
> PS: você já leu os livros de Kent Back sobre Extreme programming?
> Recomendo!!!
>
> Extreme Programming Explained: Embrace Change
> http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>