Às vezes ouço pessoas reclamando de seus clientes, dizendo que eles insistir sobre o uso de Rails, que eles usaram Kool Aid demais. Se eles são recrutadores, eles quase se sentem mal por ter que encontrar outro desenvolvedor de Ruby on Rails ‘primadona’. Em seguida, eles puxam algo semelhante a este incrivelmente ignorante comparação entre Git e PHP para provar seu ponto. “Eles nem sabem o que estão pedindo”, dizem.
Para nós como programadores , às vezes realmente parece que nossos clientes não têm a menor ideia. Adoramos exagerar em casos como este. Quando você pensa um pouco sobre isso, não parece certo pensar que uma pessoa que está me dando dinheiro para construir coisas é de alguma forma limitada e 'simplesmente não entende'. De fato, Eu acredito que a maioria dos clientes conhece suas opções muito bem, mas eles ainda decidir ir com Rails.
Vou tentar explicar o que, na minha opinião, torna o Rails benéfico o suficiente para ser considerado seriamente para uma infinidade de projetos e necessidades.
crie seu próprio token erc20
É possível que ninguém saberia sobre os benefícios do Ruby se não fosse pelo Rails em si. Algumas pessoas gostam de menosprezar Ruby, dizendo que é 'tão fácil para Ruby' com seu 'cavaleiro de armadura brilhante chamado Rails' e que sem Rails, 'Ruby seria irrelevante'. Não posso dizer com certeza se isso é verdade ou não, mas sei que seria uma grande pena se o mundo perdesse uma linguagem tão excelente. O fato é: o autor de Rails escolheu Ruby deliberadamente, e sua aposta ‘selvagem’ rendeu muito interesse. O que ele viu naquela época, muitos outros podem ver hoje. Ruby de alguma forma capacita os programadores de uma maneira especial que é tão difícil de explicar para as 'massas sujas'. Então, por que usar Ruby on Rails? Ruby deixa os programadores felizes, como anunciado.
Embora a maioria dos desenvolvedores concorde que Ruby é útil, alguns o veem como demais assim. Eles se preocupam com o que pode acontecer com todas as liberdades que Ruby permite, todo o potencial para uso indevido. Deixe-me ilustrar com alguns patches de macaco:
'1'.to_i #=> 1 class String def to_i raise 'foobar' end end '1'.to_i #=> RuntimeError: foobar É muito fácil: com apenas cinco linhas de código, pegamos uma classe existente e substituímos seu comportamento. Nohting é sagrado - nem mesmo uma corda. Esse erro específico seria fácil de detectar, mas as coisas podem ficar muito mais sinistras:
class String def to_i self.to_f - 1.13 end end '2'.to_i #=> 0.8700000000000001 Assim, introduzimos um erro na classe String que poderia ser envolvido e obscurecido por camadas e camadas de complexidade.
Então, você pode estar pensando: Todo mundo e sua mãe podem bagunçar meu precioso aplicativo? Embora esse comportamento realmente pareça assustador - realmente não é. Em cinco anos de usando Ruby , Não tive exatamente nenhum problema com esse comportamento. Pode parecer contra-intuitivo, mas dirigir carros a 60 MPH em direções opostas também é, separados apenas por uma fina linha branca no meio da estrada. Na prática, ambos funcionam muito bem.
Outro benefício é que Ruby é uma ferramenta versátil. Como tal, tem bordas afiadas em forma de faca. Gosto de pensar que os adultos podem manusear facas muito bem - proteção contra crianças é para, bem, crianças ( Tweet ) E ser tratado como uma criança em TI deixa você uma vítima de Paul Graham Paradoxo de Blub : você acha que está melhor sem certos recursos que não entende ou que alguém disse que você é muito perigoso. Claro, hoje estamos perguntando “por que usar Ruby on Rails”; portanto, este é um debate para outro momento. É certo que Ruby perde alguns recursos que outras linguagens têm (Lisp hmm, hmm). Em suma, Ruby está perto do topo do 'continuum de poder da linguagem'.
Meus primeiros anos com Ruby foram humilhantes. Aprendi muito apenas lendo o código de outras pessoas. Às vezes, eu ficava surpreso; às vezes, eu ficava bravo; mas, eventualmente, esse conhecimento permitiu que eu me comunicasse com meu computador com muito mais eficácia do que antes. Eu quase sinto pena de algumas outras linguagens de ‘burocracia’ que fazem você pular obstáculos apenas pelo fato de pular através deles, enquanto te digo “Eu estou apenas fazendo o que é melhor para você, é para o seu próprio bem!”
Há um profundo respeito pelo pragmatismo entrelaçado no DNA de Rails no nível mais baixo possível. Em combinação com os benefícios do Ruby, este pragmatismo produz soluções elegantes e encoraja / inspira o Comunidade de desenvolvimento Ruby on Rails para fazer o mesmo. O pragmatismo é frequentemente anunciado como uma tenda de Rails, então essa afirmação não é nova, mas me lembrei de sua veracidade recentemente, quando um amigo meu tentou me mostrar o quão “legal” Hibernar realmente é. Ele estava lutando. Eu podia sentir sua dor, pois ele era incapaz de definir uma miríade de opções e parâmetros de configuração que deveriam ter sido os padrões do framework em primeiro lugar.
proteger aplicativos da web é mais fácil do que proteger outros sistemas.
Com a idade, meus padrões de complexidade artificial têm crescido cada vez mais. Considerando que comecei a escrever código de produção em 1989, aos 11 anos (começando com um projeto para o meu vizinho ao lado em Clipper Summer '87 ), Tenho tolerância quase zero para complicações desnecessárias. E Rails tem uma pontuação muito alta nesse departamento. É mais do que apenas 'convenção sobre configuração'; Estou falando sobre toda a mentalidade pragmática que é altamente valorizada e permeia a comunidade Rails.
Rails é o mais próximo possível do inglês (a menos que você esteja usando COBOL). Ele usa o que é conhecido como um interno DSL , estendendo Ruby com sua própria semântica. Construir uma DSL é sempre perigoso, pois você está efetivamente desenvolvendo uma nova linguagem. Por ser interno, você não precisa usar um analisador externo, mas, de certa forma, parece uma nova linguagem. A equipe Rails atingiu um bom equilíbrio com seu DSL, usando-o onde fazia sentido e raramente exagerando, demonstrando excelente autocontrole. Eu acho que qualquer programador, independente da experiência com Rails, (e até mesmo alguns não-programadores) poderia entender isso:
class User true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => '240x240>'} has_attached_file :cv ... Na verdade, se você não está familiarizado com Ruby, isso pode parecer estranho - é quase como se não fosse uma linguagem de programação. Depois de perceber que são apenas chamadas de método sem parênteses, você está pronto para prosseguir. Ainda assim, o Rails DSL parece ser uma linguagem especial para descrever requisitos quando na verdade é apenas uma nomenclatura inteligente e uso inerente da excelente sintaxe do Ruby.
Rails tem um exército de committers que garantem que ele permaneça em ótimas condições. Muitos projetos acalmam com a idade, mas com Rails, faíscas ainda voam quando decisões precisam ser feitas. Parece que os mantenedores (ainda) realmente se importam e querem que as pessoas usem Ruby on Rails e entendam seus benefícios.
Muitos projetos acalmam com a idade, mas com Rails, faíscas ainda voam quando decisões precisam ser feitas. TweetEmbaixo do próprio Rails, como uma cereja no topo, está o Ruby com seu formidável gerenciador de pacotes, RubyGems , comparável a CPAN em termos de número de pacotes - e considerando a idade do CPAN, essa afirmação é (para dizer o mínimo) muito impressionante. O Rails teve um breve descarrilamento ao tentar fazer seus próprios “plugins Rails”. Felizmente, isso não pegou, então RubyGems continua sendo a fonte unificada e excelente para código programado por indivíduos muito brilhantes.
qual é o tamanho recomendado de uma equipe scrum?
A sinergia entre uma linguagem legal, um framework web pragmático e uma comunidade excelente dá ao Rails um resultado muito melhor do que a soma de suas partes.
Rails tem andado por aí. De uma forma meio hipster, não é nem tão legal assim. Isso é bom quando se trata de escolher uma pilha de tecnologia: você quer algo comprovado. E Rails é exatamente isso. Recentemente, escrevemos um artigo falando sobre a grande variedade de Intérpretes e tempos de execução Ruby que agora estão disponíveis.
Eu sei eu sei. Como profissional de TI, devo realmente valorizar 'grave' coisas e ignorar o 'Brilho' . Pode parecer superficial, mas vamos enfrentá-lo:
Não se trata nem de vaidade; trata-se de envolver o máximo de pessoas inteligentes que puder para colocar água no moinho. Quando as estruturas são consideradas, o melhor lugar para estar é no meio da multidão. Escolher uma estrutura na qual essas pessoas inteligentes estão se concentrando significa simplesmente que muito mais terreno já foi coberto para você. E isso me leva ao meu próximo ponto.
Eu tenho um fraquinho por estruturas minúsculas. Gosto quando consigo entender o que uma estrutura específica está fazendo e por quê. Nesse sentido, Rails é um pouco inchado e às vezes até opressor.
O dilema aqui: quantas vezes você deseja escrever as mesmas coisas repetidamente? Algumas delas podem ser reescritas melhor, tenho certeza, mas isso leva tempo - muito tempo. Quanto mais você permite que o Rails faça por você, menos você terá que se preocupar em reescrever ou reimplementar sua funcionalidade.
Rails é (como se costuma dizer) ‘baterias incluídas’. Isso não é uma coisa boa se você gosta de esparsidade ou se sente necessidade de ter amplo conhecimento de como tudo funciona. Na prática, se você abrir mão de seus medos, parece funcionar. O Rails tem padrões razoáveis para quase tudo que você precisa e é modular o suficiente para evitar que você fique em uma situação difícil.
Pergunte a si mesmo novamente, por que usar Ruby on Rails ? O Rails é adequado tanto para sites públicos de última geração que competem com aplicativos JavaScript de página única, quanto para aplicativos complexos de sistema de núcleo corporativo que geralmente parecem um pouco mais 'feios' (com uma interface de usuário mais genérica e de baixa fidelidade), mas compensam isso defeito com uma tonelada de regras e lógicas de negócios complicadas. Sua vantagem é que é versátil e capaz de competir com os elegantes e poderosos.
express js vs node js
Para a maioria dos problemas comuns, o Rails tem um componente à sua disposição quase pronto para uso com documentação que está consistentemente acima da média (de alguma forma, a equipe principal do Rails persuadiu os contribuidores de que escrever documentação é legal (embora todos saibamos que é não), levando a documentos bem escritos, concisos e que economizam tempo).
Quando você deixa de lado os unicórnios e os abraços de sexta-feira, acaba com uma estrutura poderosa que pode ser usada tanto para seu futuro virador de jogo quanto para seu próximo site de negócios intermediário. E com seu conjunto de joias de primeira linha, você tem nas pontas dos dedos um arsenal que implementa algumas das idéias mais brilhantes da programação de computadores. Sem confusão.
Relacionado: Truncamento de carimbo de data / hora: um conto de Ruby on Rails ActiveRecord
