Um livro introdutório escrito pelo internauta Koalant (faça login para fazer o download).
Apresenta a linguagem Ruby, instalação do Rails e um exemplo simples. Muito útil para iniciantes. Altamente recomendado!
Se você estiver envolvido no desenvolvimento j2ee como programador Java, certamente usará muitas estruturas de aplicativos. Nenhuma linguagem é tão ativa quanto a comunidade de linguagem Java, e qualquer novo conceito de programação em breve terá implementações de código aberto correspondentes na Internet. Correspondendo ao modelo de desenvolvimento de sites MVC mais comumente usado, cada camada terá muitos frameworks e Tapestry pertencentes à camada controladora (C), e a estrutura Velocity pertence à camada de visualização (V). seja Hibernate, iBatis, OJB ou qualquer uma das muitas implementações de código aberto de JDO, como JPOX. Mas ter demasiadas opções não é necessariamente uma coisa boa, e nem todos podem adoptar a estrutura certa para fazer a coisa certa. Se sua plataforma de desenvolvimento for .net, você poderá evitar essa situação. Normalmente, você só precisa instalar um Visual Studio .net como ferramenta de desenvolvimento e, em seguida, instalar um MSDN para encontrar informações. Para os desenvolvedores de programas, esta é uma situação muito difícil. Pessoalmente, gosto muito de Java, seja para aprender ou praticar, ele nos fornece muito. Mas por que acho que soluções “one-stop” como .net estão corretas muitas vezes?
Como programador Java, acho que alguns dos problemas mais óbvios do Java são que, em primeiro lugar, Java é muito complexo e, em segundo lugar, Java é muito orientado ao programador e não ao usuário. Comparado com C++, Java já é muito simples. O fato de existirem tantos programadores Java agora ilustra esse ponto. Mas como alguém disse uma vez: “No Linux, você pode facilmente dizer quem é o mestre”, mas não é tão fácil no campo Java. Muitas vezes descubro que meus colegas ao meu redor ainda cometem erros conceituais de nível muito baixo. Eles ainda podem se envolver no desenvolvimento j2ee por muitos anos, mesmo que não consigam distinguir com precisão o que são interfaces, classes abstratas e Servlets. Mas por que Java é considerado complicado porque requer muitas tecnologias diferentes para realizar uma coisa? Então, para programadores que não têm conceitos muito claros, como garantir que eles farão a escolha certa? E quantas das muitas estruturas fornecem serviços “one-stop”? O framework Spring recentemente surgido oferece o maior número de serviços entre muitos frameworks, mas tem um novo problema, ou seja, ainda é muito orientado para programadores, não para usuários. Por que você diz isso? Frameworks são originalmente projetados para programadores, não é mesmo? Embora o Spring ofereça muitas opções (mas não o suficiente, ele não possui um ORM próprio), ele não fornece uma maneira simples de usá-lo, então só podemos dizer que é para programadores. A maioria dos frameworks Java apresenta esse problema, ou seja, a curva de aprendizado é relativamente alta. Acho que o nível da curva de aprendizado é a chave para distinguir se um framework é para programadores ou usuários. Acho que isso se reflete principalmente na facilidade de uso do framework. Na verdade, os usuários finais da estrutura são programadores. A razão pela qual usamos "usuários" e "programadores" para distinguir é porque algumas estruturas para "programadores" são difíceis de usar, embora forneçam uma grande quantidade de infraestrutura e peças. eles ainda exigem que os próprios programadores o montem. A estrutura orientada ao "usuário" é mais simples. Os usuários só precisam seguir as instruções para usá-la. Por que Ruby on Rails causará sensação na comunidade Java, acho que o motivo é que ele fornece uma estrutura "one-stop" orientada ao usuário, simples e fácil de usar, que falta na estrutura Java. Por que o Ruby on Rails pode fazer isso? Não é possível que o próprio Java não possa fazer isso? O fato é que muitos designers de frameworks Java não fazem isso. Pode ser que seu pensamento tenha se limitado a como usar padrões para projetar um bom framework, e eles não tenham feito mais sobre a facilidade de uso do framework. Qualquer pessoa que já usou Spring sabe que seu arquivo de configuração xml irá se expandir gradualmente, embora possamos facilmente dividi-lo em arquivos de configuração mais pequenos para resolver este problema. Mas ao usar arquivos de configuração xml, segue o conceito habitual de programação Java: "Java é a melhor linguagem de programação, XML é a melhor linguagem para descrever dados e a combinação das duas é a mais perfeita. Se um aplicativo não usar xml para descrevê-lo, então não é um bom aplicativo Java."
No entanto, é neste ponto que Ruby on Raiils se distingue de muitos frameworks Java e alcança um avanço na facilidade de uso do framework. Essa ideia permeia todo o design do Rails: convenção sobre configuração. Por exemplo, quando escrevemos aplicativos da web Java, geralmente distinguimos as classes correspondentes de acordo com o MVC. Pessoalmente, gosto de colocar a classe Controller no diretório da web, a classe View no diretório de visualização e a classe de modelo no diretório intermediário do domínio. . Mas pessoas diferentes têm configurações e nomes diferentes. Como permitir que o framework conheça esses diretórios diferentes? A única solução para o framework Java é informar essas informações por meio do arquivo de configuração xml. A solução do Rails é: eu defino a estrutura de diretórios e você só precisa colocar as coisas no diretório que defini. Esta é uma razão importante pela qual existem poucos arquivos de configuração no Rails (mas não nenhum). Embora a ideia seja muito simples, o benefício que ela traz é que a eficiência de desenvolvimento do Rails é 10 vezes maior que a do desenvolvimento Java (isso é afirmado pelos fãs do Rails, mas acredito nisso, e acredito que você também saberá disso depois de ler este artigo ). Então, isso por si só torna o desenvolvimento do Rails mais rápido do que usar Java? Não inteiramente, porque isso também se beneficia de outra filosofia de design do Rails: menos código. Nenhuma linguagem pode afirmar isso. Rails consegue isso inteiramente graças à sua linguagem de design Ruby. Com Ruby você pode realmente escrever muitas funcionalidades em uma pequena quantidade de linguagem que simplesmente não é possível com outras linguagens. Para dominar Rails, você deve entender Ruby. Alguém disse uma vez: Zope (o famoso framework web python) é uma aplicação matadora de python, e python é a arma secreta do zope. Acho que esta frase é mais apropriada para descrever a relação entre Rails e Ruby.
Expandir
