Share
Ditt valg, når du lærer et nytt rammeverk, er en utrolig viktig. Det tar utallige timer og krefter å bli dyktig og lære alle de beste metodene - selv for erfarne utviklere.
Derfor er det nødvendig å forstå særegenheter av et rammeverk så tidlig som mulig for å avgjøre om det er den rette løsningen for problemet du prøver å løse. I denne artikkelen skal jeg dekke mange av hovedområdene i Ruby on Rails-rammen, og hvorfor jeg føler at det er et utmerket valg for webutviklere.
Ruby on Rails ble hentet fra prosjektstyringsprogrammet Basecamp.
Ruby on Rails ble åpnet i 2004, av David Heinemeier Hannson, etter å ha blitt hentet fra prosjektledelsen, Basecamp.
Den er basert på Ruby programmeringsspråk, og den nåværende stabile utgivelsen er 3,2 - med 4,0 rett rundt hjørnet!
RoR er en fullstendig webapplikasjonstabel; starter med versjon 3.1, inkluderer det også fasiliteter og biblioteker for å administrere frontendkoden, som støtter Sass og CoffeeScript ut av esken, uten behov for eksternt verktøy for å administrere kompileringsprosessen. Opinjonsarbeidet er navnet på spillet med Rails.
For utvikling, har den sin egen webserver, slik at du ikke trenger å installere ekstra programvare bortsett fra en fungerende Ruby-installasjon.
Det er utallige grunner til å lære Rails, alt fra teknisk til bedrift og produktivitet. Vi takler hverandre for en.
Ruby har blitt designet for å være en "glede å bruke".
Som navnet antyder, er Rails basert på Ruby-språket. Fant i 1993 og utgitt for første gang i 1995 av Yukihiro Matsumoto (kjent som bare "Matz"), er Ruby et objektorientert tolket språk som har en syntaks som er sterkt inspirert av Perl og Lisp. Siden starten har Ruby blitt designet for å være en "glede å bruke" - noe som betyr et sterkt fokus på lesbarhet og eleganse.
Ruby er et høyere nivå språk, og er ekstremt kraftig og allsidig, samtidig som den opprettholder en god balanse mellom klarhet og ytelse (med tanke på at det fortsatt er et tolket, dynamisk språk).
Den originale Ruby-tolken (Matz's Ruby Interpreter, forkortet som MR) er skrevet i C, men det er ikke den eneste som er tilgjengelig i dag (et par bemerkelsesverdige alternativer er JRuby, kjører på toppen av JVM og Rubinius).
Ruby har flere biblioteker sendt med kjernen, inkludert en meget kraftig enhetstesting, som kalles Minitest (før Ruby 1.9, Ruby brukt TestUnit).
Rails er en populær måte å bli involvert med Ruby, så det er ikke sjelden for tiden å finne folk (inkludert meg selv) hvis første introduksjon til Ruby var gjennom Rails.
Lær grunnleggende av Ruby med Tuts + Premium.
Rails er sterkt påtatt når det gjelder arkitektoniske beslutninger
Rails er en database-agnostisk MVC-rammeverk som velger konvensjon over konfigurasjon, noe som betyr at det er sterkt oppfylt når det gjelder arkitektoniske avgjørelser, navngi konvensjoner, stier og mønstre.
I mer detalj:
MVC betyr at det følger Model-View-Controller-paradigmet, slik at du tydelig kan skille problemer når du utvikler en applikasjon. Dette gjør at kjernevirksomhetslogikken din kan være på et enkelt sted, unngå duplisering og bistå med vedlikehold.
Det følger en RESTful, ressursorientert tilnærming, noe som betyr at det oppfordrer deg til å tenke på forretningslogikken fra datapunktet, og eksponere ressurser til endepunkter som utfører CRUD-handlinger. For eksempel kan logging inn på et nettsted bli sett på som "opprette en økt"; logger ut som "ødelegge en økt". Denne tilnærmingen tar litt vant til, men når du har vedtatt det tenkemåte, hjelper det med å holde grensesnittene dine konsistente og forutsigbare av andre utviklere. Rails applikasjoner pleier å dreie seg rundt modeller, som styrer data utholdenhet.
Det bruker Bundler som et verktøy for avhengighetsadministrasjon, som utnytter kraften til Rubygems-fellesskapet. Dette sikrer en konsistent tilnærming for å legge til tredjepartsfunksjonalitet i et program, med et eksplisitt format som beskriver hvilke biblioteker vi trenger, og hvilke versjoner, inkludert oppløsning av nestede avhengigheter.
Den kan støtte et bredt spekter av databaser, med SQLite som standard (bra for utvikling) og MysQL og PostgreSQL som første valg for produksjon. MongoDB kan også integreres med minimal innsats.
Konvensjonen betyr at navngivning, stier og mønstre vanligvis er forutsigbare og deles blant andre Rails-utviklere. Dette sikrer en lettere læringskurve, fokusert på forretningslogikken for appen, enklere vedlikehold og mindre dokumentasjon.
Det er lett å teste, med verktøy som integrerer med rammene for enhetstesting og integrering (med JavaScript-støtte) også. I tillegg støtter Ruby-samfunnet seg i seg selv testdrevet utvikling, så en god Rails-utvikler er sannsynligvis ganske erfaren i testing.
En Rails-applikasjon kan enkelt distribueres til sky-infrastrukturer, som Heroku, eller direkte til private servere (det går bra på Ubuntu Linux, for eksempel).
Her er en grunnleggende gjennomgang av hva Rails kan gjøre ut av boksen, sammen med noen kodeeksempler. Vær oppmerksom på at selv om du aldri har jobbet med Rails før eller ikke kjenner Ruby, bør dette ikke hindre deg i å forstå dem, da de er ganske lesbare.
Støtte for datamodelldefinisjon gjennom migreringer, dvs. repeterbare og reversible database-agnostiske instruksjoner, som manipulerer databasestrukturen. Vurder følgende migrering:
klasse CreateEvents < ActiveRecord::Migration def change create_table :events do |t| t.string :title t.date :start_date t.date :end_date t.boolean :live, :default => false t.timestamps slutten slutten
Denne overføringen oppretter en arrangementer bord, med noen grunnleggende data, som a tittel, og bruker spesifikke datatyper som er kartlagt til bestemte kolonnetyper i den underliggende databasen. For eksempel, som standard, string bruker a VARCHAR (255) kolonne, hvis du bruker MySQL. Denne overføringen kan skrives manuelt fra bunnen av eller genereres fra kommandolinjen og deretter redigeres før den kjøres.
Database agnostisk modell grensesnitt for CRUD handlinger. Her er noen eksempler, gitt a Nyheter modell:
nyheter = News.new (tittel: 'Sample news') # => returnerer en nyhetsinstans, ikke lagret i databasen news.save # => kjører et innleggssøk og oppdaterer forekomsten med det returnerte id fra databasen news.title = 'Oppdatert utvalgsnyheter' # => setter tittelen til den nye verdien uten å lagre i databasen news.save # => kjører en oppdateringsforespørsel for det aktuelle elementet news.destroy # => kjører et slettespørsmål for det aktuelle elementet
I tillegg gir Rails et enkelt grensesnitt for å utføre utvalgsspørsmål, inkludert sammenhenger mellom modeller.
Accentsconagua
News.where (publisert: true) .order ('created_at DESC') .grense (5) # => produserer 'SELECT * fra nyheter der publisert = 1 rekkefølge av created_at DESC limit 5' Støtte for valideringer; en Begivenhet modellen kan alltid kreve tilstedeværelse av en unik tittel. I så fall er det mulig å tydelig uttrykke disse kravene i Begivenhet klasse:
klassen hendelse < ActiveRecord::Base validates :title, :presence => true,: uniqueness => true end
Denne funksjonaliteten sikrer at ingen ugyldig post blir lagret i databasen, og gir også alle bindingene som trengs for å vise valideringsfeil til brukeren (for eksempel i et skjema).
Session og cookies med enkle hjelpere for å angi verdier, få og slette dem, med gjennomsiktig signatur.
Beskyttelse mot formforfalskning, slik at et hvilket som helst skjema du genererer gjennom Rails, blir automatisk signert med et token som garanterer det virkelig.
Aggressiv XSS-beskyttelsespolicy aktivert som standard, slik at ethvert skjemaelement du bruker, er beskyttet som standard, med mindre du eksplisitt hvitlister den (forsiktig når du gjør det!).
Enkel styring for FÅ og POST Data, tilgjengelig via en enkel hash tilgjengelig i alle kontrollerhandlinger.
Enkle bindinger for å koble kontroller, modeller og visninger, med klare og konvensjonelle regler som forenkler filbehandling og kode. For eksempel, vurder følgende kontroller som er ansvarlig for å gjøre en nyhetsliste side på http://example.com/news:
klassen NewsController < ApplicationController def index end end
Selv uten å skrive noen kode for å definere hva index gjør, Rails gir en standard oppførsel, som er å gjengi app / visninger / nyheter / index.html.erb utsikt. Dette reduserer behovet for boilerplate-kode, for det meste er det bare nødvendig å overstyre atferd når ukonvensjonelle.
Integrasjon med eksterne tjenester; Rails tilbyr et rikt økosystem av applikasjoner som du kan bruke til å overvåke, vedlikeholde og forbedre søknaden din (noen av dem arbeider også med andre rammer). New Relic hjelper til med å overvåke ytelsen, Airbrake Bug Tracker samler unntak for å varsle utviklingslaget, Code Climate analyserer kodebase for kvalitet, kompleksitet og duplisering. Tddium og TravisCI kan kjøre testpakken eksternt mot forskjellige Ruby-versjoner.
Som nevnt tidligere tilbyr Rails et integrert miljø for å jobbe med Coffeescript og Sass, med gjennomsiktig kompilering i utvikling og forbehandling og cache-busting for distribusjon, slik at produksjonsappen din vil betjene single-minifiserte filer med en signatur i filnavnet. På den måten kan du være helt sikker på at en hvilken som helst nettleser alltid vil laste og cache den nyeste versjonen av filen.
Har du noen gang lurt på hvorfor Rails er førstevalget av mange weboppstart? Det er to primære årsaker:
Det lar deg jobbe med funksjoner med minimal boilerplate, og fjerner mye ikke-forretningsrelatert arbeid fra utviklingsprosessen. Dette medfører økt hastighet ved utvikling og distribusjon av nye funksjoner, noe som er nøkkelen til å forstå om produktet er solidt.
Rails struktur gjør det enkelt å imøtekomme forandring. Dette er sikkert sant for mange MVC-rammer, selv om Rails er spesielt godt å restrukturere applikasjonsflyten, gjenbruk av komponenter på en enkel måte.
Det er viktig å huske at utviklingstiden ofte er dyrere enn en ekstra server.
Det er alltid en pågående samtale om Rails ytelse, og hvordan det kan bli en flaskehals når du får tusenvis av treff i minuttet. Problemet er at å komme til det nivået av trafikk krever en stor innsats. Sannheten er: 9 ganger ut av 10, skalerbarhet er et problem som mange bedrifter aldri trenger å møte. For dem er evnen til å gjøre endringer, enkel vedlikehold og forutsigbarhet langt mer verdifull.
I tillegg er det viktig å huske at utviklingstiden ofte er dyrere enn en ekstra server. Et rammeverk som Rails er ofte foretrukket, fordi selv om det kan trenge mer kraftig maskinvare, er den fortsatt kostnadseffektiv på andre områder.
Dette betyr ikke at du ikke bør bry deg om kodenes utførelse eller bekymre deg om emner, for eksempel caching og spørringsoptimalisering. I stedet betyr det å ta hensyn til hele spekteret av maskinvare- og programvareendringer du kan gjøre; Noen ganger er det fornuftig å skape en ytelsesfokusert del av arbeidet og midlertidig ha kraftigere maskinvare for å fortsette å jobbe med viktige funksjoner.
Rails kan enkelt utvides med et bredt utvalg av eksterne biblioteker, distribuert gjennom Rubygems. De fleste ganger, noen funksjoner som du trenger å bygge, tilbys allerede gjennom en perle. Nå betyr dette ikke at å legge perler er den perfekte løsningen; hver tredjepartsavhengighet som du legger til i et program, blir en risikofaktor.
Noen ganger er det å foretrekke å rulle din egen versjon med tilpasset kode.
Når det er sagt, bør du ikke gjenoppfinne hjulet. Mange Rails-applikasjoner bruker de samme edelstener til å gi spesifikke funksjoner; Dette kan ses som en fordel. Husk: Bred bruken oversetter til bred testing, så det regnes som en sikker praksis å bruke visse kjente perler for å oppnå viktige oppgaver. Her er noen eksempler:
Denne listen kan lett fortsette, men poenget er at Rails utnytter modulariteten til en Rubygems-basert tilnærming, og kan i stor grad øke utviklingen ved å plassere fokus på å bygge egenskaper som betyr noe for produktet du jobber med, i stedet for boilerplate.
Jeg kan fokusere på det som betyr noe for klienter uten å gå på kompromiss med god kodekvalitet.
For omtrent to år siden jobbet jeg i en markedsførings- / produktstyringsrolle (gjør webutvikling som en hobby); som betydde å fokusere på produktegenskaper, deres forretningsverdi og kostnaden forbundet med utviklingen. Da jeg bestemte meg for å bytte karriere, var Rails 3.0 nettopp blitt utgitt. Jeg tilbrakte en ettermiddag å se på videoer og lese opplæringsprogrammer. Jeg bestemte meg raskt for at Rails var det jeg ønsket å fokusere på min innsats på.
Årsaken - og dette noe overlapper det vi allerede har diskutert - er at jeg kunne se en praktisk tilnærming i framemork, et klart mål å være produktiv og fokusere på produktet og dets utvikling. Jeg kunne få ting gjort på kort tid. Etter noen få måneder med intensiv selvopplæring gjennom ulike nettopplæringsprogrammer og noen prøveapplikasjoner, søkte jeg om min nåværende jobb som Rails-utvikler ved New Bamboo.
Jeg liker å jobbe med Rails hver dag, fordi jeg kan fokusere på det som betyr noe for klienter uten å gå på kompromiss med god kodekvalitet. For meg er det det perfekte utgangspunktet for de fleste nettbaserte applikasjoner.
Det løser ikke alle problemene du vil møte, når du bygger store webapplikasjoner. Det er tider når du tydeligvis ser at Rails ikke passer for en bestemt type tjeneste, men det er på tide å dele arkitekturen i mindre applikasjoner.
Rails er et kraftig rammeverk som kan hjelpe deg med å bli mer produktive og selvsikker når du jobber med komplekse prosjekter. Dette er mulig, takket være dets sterke konvensjoner og solid struktur. Store selskaper, som 37 Signaler, Pivotal Labs, Groupon (eller til og med Twitter i gamle dager) har valgt Rails som grunnarkitektur for sine kjerneprogrammer. Det er en grunn til hvorfor!
Klar til å starte Riding Ruby on Rails?
