[SP-pm] Vaga catalyst

Daniel de Oliveira Mantovani daniel.oliveira.mantovani at gmail.com
Fri Oct 7 15:59:50 PDT 2011


maluco++

Salvo um artigo para o próximo equinócio :)

2011/10/7 Thiago Rondon <thiago em aware.com.br>

> On Fri, Oct 07, 2011 at 06:17:09PM -0300, Tiago Peczenyj wrote:
> >    Nao querendo sair do assunto mais ja saindo.
> >    Nao sei comec,ar um projeto com catalyst. Vejo o cookbook, acho
> maneiro,
> >    mas parece que nao da liga no cerebro. Pode ser questao de tempo,
> talvez.
> >    Mas o ciclo de vida de um request no catalyst ainda nao entendi, por
> >    exemplo.
>
> Tiago,
>
> Acredito que tua dúvida é muito pertinente.
>
> E pensando nisto, em 2009 eu escrevi este tutorial em pt_BR sobre o
> Catalyst:
>
> https://github.com/maluco/catalyst-tutorial-ptbr/blob/master/catalyst.pod
>
> Ela contempla o uso do Catalyst, com um exemplo simples de um aplicativo de
> agenda telefonica.
>
> Bonus: Este exemplo ainda funciona.
>
> E sobre a requisição, é interessante dizer que a filosofia do Catalyst esta
> direcionado em oferecer uma flexibilidade grande para o desenvolvedor,
> facilitar
> o "plug" de várias "coisas" de forma simples. Resumindo: o que visualizo é
> que
> outros frameworks são mais simples de começar, porém tornam a vida do
> desenvolvedor
> extremamente dificeis depois do "ponto" que você começa a necessitar de
> funcionalidades diferentes, seja ela direcionado para escalar sua
> aplicação,
> se comunicar com um servidor web de forma diferente, ou até mesmo interagir
> com outros módulos já existentes.
>
> Bonus: Você não fica "amarrado", tirar seu aplicativo do Catalyst é tão
> simples, pois na realidade ele trata tudo de forma "orgânica", e você
> acaba depois de um determinado tempo, entendendo que isto faz muito
> sentido.
>
> ATENÇÃO: Isto não é uma defesa ao Catalyst, e sim a sua filosofia. É da
> mesma
> forma que eu defendo módulos do namespace "Cache::", "AnyEvent::" e etc.
>
> Muitos de nós, acabamos desenvolvendo na fase inicial do "relacionamento"
> com
> o framework, baseado apenas na simplicidade de uma sintaxe, e esquecendo
> que
> além de desenvolver um aplicativo web, precisamos testar, precisamos
> manter,
> tornar a vida de quem for manter simples. Isto significa, que na minha
> opinião
> "dividir" as tarefas sempre que possível, ou seja, o que é de
> responsabilidade
> do framework seja bem definido, o que é de responsabilidade do banco de
> dados é
> do ORM XPTO, o que é de responsabilidade por serializar as coisas são de
> modulos
> determinados, o que é de responsabilidade por efetuar cache, são dos
> módulos
> no namespace Cache::, enfim...
>
> Bonus: Na minha opinião, a arquitetura de desenvolvimento do Catalyst é tão
> "simples" e orientado ao objetivo de ser exatamente um framework web, que
> em muitos casos, alguns frameworks dizem que esta filosofia é limitada, ou
> seja, um framework poderia fazer mais, ele poderia até serializar seus
> dados,
> ele poderia até acessar o teu banco de dados, ele poderia até executar
> testes
> automaticamente, enfim...
>
> CONTRA: Dificulta o acesso por muitos desenvolvedores a tecnologia, pois
> exige uma curva de aprendizado maior, e além do aprendizado no framework,
> de
> vários outros aplicativos que estão ao redor do framework, e que vão
> completar
> ele. Um framework que oferece sintaxe simples, que faz muito mais do que
> ele
> se propõe, oferece uma maneira muito mais rápida no primeiro contato para
> resolver teus problemas de forma geral.
>
> PRÓ: Liberdade para o desenvolvedor, o framework web, sendo apenas um
> framework web, e nada mais do que isto, na prática significada de forma
> prática estabilidade e flexibilidade no mundo de "software-livre", ou seja
> 'plugue' com o que você quiser, e há muito menos código para aprimorar.
>
> Bonus: É melhor testar 'tudo' junto, ou tudo separado ? Ou os dois ? O
> interessante do Catalyst, que você é orientado de certa forma a resolver
> seu problema fora do framework web, e isto vai te ajudar muito, quando
> você começar a elaborar testes, ou mesmo quiser trocar de framework web.
> ;-)
>
> Mas, depois de tudo isto, fica uma outra pergunta, o que significa ser
> melhor ? O que significa visualizar 'liga' no framework que vou utilizar ?
>
> Acredito que o Catalyst é uma boa escolha, quando você procura simplesmente
> um framework web.
>
> Se você procura um framework web, que faça mais do que a proposta dele, e
> que isto vai te oferecer facilidades iniciais para o teu desenvolvimento,
> o Catalyst pode ser para alguns, uma escolha 'dificil', devida a curva
> de aprendizado.
>
> E por isto, que em alguns tutoriais normalmente que descrevem, 'vejam
> qual o ciclo de requisição no meu framework':
>
>    sub respondendo_requisicao: URL('/') {
>        my $resposta = shift;
>        return $resposta->html("Olá mundo, veja como sou simples") if
> $parametro eq 'html';
>        return $resposta->json( mundo => 'sou simples') if $parametro eq
> 'json';
>    }
>
> Teoricamente, isto é possivel de se fazer em qualquer framework, basta você
> efetuar o teu setup para isto, e aí o que muda o setup 'default' ou mesmo
> o esforço que foi realizado para simplificar a sintaxe.
>
> Atenção: Eu acredito que a sintaxe do Catalyst poderia ser melhor, como
> usuário do framework. Eu gostaria de ver um projeto "em cima" do Catalyst
> oferecendo uma sintaxe mais simples no geral.
>
> Porém, qual é o meu real ganho com isto ? O meu ganho é sintaxe, mas eu
> preciso saber o que o framework esta fazendo 'debaixo' dos panos. Eu posso
> ter problemas logo ali, que se eu não entender bem, o que ele esta fazendo
> é complicado, vou ter que estudar mais para debugar algo e etc. O
> interessante
> é que este framework já consuma tecnologias que uso em outros cenários, e
> não apenas para o meu framework, isto gera uma curva de aprendizado
> "pós-inicio de relacionamento" muito menor.
>
> Bonus: Aplicações web, estão cada vez mais complexas, cada vez mais
> extendendo
> ferramentas diversas, tecnologias distintas, ou seja, saber que minha
> solução faz só uma tarefa e trabalha bem em conjunto com outros, é baita
> duma vantagem.
>
> Veja, minha indagação, não é nem sintaxe agora, e sim o que o framework faz
> no 'ciclo de vida da requisição'. Pois bem, eu ainda não encontrei nenhum
> framework web que faça isto melhor que o Catalyst, pq ? Ele simplesmente
> não quer saber de nada, ele simplesmente quer 'rotear' as requisições entre
> a minha aplicação, os módulos já existentes para suas respectivas tarefas e
> o servidor web.
>
> Ou seja, o 'ciclo de vida da requisição' no Catalyst é tão simples de ser
> explicado, que dificulta na comparação com outros frameworks. Pois, ele
> não faz mais nada além do que dizer 'você vai para cá, você vai para lá',
> agora o que você vai fazer lá, ou cá, é de responsabilidade tua.
>
> O setup 'default' do Catalyst é o MVC, que ele cria uma estrutura de
> diretórios para oferecer esta arquitetura, que é um consenso na grande
> maioria dos desenvolvedores web, ou seja, quem 'responde' a requisição é
> o "Controller".
>
> No "Controller" nada mais temos do que :
>
> 1. sub root : Args(0) PathPart('') ... {
> 2.    my ($self, $c) = @_;
> 3.    warn $c->request->user_agent;
> 4.    $c->response->headers->header( 'X-Foo' = 'Bar')
> 5. }
>
> 1. Estou declarando o "cá" ou o "lá".
> 3. Estou buscando a informação da requisição já efetuada, o user agent.
> 4. Estou setando um cabeçalho HTTP para resposta.
>
> Ou seja, nestas poucas linhas, eu estou setando quem responde por este
> "código", estou mostrando informações da requisição, e estou preparando
> a resposta.
>
> Veja uma coisa, tanto a requisição, como a resposta, são baseado nos
> módulos do namespace "HTTP::" para oferecer compatibilidade com diversos
> outros módulos que trabalhem com HTTP.
>
> Qual o papel além de um framework do que este ?
>
> Esta pergunta, pode levar você para um framework ou outro. Quem vai
> definir, são suas necessidades, se você quer uma sintaxe por exemplo
> que retorne JSON diretamente como resposta, você pode ter um cenário
> para distinguir dois frameworks:
>
>    use JSON;
>    sub foo {
>        return JSON->encode(foo => 'bar');
>    }
>
> Ou, ter:
>
>    sub foo {
>        return json(foo => 'bar');
>    }
>
> O que é mais simples ? O segundo, claro. Mas, antes de falar de sintaxe
> precisamos saber o que é feito por baixo dos panos, e é por saber o que
> o Catalyst faz e não faz, que opto por ele, e hoje o entendimento da
> "vida requisição" dele é até 'muito simples' e me deixa muito confortavel
> e seguro de saber que ele utiliza módulos com a mesma filosofia que ele,
> ou seja, o próprio módulo JSON que esta disponível não só para este
> framework, assim para tantas outras soluções.
>
> Eu acredito que estes frameworks mais novos, que estão oferecendo uma
> vida mais simples, podem ensinar muito para o Catalyst em relação a
> "tração" de usuários-desenvolvedores. Assim como o Catalyst pode
> ensinar muito, em como "manter tudo" de forma mais estável e elegante
> em relação ao ecosistema da comunidade Perl, no caso em especifico.
>
> Enfim, não tenho a menor intenção de gerar um flame war em cima desta
> resposta, e sim de levantar questões que eu ainda não vi sendo debatidas
> aqui. Na minha opinião pessoal, precisamos valorizar projetos que
> estão fazendo bem para todos, e não só para ele. Afinal, como comentei
> aplicações web estão cada vez mais complexas, e cada vez mais vamos
> "tirar proveito" de ecosistemas paralelos de desenvolvimento.
>
> O tempo é cada vez mais precioso, e eu hoje quero saber sim o que
> esta "por traz" dos desenvolvimetos de projetos em geral, até por
> que isto me dá uma baita segurança como profissional, saber que as
> coisas dificilmente vão ser descontinuadas de uma hora para outra
> e eu ter uma porção de código que não será mais compativel com nada.
>
> Desculpe o e-mail longo. Se tiver alguma dúvida mais pontual, por
> favor envie.
>
> Abs,
> -Thiago Rondon
>
> =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
>



-- 
http://noticiasglobal.com

"If you’ve never written anything thoughtful, then you’ve never had any
difficult, important, or interesting thoughts. That’s the secret: people who
don’t write, are people who don’t think."
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111007/5d98f0b9/attachment-0001.html>


More information about the SaoPaulo-pm mailing list