Kujutise allikas: pixabay.com

Enne kui ma siin Rails (Ruby) ja PHP-d kasutavate inimeste vahel sõda alustan, lubage mul öelda, et ma ei ole siin, et arutada, milline keel on parem. Minu või mõne kogenud programmeerija jaoks oleks kumbki sama. See on lihtsalt tõenäosus, kas keegi eelistab ja mis on nende jaoks lihtne.

Selles blogis arutaksin enamasti mõlema olulisuse ja nende erinevuse üle. Niisiis, kui te pole uus nii Rails kui ka PHP, siis võib see olla teie jaoks ideaalne ajaveeb, kui soovite ühe neist kahest valida. Alustame siis. Kas peame?

Mõned põhitaustad

Alustuseks on PHP skriptikeel, RAILS aga veebiarenduse raamistik, mis põhineb skriptikeeles Ruby. PHP on laialdaselt kasutatav programmeerimiskeel selliste veebisaitide jaoks nagu Facebook, WordPress, Yahoo, Flickr ja veelgi enam. PHP on äärmiselt kiire, n korda stabiilsem kui Rails ja isegi seda toetab suurem arendajate kogukond.

Rails põhineb täielikult rubiinil. Seda on äärmiselt lihtne kasutada ja sellega alustada. Ruby keskkond on väga automatiseeritud. Ruby on tõesti üsna hämmastav keel. Erinevalt PHP-st on see tegelikult objektorienteeritud juba algusest peale. Selle kood on väga lühike ja võimas. Vääriskivid (pikendused) võimaldavad teil vajalike funktsioonide külge kinnitada. Pärast kodeerimist Ruby's on kodeerimine PHP-s üsna tüütu.

Hea halb ja kole

  1. PHP

Minu nõuanne on PHP, kuna PHP kasutamine põhitasandil on väga lihtne, on seal palju inimesi, kes teavad mõnda mallikoodi kopeerida / kleepida, konfiguratsioonifaile modifitseerida ja nad võivad isegi nimetada end PHP programmeerijaks, mis annab PHP-le väga halb nimi, mida ma ei usu, et see väärib.

Tõelise programmeerija jaoks pole tegelikult oluline, millist keelt ta kasutab, tähtis on see, mida ta kodeerib ja kuidas ta kodeerib. Pärast mõne programmeerimiskeele õppimist saate aru, et enamik neist on tegelikult väga sarnased, tavaliselt on süntaks erinev (eriti nende põhimehhanismis, isegi erineva programmeerimisparadigma jaoks).

Kõigepealt peaksite õppima puhta ja loetava koodi kirjutamist ning mitte liiga keeruka koodi kirjutamist, kuna seda on keerulisem siluda ja see on segane inimestega, kes ei oska keele erilisi trikke (PHP-ga saate teha igasugu keerulisi trikke kraam, mitte kõik pole teistele programmeerijatele ilmne).

Võrreldes PHP-ga on Rails ka vigade osas ebasõbralik. PHP-ga sülitab see teie arenduses olevad vead välja ja tõrketeated on tegelikult mõistlikud. Tavaliselt renderdatakse leht, kuid tõrkega osa näitab teile, millisel real viga ilmnes ja sõnum on kasulik. Railsis puhub tavaliselt kogu rakendus.

Mul on kahju siin inimesi solvata, kuid Ruby pole lihtsalt nii sirgjooneline kui PHP. See on kõigil eesmärkidel äärmiselt võimas keel. Ma valin Ruby kasutamise lihtsalt seetõttu, et arendajana tunnen, et see on palju parem keel kui PHP. Kuid õppimise seisukohast see pole nii. Rubiinil on palju funktsioone, mis algajale programmeerijale pole lihtsalt arusaadavad. Üheks selliseks kontseptsiooniks on plokid, sondid ja lambad, mida Rails kasutab palju.

Klassikaline näide Ruby on Rails, mida ma kasutan, on vormi loomine:

  1. Rööpad

Ruby on dünaamiline, hädavajalik objektorienteeritud programmeerimine. See on dünaamiliselt trükitud, nagu ka PHP-s, nii et te ei pea muretsema muutujate deklareerimise pärast. Rails on avatud lähtekoodiga, töötab mitmel platvormil ja selle saab manustada hüperteksti märgistuskeelde. See on väga kõrge tasemega keel. See pakub isegi andmemeetodite kapseldamist objektidesse.

Rubiinil on ülitäpsed stringi ja tekstiga manipuleerimise tehnikaid saab hõlpsasti ühendada DB2, MySQL, Oracle ja Sybase'iga. Ruby keeles kirjutatud suuri programme saab hõlpsasti hooldada. Sellel on puhas ja lihtne süntaks, mis võimaldab uutel arendajatel õppida Rubiini väga kiiresti ja hõlpsalt. Sellel pole mitte ainult võime kirjutada mitme keermega rakendusi lihtsa API abil, vaid see pakub ka arenenud massiiviklassi ja võimalust kirjutada väliseid raamatukogusid Ruby või C-s.

Ruby Võimaldab identifikaatorina kasutada „reserveeritud sõna” seni, kuni parsija ei taju mitmetähenduslikkust. Võrreldes PHP-ga on Ruby'l palju turvafunktsioone ja võimas stringihaldus.

Niisiis, kümnendi küsimus on … Kas kõigi nende funktsioonide abil muudab see Ruby PHP-ga võrreldes paremaks?

Kahjuks pole see nii mustvalge ja paljud muutujad võetakse arvesse, kui otsustatakse, kas arendamiseks tuleks kasutada PHP-d või rubiini rööbastel.

Näiteks on Ruby on Rails arengukeskkonna seadistamiseks palju keerulisem keel. Järelikult tõstab Ruby jaoks vajalikud vaikivad teadmised programmeerimisturul PHP-arenguga võrreldes kohe hinna üles. Teisest küljest saab PHP arendaja kasutada tavalist paketti, näiteks WAMP, MAMP, et saada nende dev-keskkonna seadistamine vähem kui 5 minutiga.

Kui ma Ruby'is kodeerima hakkasin, ajasid kalliskivid mind segamini, kui nad aitasid, sest maagiat oli liiga palju. Kui ma sain teada, et võiksite (ja peaksite) lihtsalt kalliskivide lähtekoodi lugema, oli kõik palju mõistlikum. Vääriskivide ühendatava olemuse ja kogukonna standardite tõttu võivad kalliskivid anda teie rakendusele väga kiiresti tohutu funktsionaalsuse.

Mõned kalliskivid, milleta ma ei ela: Devise (autentimine - tegeleb kasutajate sisselogimisega, sotsiaalse sisselogimisega, unusta paroolivoogud ja palju muud), kirjaklamber (failide üleslaadimine - isegi käepidemete üleslaadimine S3-le, piltide kärpimine / uuesti proovivõtmine), lihtne Vorm muudab vorme veebisaitidel standardiseerimiseks ja renderdamiseks uskumatult lihtsaks.

PHP loodi hüperteksti eeltöötlejana, mis tähendab, et see käivitatakse ainult veebipäringu olemasolul. Võrreldes protsessi käivitava Ruby'ga. Railsis saate taustatöid hõlpsalt seadistada, kasutades Sidekiqi või Resque'i. See lisab ka Rail'i võimele hõlpsasti skaleerida. Oma rakendustes liigutame palju asju, mis võivad aeglustada taotlusi, näiteks kasutajate e-kirjade saatmine tausttöödele.

Nüüd saab PHP Gearmani abil teha taustatöid, kuid see pole standarditud - peate installima PECL-i laienduse. Rakenduses Ruby / Rails pole tausttööga seotud probleemid. Sa lihtsalt teed seda.

Sõja puksiir

Nüüd, kui olete PHP ja Rails kohta palju lugenud, laske neil neid võrrelda. Kontrollime, milline neist on ressursside kasutamise ja isegi jõudluse (kiiruse) osas võrdne.

Soovitatavad kursused

  • Veebisertifitseerimise kursus Java talveunerežiimis
  • Programm Java Kevadel
  • WordPressi atesteerimiskursus
  • Rubiini kursus

Ressursi kasutamine ja kiirus

Mälukasutuse osas saab sellest üldjuhul Python> Ruby> PHP, mis muidugi viib Django> Rails> PHP-ni. Mitte ainult mälu, vaid see kipub olema ka toores rubiin rööbastel vs php jõudlus. Siinkohal väärib märkimist ka see, et muidugi pole siin absoluute. On palju kasutusstsenaariume, kus Ruby lööb Pythoni käed alla. Ma arvan, et võime kõik nõustuda, et Ruby ja Python võidavad PHP-d alati.

Minu enda kogemus on see, et Railssi mälukasutus võib olla suur, eriti 64-bitistel masinatel (minimaalne on umbes 95–100 MB, nii õhuke kui veebi esiosa). PHP-d kiputakse kasutama erinevate mustritega, nii et seda on pisut keeruline otse võrrelda.

Nagu öeldud, on ikka väga lihtne teha jubedat, aeglast ja ebaefektiivset Django rakendust ning lahjat, kiiret ja tõhusat Rails rakendust või vastupidi. Kasutatava süsteemi oskus, teadmised ja teadmised annavad selle mälu ja jõudluse jaoks palju rohkem kui lihtsalt raamistik ise.

Andmebaaside optimeerimine, serverivalikud ja arhitektuurid (Apache vs puhverserveri seadistused, kasutades nginx / lighttpd jne) ning põhimõttelised kujundusotsused katavad tõenäoliselt raamistiku loomupärased omadused üsna kiiresti.

Kui juhite Ruby ja teiste keelte vahel tüüpilisi võrdlusnäitajaid, siis Ruby kaotab. Ruby ei teeniks teid tõenäoliselt reaalajas digitaalse signaali töötlemise rakenduse või mis tahes reaalajas juhtimissüsteemi kirjutamisel. Ruby (koos tänaste VM-idega) lämbuks tõenäoliselt ressurssidega piiratud arvutis, näiteks nutitelefonides.

Pidage meeles, et suurt osa teie veebirakenduste töötlemisest teeb tegelikult C-s välja töötatud tarkvara, nt Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, paljud parsimisraamatukogud, RMagick, TCP / IP jne on C-programmid, mida kasutab Rubiin. Ruby pakub liimi ja äriloogikat.

Küsimus on “MIKS siis PHP?”

Nüüd saab rääkida PHP-st. PHP töötab apache-serveris eriti aeglaselt. Isegi kui proovite PHP-lehte käitada ka ilma skriptideta, lihtsalt tühja php-lehena, võtab JSP-de või Java-versioonidega laadimine siiski kümme korda rohkem aega. Kuid jällegi on miljoni sajandi küsimus selles, et kui see on nii, siis miks pole Facebook veel PHP-d kraavitanud? Põhjus, miks Facebook pole PHP-st eemaldunud, on sellepärast, et Facebooki insenerid on suutnud lahendada paljud selle vead, kasutades täppide kombinatsiooni kõikidel virnade tasemetel ja suurepärast sisemist distsipliini koodikonventsiooni ja stiili kaudu.

Keele halvimaid atribuute välditakse ja kodeerimisstiili jõustatakse üsna tiheda koodide ülevaatuse kultuuri kaudu (stiilist kinnipidamine ja lohvakoodi kirjutamisega “kauboi minek” põhjustab kaaslaste haletsusväärset pilkamist). Insenerijuhtimine pole kunagi pidanud siin tugevat kätt võtma; see tekkis suuresti tänu sisemistele tehnilistele juhtidele, kes just nagu kõik teisedki kaasa tõmbasid.

Ja Facebook ei kasuta muidugi ainult PHP-d. Selle tuumaks on ka C ++. Niisiis, PHP jaoks kasutage mingit opoodikoodide vahemälu, näiteks APC või eAccelerator, vastasel juhul peab PHP iga faili teie faile parsima. Apache üldiseks häälestamiseks peaksite tegema natuke googeldamist, tuleb meelde paar asja, näiteks .htaccess-failide keelamine, kuid see peaks siiski olema kiirem kui JSP.

Järeldus

Nii et lõpuks arvan, et ütlen, et kui läbite Rails, siis peaksite Railsist läbi jääma, kui te ei plaani käivitada tervet uut PHP-l põhinevat projekti ja asutada sellega koos ettevõte.

Soovitatavad artiklid

Siin on mõned artiklid, mis aitavad teil Rails vs PHP kohta rohkem üksikasju saada, nii et minge lihtsalt lingi kaudu.

  1. Hämmastav juhend Learn Rails arendamise kohta
  2. Ruby vs Ruby On Rails- kumb on parem?
  3. Ruby vs PHP - milline tehnoloogia on parim?
  4. Kümme parimat kõige ägedamat PHP-intervjuu küsimust kogenutele

Kategooria:

Tarkvaraarendus