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

[Eden Cardim]

Podemos hoje chamar o mojo de "flamework, pois parece que seus defensores
gastam mais tempo e energia jogando lama no Catalyst do que produzindo
projetos de fato. Fica até incoerente falar de produtividade.
On Jul 23, 2013 1:49 PM, "Blabos de Blebe" <blabos em gmail.com> wrote:

> Nada como o tempo...
>
> Sério que nasceu mais uma flamewar entre Mojo e Catalyst?
>
> Eu não gostava do Catalyst, fui pro Mojo que era simples e blablabla.
>
> Depois enchi o saco do Mojo quebrar minhas aplicações a cada versão e
> voltei pro Catalyst porque ele era estável e blablabla.
>
> No fim percebi que os problemas que eu encontrava não eram dos frameworks,
> mas da minha incompetência em usá-los. Na verdade a minha incompetência em
> criar aplicações web em geral.
>
> Estudei e os problemas ficaram menores...
>
>
> 2013/7/23 Nelson Ferraz <nferraz em gmail.com>
>
>> >>> 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<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 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
>
>
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130723/fb7f501a/attachment.html>