Conforme expliquei anteriormente, minha intenção é fazer uma comparação séria entre tecnologias que permita que decisões tecnológicas sejam tomadas com mais precisão. Porém programadores rails fizeram o desafio de responder a um vídeo que eles produziram, um vídeo nada sério para esta finalidade.
Por que não considero o vídeo de Rails sério para esta finalidade ?
O principal motivo é o fato do vídeo fazer uso de técnicas de Scaffolding. Scaffolding, para quem nunca ouviu falar, refere-se a capacidade de auto-gerar uma interface gráfica a partir da estrutura do banco ou, como é o caso do Rails, auto-gerar o banco a partir da interface gráfica.
Alguém em sã consciência acredita realmente que a interface gráfica e o banco possam espelhar um ao outro em um sistema minimamente sério ? Se alguém acredita nisso, não precisa nem seguir adiante com a leitura, pode voltar ao trabalho e ir pegar o café do chefe, afinal é para isso que estagiário serve.
Fiz questão de não fazer o primeiro exemplo com scaffolding. Sim, .NET também possui scaffolding. Ao contrário do Rails (me baseando no demonstrado no vídeo), o Scaffolding do .NET parte de um Entity Model para a interface e não da interface para o banco. Observe que eu disse Entity Model para a interface, significa que eu posso ter desenhado um modelo de objetos bem complexo e repleto de regras de negócio que se comuniquem com a base e o scafolding do .NET irá se basear neste Entity Model.
Muito mais utilizável, muito mais realista, nem por isso eu deixo de chamar de brincadeira de criança, ainda não acreditando que mesmo no modelo utilizado pelo .NET o scaffolding se tornará hábito em sistemas sérios (vou engolir minhas palavras em 2 anos, mas tudo bem, um pouquinho de sal ajuda).
Assim sendo, o vídeo que fiz para ser comparado ao vídeo-desafio-rails não usa scaffolding. Mesmo sem usar scafolding o trabalho foi completado em 25 minutos.
Qual a importância do trabalho ser completado em 25 minutos ? Merda nenhuma ! Só as amebas podem acreditar que a comparação de tempo destes vídeos pode realmente significar alguma coisa. O objetivo não é, nunca foi, fazer uma comparação direta de tempo, pois dois desenvolvedores vão com absoluta certeza completar a mesma tarefa - até mesmo na mesma ferramenta - em tempos diferentes.
O objetivo é fornecer uma comparação técnica que permita observar a forma de execução de uma tarefa em rails e a forma de execução da mesma tarefa em .NET.
Ainda assim o vídeo não é sério para este fim. Por que ? Porque não contém conteúdo de negócios suficiente para a avaliação de qualquer das duas tecnologias. Componentização, regras de negócio, capacidade de manutenção, o exemplo não cobre nada disso para permitir uma avaliação realmente séria, em termos de negócios, das duas tecnologias.
Ainda assim, os dois vídeos, com propostas equivalentes, foram feitos. O que podemos tirar dos dois ? Assista o vídeo abaixo e confira.
| .NET | RoR |
| Não fez uso de scaffolding | Fez uso de scaffolding |
| O tempo entre os 2 ficou muito semelhante. Como ficaria o tempo entre os 2 se no desenvolvimento em Rails não fosse feito o uso de scaffolding na demonstração ? Neste ponto um aparte : O uso de scaffolding no rails é eventual, correto ? Não é hábito programar apenas desta forma, ou estou errado ? Se for hábito programar apenas com scaffolding, como resolvem os problemas de regras de negócio e mapeamentos entre banco e interface ? Conforme a resposta, fica o desafio aos railers : Como ficaria o vídeo sem scaffolding ? | |
| No .NET foram implementadas 4 regras de negócio : Administrador manipula tudo, usuário comum manipula apenas seu conteúdo, usuário não logado apenas visualiza, data e usuário são determinados automaticamente. | Rails não implementou praticamente nenhuma regra de negócio, apenas a separação entre usuário comum e administrador. |
| Então fica o desafio aos Railers : Como ficaria um vídeo com a implementação destas regras de negócio ? | |
| No .NET o sistema de segurança foi completo, com base de autenticação, senha gravada em hash, garantia de segurança mínima de senha, travamento após determinado número de entradas de senha erradas, entre outros recursos. | No Rails a segurança foi fixa, em hard code. |
| Então fica o desafio aos Railers : Como ficaria a implementação da segurança completa em Rails ? | |
| o .NET fez acesso direto a banco | Rails implementou modelo MVC |
| Realmente, mas o MVC implementado pelo rails foi padrão vai scafolding. Para atingir um tempo semelhante de execução (apenas para agradar as amebas que agarraram meu pé), foi feito o acesso direto ao banco, neste ponto perdendo em capacidade de manutenção para o Rails. Porém nos vídeos seguintes isso será amplamente compensado. | |
| Alguns recursos não totalmente adequados foram utilizados para igualar o tempo de execução (traduzindo : satisfazer amebas) | Apesar de ter os mais avançados recursos a disposição, no vídeo de Rails foi feito copy/past das views |
| A utilização de copy/past das views resulta em uma duplicação do layout e consequentemente um problema para a manutenção da aplicação. Nesse caso não adianta rails ser dotado de recursos como MVC se faltam outros recursos como master pages e user controls que possam suprir a interface de uma metodologia moderna de desenvolvimento. Porém o que foi mostrado foi muito superficial e totalmente não conclusivo. | |
| No .NET já foi realizada a implementação de design gráfico básico | No rails as views foram mantidas apenas com o que foi gerado pelo scaffolding |
| No .NET, após deletar um post, se for realizado um refresh, nada prejudicial acontece, devido aos controles de segurança existentes no .NET. | O que acontece no caso do Rails ? |
| Não implementou URLMapping no vídeo | Rails implementou UrlMapping |
| Não implementou feeds Atom no Vídeo | Implementou feeds Atom |
| Resumo : O que faltou | |
| .NET | Rails |
|
|
Próximos vídeos de .NET
- Implementação de UrlMapping
- Implementação de feeds Atom
- Implementação em camadas
- Implementação com scaffolding sobre Entity Model
Conclusão
Se ainda restarem dúvidas, os vídeos seguintes de .NET mostrarão que a inclusão de tempo para a realização de todas essas tarefas será pequena (já sei quanto, mas não vou adiantar). Por outro lado, quanto tempo será necessário para as implementações que faltaram no Rails ?
Além disso, a questão em jogo não são apenas alguns minutos de diferença, o que é absolutamente insignificante. A questão no momento é o uso do scaffolding no Rails :
- O scaffolding permite flexibilidade para implementação das regras de negócio necessárias e desta forma ser utilizado de forma séria ou
- O que acontece com o trabalho de implementação se tiver que ser feito sem o scaffolding ?
Assim sendo, a bola agora está com os Railers. Se desejarão prosseguir com uma comparação séria ou se ficarão agindo como amebas, é escolha deles.
Observação Adicional
Sem relação alguma com a comparação, mas achei curioso : Railers falam mal do .NET por ser tudo muito automático, mas afinal, qual a diferença de utilizar wizards visuais ou utilizar wizards que são disparados via comandos de prompt ?
Gostou do vídeo ? Consulte o preço de livros de ASP.NET no Já Cotei Que tal visitar nossa loja de livros e analisar alguns livros sobre ASP.NET ?
17 comentários:
Não tem como deixar esse vídeo para baixar. Não está dando para ver nada e o Veoh precisa de um player especial para download que, sinceramente, não rola.
Ainda não vi o vídeo pois aqui esta sem som.
Mas vou dar meu feedback sobre algumas afirmações suas sobre o Rails.
"O uso de scaffolding no rails é eventual, correto ? Não é hábito programar apenas desta forma, ou estou errado ? Se for hábito programar apenas com scaffolding, como resolvem os problemas de regras de negócio e mapeamentos entre banco e interface ?"
O Scaffolding é apenas um recurso para agilizar as telas de CRUD que podem ser evoluídas durante o projeto, fica a escolha do programador utiliza-lo ou não!
"Não implementou URLMapping no vídeo"
Como você não conhece nada sobre o Rails, existe o recurso de Routes que é a mesma coisa do URLMapping, então existe sim!
"Nesse caso não adianta rails ser dotado de recursos como MVC se faltam outros recursos como master pages e user controls que possam suprir a interface de uma metodologia moderna de desenvolvimento."
Aqui você escreve uma tremenda besteira, além do Rails utilizar o MVC, existe sim o recurso de MasterPages, mas de uma forma bem mais simples, dentro da pasta Views/Layouts você pode definir um arquivo "application.html.erb" que serve como template para todas as views!
Enfim, antes de fazer um vídeo desse, procure conhecer melhor pelo menos o BÁSICO do Rails e outra o vídeo do Akita fica claro que o objetivo é demonstrar as novidades do Rails 2.0, em nenhum momento ali é criar algum tipo de desafio, você que começou com isso hehehe!
Falow
Samir,
Antes de escrever um comentário, procure pelo menos entender o texto sobre o qual está comentando, ok ?
Sobre a não implementação de URLMapping, quem não implementou URLMapping foi o vídeo de VS, não o de Rails, essa implementação ainda vou fazer em separado.
Quanto a master pages e user controls, parece que você se esqueceu de ver o vídeo do Akita, além de ler o texto acima cuidadosamente.
Ali acima está escrito : "no vídeo de Rails foi feito copy/past das views"
Isso é fato, foi feito. Rails não tem master pages e user controls. Tenho absoluta certeza de que tem outros recursos (templates) que vão fornecer resultado semelhante, mas por que no vídeo foi feito copy/past ?
Observe ainda que foi Akita que me forneceu o link do vídeo e me desafiou a fazer igual, vídeo que eu destaquei ser completamente inadequado para uma comparação séria entre as tecnologias pelos motivos que estão muito bem explicados no texto.
Então, resumindo, entenda o texto que está comentando antes de escrever um comentário.
Caro anônimo,
Sim, posso disponibilizar para download, apesar de que o próprio vídeo do Akita está em Veoh, como você poderá comparar ?
Que tal se identificar?
Dennes,
É claro que o Rails não possui WebControls, pois seu modelo não é baseado em componentes e isso não faz dele inferior que o ASP.NET.
Novamente torno a repetir, conheça o Rails primeiro, depois coloque seus argumentos comparativos.
Feliz Ano Novo pra você também :-)
Bom, não entrando de novo na discussão do 'desafiou', 'desafiado' que eu já disse inúmeras vezes que não dou a mínima. Não me leve a mal, explicarei de novo lá embaixo.
Primeiro, parabéns, o vídeo é mais ou menos o que eu esperava também. Conforme eu já comentei antes não duvidava que você fizesse. Como você mesmo lembrou, esse escopo é pequeno demais para se ter uma comparação sobre o fator 'tempo'.
Mas achei interessante as perguntas que você fez e acho que merecem respostas. Eu sei que ficou comprido mas peço que leia até o fim.
Primeiro de tudo, foi como o Samir disse, esse vídeo foi feito com o único objetivo de demonstrar novidades no Rails 2.0 e mais outros motivos históricos para ter sido feito do jeito que foi. Enfim, eu poderia ter feito melhor mesmo, foi mal.
Sobre scaffolding, veja bem, esse é um ponto que você talvez discorde: fazer copy/paste de um trecho da view (como um helper link_to(), por exemplo) é a mesma coisa que arrastar um User Control da palheta para a tela. Explico: você pode ter o mesmo efeito se abrir o aspx, copiar a tag <asp> digamos button e colar num outro aspx. A diferença é apenas mecânica entre 'drag-drop' e 'copy-paste'.
Aí vem mais uma questão de 'gosto': eu prefiro não precisar de uma IDE. Como disse também venho de Java e estava acostumado a um Eclipse lotado de plugins e diagramas drag-drop. O fato de se usar uma linguagem dinâmica concisa evita a necessidade de uma IDE. Não é uma boa desculpa, existem diversos grandes programadores Java que preferem mil vezes usar Emacs e é surpreendente ver como eles são mais rápidos do que eu no Eclipse. Isso é opcional, o pessoal do Saphire in Steel tem um pacote para Visual Studio que terá todos os recursos drag-drop que você está acostumado. Então, é mais uma questão de gosto mesmo. Não sou contra nem a favor de uma IDE, eu pessoalmente prefiro não usar, não recrimino quem prefere.
Estou sendo injusto, na verdade também é possível fazer a mesma coisa com ASP.NET: alguém poderiar simplesmente com um Notepad++, Scintilla, Textpad, criar um site inteiro em .NET, compilar com o compilador de linha de comando quem vem no .NET framework e funcionaria igual. Mas isso provavelmente não é prático já que o framework foi feito para ser usado dentro de uma IDE e obviamente funciona melhor assim. Mas é como o pessoal do Mono fazia antes de ter MonoDevelop. Gosto do VS. Tem muitas coisas no VS que eu gosto mais que no Eclipse e vice-versa.
Sobre Scaffolding, isso eu preciso concordar que 2 anos atrás foi um ponto de atrito muito forte para quem não era da comunidade. Ficou aquele gosto de 'gerador de código', 'coisa engessada'. Na verdade basta ver a definição de 'scaffold': uma plataforma de madeira. Literalmente um degrau extra para te ajudar.
Scaffold é literalmente um gerador de código mesmo. Da mesma forma quando você faz File -> New -> Aspx File ou parecido e ele cria um arquivo texto já pré-preenchido com um esqueleto. Você pode tirar o que está lá, ou construir a partir dele. É sua escolha. A mesma coisa no Rails: eu posso usar ou não scaffold. Como na maior parte das vezes estamos fazendo telas CRUD, usar o scaffold evita copy/paste extras (drag/drops extras, se quiser), isso porque ele automaticamente já me cria arquivos de controllers, models, views, testes unitários, testes funcionais.
Não quer dizer que precisamos fazer copy/paste de tudo, veja bem. Rails também tem o equivalente a Master Pages, apenas a chamamos de Layouts. Eu não mostrei no vídeo mas ele já havia sido gerado. Tenho layout para a aplicação toda, ou por controller, ou por action, ou por partial, posso escolher a granularidade. Por default ele já cria um para a aplicação toda e um por controller (acho que eu deleto nos videos). Note que todas as telas tem um stylesheet bem mínimo que o Rails pré-gera (não tem nada em Times Roman). Eu posso apenas substituir esse CSS pelo do meu designer e pronto.
Além disso temos partials. Não é a mesma coisa mas só para facilitar pense nisso como os antigos server-side includes (SSI). Além disso temos uma segunda camada que seria o equivalente aos User Controls que chamamos de 'helpers'. Isso eu mostrei no vídeo, como eu pego um trecho que não quero duplicar e gero uma partial.
Voltando ao scaffold. Deixe-me explicar um passo antes. No Rails, IDEs não são obrigatórias como eu disse antes. Isso não quer dizer que não podemos ter algumas das mesmas facilidades como os 'wizards' de uma IDE. A diferença é apenas que a chamamos de 'generator' e usamos via linha de comando. Fica a gosto do cliente fazer via linha de comando ou usar o novo NetBeans 6, por exemplo, e fazer usando wizards gráficos também.
No caso específico de Rails temos generators/wizards para várias coisas: controllers, models, views, testes, etc. Ou se já sabemos que vamos fazer um CRUD podemos usar o generator chamado 'scaffold' que gera todo o conjunto necessário. Se não quisermos alguma coisa, basta apagar. São pouquíssimos arquivos, com pouquíssimo conteúdo e todo ele é editável. Não existe restrição. É literalmente um esqueleto mesmo. Mas mais do que isso, no Rails existe um sistema que chamamos de 'Migration'. Isso permite uma coisa chamada 'evolução de banco de dados'. Em vez de precisar fazer um Big-Up-Front-Design de todas as tabelas, podemos criar uma por vez, adicionar colunas, tirar colunas, adicionas índices, etc. Para cada etapa ele gera um arquivo de migration numerado de forma crescente.
Por que isso? Imagine que eu trabalho numa equipe, cada um com seu banco de dados de desenvolvimento local (seja sqlite3, seja MySQL, etc). Eu resolvo que preciso de duas colunas novas. Como meu colega 'ganha' as mesmas colunas (o requerimento aqui é que cada desenvolvedor tem seu próprio banco de desenvolvimento, isso é opcional, claro). Toda vez que eu preciso mudar algo no banco, eu crio um arquivo de migration. Esse arquivo eu subo num repositório (por exemplo SVN, poderia ser o Team Server). Quando o outro desenvolvedor der update do repositório, ele recebe esses arquivos e com um comando o banco de dados local dele é 'migrado'/'evoluído' de maneira não destrutiva.
Isso é útil também em deployments de produção quando eu quero subir uma nova versão de código que também requer mudança em alguma tabela. Tudo isso sobe automatizado, tanto código quanto evolução do banco de dados. Na prática, o banco de dados ganha uma 'versão'. Outra coisa: não há SQL envolvido, é tudo feito sobre Ruby puro.
Dito isso, o Rails infere a partir dos meta-dados da tabela no banco quais são as colunas e tipos que ela contém, de forma que eu não tenho etapa de mapeamento entre a classe-model e a tabela. A partir desses meta-dados ele consegue gerar o esqueleto inicial via scaffold com uma tela básica que eu posso escolher usar "as-is" ou modificar por completo. Da forma como está no meu vídeo, basta acrescentar um CSS e acabou.
Por outro lado eu posso instalar outro plugin como ActiveScaffold que faz um scaffold ainda mais sofisticado, todo em Ajax, etc sem nenhuma linha de código (se eu não quiser). Ele gera a tela totalmente através de meta-dados no model que eu posso escolher detalhar ou não. Depende do nível de sofisticação que eu preciso. Usamos isso normalmente para telas administrativas, que exigem menos design e mais funcionalidade. Novamente, tudo opcional. Seria como se você escolhesse usar o User Control de Data Grid ou não, fazer tudo na mão com tag <div>.
Quanto às regras de negócio, a maioria vai no próprio model. Uma classe de regra de negócio são validações. Com helpers simples como 'validates_format_of' eu configuro minha classe model para se auto-validar e isso se reflete nas views com mensagens de erro - se eu quiser. Quase como preencher uma propriedade na IDE. Fora isso models tem toda uma classe de callbacks/eventos onde eu posso colocar o que quiser. Controller também tem callbacks e é como eu insiro autenticação. Posso fazer minha própria autenticação que basicamente seria: 1) criar um CRUD de uma tabela User e Permission; 2) acrescentar uma única linha no controller master (que chamamos de Application) com um before_filter e acrescentar callbacks no model para gerar criptografia da senha. No caso, como isso é um pattern comum, temos um plugin chamado restful_authentication que faz tudo isso e mais um pouco. Incluindo, claro, gravar a senha na forma de um Digest SHA1 com um salt.
Enfim, scaffold é tão útil e flexível que não faz sentido não usá-lo. Aliás, usando o generator ganhamos de graça uma API REST para cada resource gerado. De forma que imediatamente todos os models que estão naquele video são automaticamente consumíveis a partir de uma aplicação externa. E o aplicativo cliente, usando outra biblioteca do Rails chamada ActiveResource, se resume a apenas 1 linha de código, literalmente só a URL do recurso REST. A vantagem de ser uma linguagem dinâmica que permite metaprogramação em runtime significa que eu não preciso mapear absolutamente nenhum método, nenhum campo e nem usar nenhum wizard ou generator.
Para fazer uma API SOAP é um pouquinho mais complicado. Basicamente criar outra classe Ruby onde aí sim, pelos requerimentos mais restritos do SOAP, eu preciso mapear mais explicitamente métodos e parâmetros para definir uma interface WSDL. No fundo é um pouco mais do que colocar um atributo [WebMethod] como é no C#. Mesmo assim eu não preciso gerar um pacote de estruturas por trás para isso, é literalmente só uma classe-esqueleto mesmo.
Não entendi muito bem o que você quis dizer sobre o delete de um post. Todo model automaticamente tem métodos básicos como save, create, update, destroy, find. O controller também tem actions como create, update, destroy, etc. Se eu não quiser o destroy basta deletar o método da classe. Se eu quiser proteção para acesso de apenas alguns usuários basta um callback before_filter(:is_admin?, :only => :destroy) por exemplo. Mas não sei o que você queria.
O Ruby on Rails é um framework que não acrescenta internamente autenticação ou internacionalização. Motivo: é possível implementar essas funcionalidades de diversas maneiras. Em vez de escolher apenas um, eles preferiram não acrescentar nenhum. A idéia é que o Rails suporta um sistema de plugins. Se eu quero autenticação primeiro eu penso, quero algo bem simples, ou algo bem completo ou algo mediano? Escolhido o plugin é apenas um comando script/plugin install [nome_do_plugin]. Existem mais de 800 plugins. É como o mercado de OCXs e outros componentes que você pode adicionar à sua palheta no VS. Ou eu posso escolher fazer o meu próprio e encapsular num plugin para usar em meus projetos internos. Tanto faz.
Bom, se tiver mais perguntas sobre Rails tentarei satisfazer as dúvidas. Algumas das coisas que tentei explicar são difíceis de demonstrar apenas em palavras. Porém, voltando ao ponto do 'desafio': pretendo ignorar qualquer coisa com pano de fundo de 'briga'. E nesse ponto, vou pedir desculpas publicamente porque no artigo original do Meiobit eu me excedi demais. Fiz a mesma coisa em outros fóruns. Acho que isso é desnecessário. Se quiser saber mais sobre o Rails ficarei feliz em satisfazer as dúvidas como eu já faço na comunidade Rails. Sinceramente não estou no humor de ficar arranjando briga de graça. Mas discussões construtivas são bem vindas.
Inclusive, não sei se você chegou a testar o framework MVC da Microsoft. Muitas coisas nesse framework (muitos dos nomes da classes, pastas, etc) são espelho de como funciona no Rails. A equipe que fez esse framework MVC com certeza passou um bom tempo experimentando Rails. Por outro lado talvez você não goste dessa alternativa da Microsoft, não tem problema. É apenas mais uma opção. Mas de qualquer forma, ele tem uma pequena parte das características do Rails embutida caso tenha curiosidade.
E eu nao pararia no Rails. Novos frameworks como Seaside e Django tem excelentes características que nem ASP.NET nem o Rails tem e eu talvez eu implemente algumas dessas coisas em Ruby no futuro. Boas idéias são bem vindas não importa de qual comunidade.
[]'s
Esses vídeos servem para comparar aplicações simples, que na vida real não são muito uteis e servem pra alimentar briga de egos e vaidades.
Eu trabalho com rails, e é no longo prazo que vejo suas melhores vantagens:
- Estimula escrever testes
- Arquitetura que favorece elaboração de APIs
- Controle do layout- O webdesigner pode alterar a apresentação da aplicação sem grandes dificuldades
- Deployment otmizado com capistrano/vlad
- Cache e otimização do CSS e Javascripts
- HAML e SASSL, Liquid
- Facil integração com o Memcached
- E entre muitos outros plugins
- RUBY!
Isso aí. boa sorte.
Oi, Marcus !
Da forma como estão, concordo plenamente com você.
Mas uma comparação técnica mais precisa seria possível, se o pessoal de rails que faz estes vídeos levasse a sério a realização de uma.
[]'s
Samir,
Não sei nem ao menos de onde você tirou essa história de webControls. Poderia ler o texto antes de comentar ?
Que tal ler também http://cidadaocarioca.blogspot.com/2007/12/tecnologia-x-religio-o-entrave-do-avano.html ?
[]'s
Só complementando a resposta do Akita, já fazem dois dias que venho testando o CTP do ASP.NET MVC e confesso que estou impressionado com a facilidade de desenvolvimento e como está influenciado pelo Rails, então nada impede que essa seja minha plataforma de trabalho amanhã.
Oi, Akita !
"Primeiro de tudo, foi como o Samir disse, esse vídeo foi feito com o único objetivo de demonstrar novidades no Rails 2.0 e mais outros motivos históricos para ter sido feito do jeito que foi. Enfim, eu poderia ter feito melhor mesmo, foi mal."
Interessante que quando comentei que o vídeo não tinha escopo adequado, todo mundo caiu de pau em cima de mim, agora assumem que o vídeo não tem mesmo escopo adequado... interessante o timing...
"Sobre scaffolding, veja bem, esse é um ponto que você talvez discorde: fazer copy/paste de um trecho da view (como um helper link_to(), por exemplo) é a mesma coisa que arrastar um User Control da palheta para a tela. Explico: você pode ter o mesmo efeito se abrir o aspx, copiar a tag asp digamos button e colar num outro aspx. A diferença é apenas mecânica entre 'drag-drop' e 'copy-paste'."
Não, não discordo, concordo perfeitamente. Mas não foi isso que eu critiquei no vídeo.
Você não fez copy/past de um trecho de uma view, você fez copy/past de views inteiras entre a parte não administrativa e a parte administrativa, views que por motivos de negócio deveriam ter a mesma aparencia.
Este copy/past resulta em uma necessidade de manutenção duplicada, bem diferente de um simples copy/past de parte de um código.
"Aí vem mais uma questão de 'gosto': eu prefiro não precisar de uma IDE. Como disse também venho de Java e estava acostumado a um Eclipse lotado de plugins e diagramas drag-drop. O fato de se usar uma linguagem dinâmica concisa evita a necessidade de uma IDE. "
Isso é uma questão de gosto e o comentário que fiz a respeito deixei bem separado, no finalzinho.
"eu posso usar ou não scaffold."
Não duvidei disso, seria espantoso se não tivesse opção.
Mas a questão é que o scaffold cria algo muito rígido e que dificilmente se encaixa com a implementação de regras de negócio. Especialmente no caso em que vi, em que Rails faz o scafolding da interface e depois gera o banco.
.NET também possui scaffolding (Fiz questão de não usar no 1o vídeo), faz tudo ficar muito mais rápido, mas o scaffolding do .NET não é nem ao menos do banco, mas de um Entity Model, o que é um passo além, permitindo uma melhor implementação de negócios e ficando um pouco menos engessado.
Mas é o scaffolding que invalida comparações nestes vídeos, falta vermos rails implementando regras de negócio mais complexas sem o scaffolding, ou conseguindo implementar as regras que usei mesmo com scaffolding.
"Não quer dizer que precisamos fazer copy/paste de tudo, veja bem. Rails também tem o equivalente a Master Pages, apenas a chamamos de Layouts."
Sim, mas não evitou seu copy/past de views e observe a diferença que destaquei ali em cima. O que evitaria tal copy/past no rails ?
No .NET, o sistema de segurança fez com que o copy/past fosse desnecessário neste exemplo, você pode tentar montar um enunciado mais complexo para ver como o .NET se comporta.
" Mas mais do que isso, no Rails existe um sistema que chamamos de 'Migration'"
Temos versionamento de banco no visual studio, mas não entendi por que entrou neste assunto.
"Seria como se você escolhesse usar o User Control de Data Grid ou não"
De forma alguma. Não compare o scaffolding do Rails com o controle gridview. O scaffolding do Rails é comparável ao scaffolding do .NET.
O controle gridview para o .NET é como uma montagem manual. Observe a geração de templates e personalizações dos templates que fiz após ter inserido o controle gridview. Além do que toda a montagem da gravação foi feita por mim, não pelo scaffolding.
A gridview não se compara ao scaffolding do rails. A comparação justa é comparar o scaffolding do .NET com o scaffolding do rails. Gridview no .NET é o trabalho tradicional.
"Quanto às regras de negócio, a maioria vai no próprio model. Uma classe de regra de negócio são validações"
Validações são validações, regras de negócio, regras de negócio, são coisas diferentes. Ter todas as regras de negócio no model não é adequado, pois você não conseguiria chegar a um bom resultado de manutenção em sistemas que envolvessem negócios e processos complexos.
Mas o objetivo não é que acredite em minhas palavras. O objetivo é uma comparação séria, com um vídeo (ou artigo, ainda melhor) sério feito a partir de um enunciado de problema montado a 4 mãos para incluir situações que desafiem cada ambiente.
"Enfim, scaffold é tão útil e flexível que não faz sentido não usá-lo."
Um gigantesco wizard. Pelo menos desenvolvedores rails não podem mais falar mal do .NET por usar wizard. Mas essa flexibilidade deveria ser posta a prova.
"Não entendi muito bem o que você quis dizer sobre o delete de um post."
Como está no vídeo, apenas o usuário que publicou o post ou o administrador podem deleta-lo e edita-lo.
"O Ruby on Rails é um framework que não acrescenta internamente autenticação ou internacionalização. Motivo: é possível implementar essas funcionalidades de diversas maneiras."
Não considere isso uma vantagem. O .NET inclui esses recursos mas produzidos através de um design pattern de providers de forma que posso usar seu formato padrão ou personaliza-los da forma que desejar, sem precisar criar nada do zero.
Por exemplo, trocaria a base de autenticação de SQL para Oracle mudando apenas configurações no arquivo web.config, sem mudar nenhuma linha de código.
"pretendo ignorar qualquer coisa com pano de fundo de 'briga'"
Da minha parte não há intenção alguma em brigar, mas sim em produzir um material sério e tecnicamente comparativo, o que é perfeitamente possível. É uma pena que inúmeras pessoas, como alguns que comentam por aqui, não compreendam esta questão.
"Inclusive, não sei se você chegou a testar o framework MVC da Microsoft. Muitas coisas nesse framework (muitos dos nomes da classes, pastas, etc) são espelho de como funciona no Rails. "
E existe um grande debate sobre como esse framework MVC se encaixa na arquitetura de desenvolvimento Microsoft. Depois de Abril poderei responder isso em mais detalhes.
" Boas idéias são bem vindas não importa de qual comunidade."
Deveriamos ser uma única comunidade, a comunidade de desenvolvimento de software, não ? Dai que comparações técnicas poderiam ser mais bem vistas ao invés de ser algo como "o meu é melhor que o seu".
[]'s
Comentários debochados e que demonstram claramente que o autor não possui nenhum conhecimento técnico - por isso mesmo se mantendo no anonimato - serão sumariamente descartados
[]'s
"E existe um grande debate sobre como esse framework MVC se encaixa na arquitetura de desenvolvimento Microsoft."
Pra mim é justamente ao contrário, enquanto outras linguagens/plataformas fazem utilização dessa arquitetura a décadas, parece que só agora caiu a ficha da Microsoft em se aquedar ao mercado.
Isso é ruim? Claro que não, é um ótimo sinal de evolução no meu ponto de vista.
Bom, vamos lá:
"Interessante que quando comentei que o vídeo não tinha escopo adequado, todo mundo caiu de pau em cima de mim, agora assumem que o vídeo não tem mesmo escopo adequado... interessante o timing..."
Olha o que eu disse no artigo anterior:
"E deixe-me colocar bem claro outra coisa: você está certo quanto diz que esse anônimo não entendeu o que eu disse. Quando eu postei sobre meu screencast foi simplesmente porque você insistiu que queria alguém para 'competir' então eu apenas sugeri meu screencast como um baseline."
Então, me desculpo novamente pelo meu comportamento no MeioBit, principalmente, mas eu já havia me explicado por você por e-mail também e depois nos últimos comments.
"Este copy/past resulta em uma necessidade de manutenção duplicada, bem diferente de um simples copy/past de parte de um código."
Na verdade não. Como eu disse, o video tem o intuito de demonstrar novas facilidades no Rails 2.0. Esse em particular são Namespaced Routes. Dava pra fazer antes, mas ficou mais fácil no 2.0. Basicamente é só mais um mecanismo para organizar meu código. Eu copiei e colei o mesmo código - duplicando, como você disse - porque eu quis manter o exemplo simples. Se o intuito fosse mostrar autorização, eu simplesmente teria colocar um callback no mesmo controller, não precisava copiar. E mesmo assim, não está exatamente "duplicado", veja que eu modifiquei as telas e controllers, apaguei algumas views, etc. São apenas arquivos. O scaffold apenas automatizou o que eu iria fazer de qualquer maneira no controller e nas views, apenas isso.
"Mas a questão é que o scaffold cria algo muito rígido e que dificilmente se encaixa com a implementação de regras de negócio. Especialmente no caso em que vi, em que Rails faz o scafolding da interface e depois gera o banco."
Então, o comando scaffold é uma junção. Existem separadamente outros comandos que ele agrega sendo eles 'controller', 'model', 'migration', etc. Eu posso gerar o model primeiro se eu quiser, ou uma migration separada primeiro, tanto faz. E o código que ele gerou eu posso apagar inteirinho e escrever o meu, se eu quiser. As telas que ele gera são esqueletos HTML, posso mexer nele inteirinho, tirar, colocar, fazer o que quiser. Não é rígido. Ele apenas facilita colocando um esqueleto que é mais ou menos comum na maior parte das aplicações, mas de jeito nenhum é mandatório.
As regras de negócio ficam no model, na maior parte, e dependendo do que estamos falando ficam na action do controller. Em Rails o best-practice é thin-controller fat-model. Eu sei que é um pouco diferente do que fazemos, por exemplo, em J2EE onde existe a figura do DAO. Mas é outro pattern. Não estamos falando de DataMapper e sim de ActiveRecord (que é o nome da biblioteca no Rails e o nome do Design Pattern, segundo Fowler, também).
"De forma alguma. Não compare o scaffolding do Rails com o controle gridview. O scaffolding do Rails é comparável ao scaffolding do .NET."
Então, desculpe o mal jeito, eu não quis dizer que é a mesma coisa. Deixe-me explicar: faça de conta que não existisse um Grid View. No fundo, no HTML final, ele vai gerar uma série de tags HTML com dados, etc. No código significa eventos, bindings, etc. Se eu "quisesse" ignorar esse componente conseguiria fazer exatamente a mesma coisa codificando manualmente o layout do grid, e escrevendo em C# todo o código para fazer o binding com o layer de dados, etc. Foi o que eu quis dizer no caso do scaffold: se eu quiser posso fazer tudo manualmente, escrever os comandos Ruby, o HTML, etc. Mas o scaffold já gera isso para mim. Eu sei, não é a mesma coisa, não são componentes. Só quis dizer que é um "facilitador". A quantidade de código que ele gera, na realidade, é extremamente mínima. Eu poderia colar aqui neste comment e não ficaria monstruoso. Na realidade mesmo, em termos de reusabilidade os componentes do ASP.NET se equivalem ao que chamamos de 'helpers' no Rails. E o 'scaffolding' de .NET a que você se refere se parece mais com o ActiveScaffold do Rails ou ao NewForms do Django, que não são geradores de código.
"Um gigantesco wizard"
Tudo bem, pode chamar de wizard, eu também descrevi assim. Não tem nenhum problema. Só que ele não é "rígido".
"Como está no vídeo, apenas o usuário que publicou o post ou o administrador podem deleta-lo e edita-lo."
Ah tá, então é exatamente o que eu falei: um simples before_filter e um método de checagem.
"Por exemplo, trocaria a base de autenticação de SQL para Oracle mudando apenas configurações no arquivo web.config, sem mudar nenhuma linha de código."
Sim, eu sei. É a mesma coisa, no Rails em vez de web.config seria no database.yml, o Rails tem adapters para outros bancos também e a grande maioria do que fazemos é database agnostic (usamos SQL nativo apenas em casos excepcionais). Migrations são agnósticos, por exemplo, não que não tenha algo parecido no .NET. Postgre, Mysql, Oracle, DB2, MS SQL, etc.
"É uma pena que inúmeras pessoas, como alguns que comentam por aqui, não compreendam esta questão."
Como eu disse, da minha parte eu não pretendo gerar discussão negativa. Não vou responder por todos que comentam aqui porque não posso responder por todos, obviamente.
"E existe um grande debate sobre como esse framework MVC se encaixa na arquitetura de desenvolvimento Microsoft. Depois de Abril poderei responder isso em mais detalhes."
Ok, desejo boa sorte ao pessoal do ASP.NET MVC, é um bom trabalho. Não imagino porque ambos não possam co-existir.
"Deveriamos ser uma única comunidade, a comunidade de desenvolvimento de software, não ?"
Exatamente.
"Dai que comparações técnicas poderiam ser mais bem vistas ao invés de ser algo como "o meu é melhor que o seu"
Eis o problema. Sim, comparações técnicas são bem vindas. Já existem algumas. Normalmente feitas pela mesma pessoa. Como você disse, claro, normalmente essa pessoa tenderá a saber mais uma do que outra. Só que quando essa pessoa é inteligente ela não tira conclusões precipitadas "ah, X não faz isso!". Ela posta o que descobriu, sem cinismo nem sarcasmo, e outras pessoas irão comentar e complementar. Alguns serão trolls, claro, mas ignorando os trolls isso funciona. A melhor comparação entre frameworks que já vi foi uma entre Django/Python e Rails/Ruby. Muito equilibrada, o autor se dedicou a buscar uma resposta, haviam muitos pontos não-técnicos que ele levou em consideração e a conclusão foi basicamente "depende". Como eu já disse antes, depende de algumas circunstâncias. Por acaso o link para essa comparação é essa. Ele fez 15 posts detalhando suas descobertas e aceitando ajuda da comunidade via comentários, e-mails. Não ofendeu ninguém, não precisou fazer insinuações nem usar de sarcasmo.
Especificamente "ASP.NET" vs "Rails" já foi discutido ad nauseum pela comunidade. Não vejo nenhum motivo para começar tudo de novo. Sabendo navegar pelo Google verá como esse tipo de discussão normalmente não acaba muito bem (como estamos vendo agora).
Vejamos outro bom exemplo de um desenvolvedor de respeito que eu estava vendo hoje mesmo: Symfony, outro excelente framework web escrito em PHP (e não, eu não subestimaria PHP, afinal Facebook usa extensivamente e Mark Zuckerberg já ganhou muito mais dinheiro do que eu jamais pensaria em ganhar). O autor do Symfony tem uma mente extremamente aberta e humildade para dizer literalmente: "adoro ver o que o pessoal do Rails e do Django estão fazendo e me inspirar neles". Excelente exemplo.
Akita,
A questão do copy/past está perfeitamente clara que é algo específico do vídeo, não do Rails, mas ficamos sem ver como o Rails resolveria essa questão em um caso mais sério.
Quanto ao scaffolding, não, você não pode comparar o scaffolding com a gridview.
Observe que sua comparação levou você a supor um desenvolvedor ASP.NET programando de forma braçal uma exibição de dados. Isso não acontece.
No ASP.NET temos a gridview, a datalist, o repeater e a listview. A programação braçal como você citou não acontece, não faz parte do ASP.NET.
É diferente da relação do scaffolding com o Rails. O scaffolding é um elemento opcional, que você vai usar ou não e nem sempre vai usar.
Comparar o scaffolding com algo do .net teria que ser com o próprio scaffolding do .NET, não com a gridview.
Quanto ao MVC, você fez uma comparação de MVC com DAO. MVC é um design pattern para ser aplicado na camada de interface. DAO refere-se a camada de acesso a dados. No meio temos ainda a camada de negócios (que pode ainda ser maior).
Ou seja, MVC é apenas para a interface. No exemplo do vídeo de Rails, você está fazendo a interface acessar direto o banco. Interface não é apenas a view, interface é o conjunto gerado pelo MVC.
Posso prever inúmeros cenários em que isso geraria problema, mas só com testes práticos para vermos se aconteceria mesmo ou não.
"Ah tá, então é exatamente o que eu falei: um simples before_filter e um método de checagem."
Não exatamente o mesmo código, pois seu código testava apenas por administrador. Mas seria por ai, porem dependeria de todo o sistema de autenticação.
"Sim, eu sei. É a mesma coisa, no Rails em vez de web.config seria no database.yml,"
Não é exatamente a mesma coisa ou equivalente, pois enquanto .NET já traz o sistema de providers, o rails tem 800 opções isoladas para a escolha. Qual o impacto disso ? Só testando.
Além disso, será que ao escolher uma dessas 800 opções de provider de autenticação este provider iria se "casar" tão bem com uma das outras 800 opções de providers de mapa de site que podem existir ? (estou supondo a questão do mapa de site no rails, .net tem isso).
"Alguns serão trolls, claro, mas ignorando os trolls isso funciona"
Não funciona, simplesmente por ter sido feito por uma pessoa só e com isso deixa total margem para descredito. Quando feito por duas pessoas, uma de cada tecnologia, essa margem não existe.
"Especificamente "ASP.NET" vs "Rails" já foi discutido ad nauseum pela comunidade."
Debates (ao invés de discussões), só levam até um certo ponto. Após este ponto, só o exemplo prático permite caminhar.
Postar um comentário