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

[Hernan Lopes]

Dessa maneira os Models (DBIx::Class,ElasticSearch,etc) ficam dentro
do módulo e não ficam no framework, mesmo sendo possível usar
normalmente diretamente no framework, mas talvez esse não seja o
conceito de framework agnostic.

No web framework fica a parte web mesmo, mas mais Controllers(thin) e
Views e quase nada de Models(pois tudo fica no módulo da app).

Assim se eu quero testar a mesma app em 3 webframeworks, preciso
apenas alterar a parte do web framework em si ex. urls de entrada,
lógica de urls e views. Embora muita coisa pode ser reaproveitada.

abs,

Hernan

On 7/23/13, Hernan Lopes <hernanlopes at gmail.com> wrote:
> 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
>>
>