Lugu

Nii et teil ja teie partneril oli see suurepärane äriidee, eks?

Olete vaimselt süsteemi funktsionaalsuse lisanud.

Sageli küsite potentsiaalsetelt klientidelt, mida nad arvavad, ja neile kõigile meeldib.

veebirakendusest mobiilirakendusse

Okei, nii et inimesed tahavad seda. Tuleb isegi natuke raha teenida. Ja ainus põhjus, miks neil seda pole, on see, et te pole seda veel rakendanud.

Nii et istute lõpuks ühel päeval maha ja ütlete: 'Teeme seda!' Nii et proovite välja mõelda, kuidas rakendada oma rakenduse äriloogikat, tapjafunktsiooni, mis viib toote edasi: teil on idee, kuidas seda teha, ja tunnete teid saab tegema.

'Valmis! See töötab! ”, Ütlete te. Teie ideekontroll on edukas! Puudu on vaid veebirakenduse pakendamine.

'Ok, loome veebisaidi,' ütlete te.

Ja siis mõistate tõde: peate valima programmeerimiskeele; peate valima (kaasaegse) ​​platvormi; peate valima mõned (kaasaegsed) raamistikud; peate ostma (ja konfigureerima) salvestusruumi, andmebaase ja hostimise pakkujaid; vajate haldusliidest; vajate loasüsteemi; vajate sisuhaldurit.

Sa tahad, et see oleks kerge, sa tahaksid olla vilgas. Soovite kasutada tehnoloogiaid, mis aitavad teil lühemas ja pikas perspektiivis edu saavutada. Ja neid pole alati lihtne valida.

Teil on teha kümneid ja kümneid arhitektuurilisi otsuseid. Ja soovite teha õigeid otsuseid: soovite kasutada tehnoloogiaid, mis võimaldavad kiiret arengut, pidevat iteratsiooni, maksimaalset efektiivsust, kiirust, vastupidavust ja palju muud. Sa tahad, et see oleks kerge, sa tahaksid olla vilgas. Soovite kasutada tehnoloogiaid, mis aitavad teil lühemas ja pikas perspektiivis edu saavutada. Ja neid pole alati lihtne valida.

'Ma olen ülekoormatud,' ütlete, et tunnete end tõesti ülekoormatuna. Teie energia pole enam endine. Proovite tükid kokku panna, kuid see on liiga palju tööd.

Teie tõestus kontseptsioonist aeglaselt kuivab ja sureb.

Ettepanek

Olles ise lugematuid ideid hüljanud, otsustasin ehitada lahenduse. Ma nimetan seda projektiks Selles ’(Ou, init.js).

Idee keskne osa on kõigi nende käivitamiseks üks projekt, mis võimaldab arendajal või tehnilisel asutajal teha kõik need olulised otsused korraga ja saada mall nende otsuste põhjal asjakohane esialgne alus. Ma tean, mida halvustajad ütlevad: 'lahendust ei saa rakendada igasugustele probleemidele' (vihkajad vihkavad). Ja neil võib olla õigus. Kuid saame sobiva lahenduse loomiseks anda endast parima ja minu arvates on Init lähedal.

Selle eesmärgi paremaks saavutamiseks peame mõningaid ideid silmas pidama. Alguse väljatöötamisel kaalusin:

• Komponendid

  Komponentimine on iga süsteemi põhijoon, kuna see võimaldab tarkvara komponente taaskasutada erinevates projektides - mis on Initi peamine eesmärk. Kuid komponeerimisega kaasneb ka kõrvalprodukt, “asendatavus”, mis on meie parim liitlane mitme erineva probleemi lahendamisel peaaegu sama lahendusega.

• Arengu lihtsus

  Kas kellelgi on mõne probleemi jaoks parem lahendus sisse kirjutatud? Brainf * ck . Kuid selle lahenduse (Brainfuckis) rakendamist on praktiliselt võimatu kirjutada, rääkimata lugemisest. See maksab teile aega ja tohutut pingutust. Üldiselt peaksite kasutama keeli ja platvorme, mis muudavad teie (või kõigi, kes võivad sellega hiljem tegeleda) arendamise lihtsamaks, mitte raskemaks.

• Kogukond

  Ükskõik, millise platvormi valite, veenduge, et teil oleks suur kogukond ja mis aitaks teil kõige tavalisemate ja ebatavalisemate probleemide korral. Pidage meeles: jQuery ei pruugi olla teek kiiremini , puhtam või elegantsem - kuid see on võitja lihtsalt selle tõttu kogukond .

Neid eesmärke silmas pidades näitan teile, kuidas ma Initi loomisel oma otsuseid langetasin.

Oma keskmes kasutab Init ära “paradigmat” kogu virna JavaScripti ’Paradigma (mõned inimesed viitavad sellele või selle alamhulgale, näiteks TÄHENDA virna ). Sellise virnaga töötades on Initil võimalik kasutada ühte keelt, luues veebirakenduste arendamiseks uskumatult paindliku ja funktsioonirikka keskkonna. Lühidalt, see võimaldab teil kasutada JavaScripti mitte ainult kliendi ja serveri arendamiseks, vaid ka ehitamiseks, testimiseks, mallide loomiseks ja muuks.

Ent laseme hetkeks tempo maha ja küsime endalt: kas JavaScripti kasutamine on tõesti hea mõte?

Miks ma valisin JavaScripti

Olen veebiarendaja alates 1998. aastast. Seal kasutasime Perlit enamiku serveripoolse arenduse jaoks, kuid ka siis oli meil kliendi poolel JavaScripti. Sellest ajast alates on veebiserverite tehnoloogiad tohutult muutunud: oleme keelte ja tehnoloogiate, nagu PHP, ASP, JSP, .NET, Ruby, Python, laine laine järel edasi andnud, kui nimetada vaid mõnda. Arendajad hakkasid mõistma, et kliendi ja serverikeskkonna jaoks kahe erineva keele kasutamine on keeruline. Esimesed katsed ühineda ühe keele all olid suunatud serveris klientkomponentide loomisele ja JavaScripti jaoks kompileerimisele. See ei töötanud ootuspäraselt ja enamik projekte nurjus (näiteks: ASP MVC asendamine ASP.NET veebivormid , on GWT vaieldamatult asendatakse lähitulevikus Polümeer ). Kuid see oli suurepärane idee: üks keel kliendis ja serveris, mis võimaldab meil komponente ja ressursse taaskasutada (see on märksõna: ressursse ).

Vastus oli lihtne: paigutage JavaScript mitte server.

Tegelikult [sündis JavaScripti serveri poolel] (http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969) Netscape Enterprise Serveris, kuid keel polnud lihtsalt valmis Sel ajal. Pärast aastaid kestnud katseid ja vigu on Node.js lõpuks ilmnes, mis mitte ainult ei pannud JavaScripti serverisse, vaid edendas ka programmeerimise ideed mitteblokeeriv , muutes igaveseks viisi, kuidas kirjutame loetud “leiba” (I / O) siin rohkem teada).

Lauses: mitteblokeeriva programmeerimise eesmärk on aeganõudvad ülesanded kõrvale jätta, täpsustades üldiselt, mida tuleks nende ülesannete täitmisel teha, ja võimaldades protsessoril käsitseda muid taotlusi, kui seda ei toimu.

Kuid need ideed polnud uued - miks nad Node.js-i seas nii populaarseks said? Lihtsat ja mitteblokeerivat programmeerimist saab saavutada mitmel viisil. Võib-olla on kõige lihtsam tagasihelistuste ja a kasutamine sündmuse silmus . Enamikus keeltes pole see lihtne ülesanne: kui tagasihelistamine on teistes keeltes tavaline omadus, siis sündmuste silmus seda ei tee ja sageli leiate end vaeva väliste teekidega (näiteks: Python, koos Twister ). Kuid JavaScripti abil tagasihelistamised need on sisse ehitatud keelde, täpselt nagu sündmuste aasad, ja peaaegu iga JavaScripti puudutanud programmeerija on nendega tuttav (või vähemalt kasutanud neid, isegi kui ei saa tegelikult aru, mis on sündmuse silmus ). Järsku võib iga Maa käivitamine taaskasutada arendajaid (st ressursse) nii kliendi kui ka serveri poolel, tööpakkumise probleem : 'Otsime Guru Pythonis'.

Järsku võiks iga Maa idufirma arendajaid (st ressursse) taaskasutada nii kliendi kui ka serveri poolel, lahendades tööpakkumise probleemi: „Otsime Pythoni gurut”.

Nii et nüüd on meil uskumatult kiire platvorm (tänu blokeerimata programmeerimisele) programmeerimiskeelega, mida on uskumatult lihtne kasutada (tänu JavaScriptile). Kuid kas sellest piisab? Kestab? Olen kindel, et JavaScriptil on tulevikus oluline koht. Lubage mul öelda, miks:

• Funktsionaalne programmeerimine

  JavaScript oli esimene programmeerimiskeel tuua funktsionaalne programmeerimisparadigma masside jaoks (muidugi oli Lisp esikohal, kuid enamik programmeerijaid ei ehitanud kunagi rakendusi tootmiskeskkondadesse, kasutades Lispi). Lisp ja mina, Javascripti peamised mõjud , on täis uuenduslikke ideid. Need ideed võiksid vabastada meie mõtted uute tehnikate, mustrite ja paradigmade uurimiseks. Ja nad kõik kasutavad JavaScripti. Heitke pilk peale monaadid , Kiriku numbrid või isegi (reaalsema näite jaoks) funktsioonid kogudest tegema Allakriips.js , mis võib säästa ridu ja koodiridu.

• Dünaamilised objektid ja prototüübi pärand

  aws sertifitseeritud lahenduste arhitekt – kaastöötaja

  Klassideta objektile orienteeritud programmeerimine (ja pole lõputut klasside hierarhiat) võimaldab kiiret arengut (objektide loomine, meetodite lisamine ja kasutamine), kuid mis veelgi olulisem, vähendab hooldustööde ajal refrakteerimisaega, lubades programmeerijal klasside asemel objektide eksemplare muuta. See kiirus ja paindlikkus sillutab teed kiirele arengule.

• JavaScript on Internet

  JavaScript oli mõeldud Interneti jaoks , on siin olnud algusest peale ja ei kao kuhugi . Kõik katsed seda hävitada on ebaõnnestunud: vaadake näiteks Java aplettid , asendades VBScript väärtusega Microsofti TypeScript (mis kompileerib JavaScripti jaoks) ning Flashi surm mobiilsete ja HTML5-turgude käes. JavaScripti asendamine ilma miljoneid veebilehti lõhkumata on võimatu, seega peaks meie eesmärk olema selle täiustamine. Ja selle töö jaoks pole kedagi paremat Tehniline komitee 39 ECMA-le.

  Okei, JavaScripti alternatiivid sünnivad iga päev, näiteks CoffeeScript , TypeScript ja nagu miljoneid JavaScripti jaoks koostatavaid keeli . Need alternatiivid võivad olla kasulikud arenguetappide jaoks ( allikakaartide kaudu ), kuid pikas perspektiivis ei suuda nad JavaScripti asendada kahel põhjusel: nende kogukonnad ei ole kunagi suuremad ja nende parimad omadused võtab kasutusele ECMA skript (st JavaScript). JavaScript ei ole assamblee keel: see on teie jaoks mõistetava lähtekoodiga kõrgetasemeline programmeerimiskeel - nii et peaksite sellest aru saama.

Nüüd tänu Esprima projekt , saate luua oma tööriistad lähtekoodiga mängimiseks, seda muuta, muuta selle stiili, lisada komponente, instrumenti ja igasuguseid asju, mida võite ette kujutada, mängides oma programmi abstraktse süntaksipuu abil, justkui töötasid DOM-puuga.

Otsast lõpuni JavaScript: Node.js ja MongoDB

Nii on need JavaScripti kasutamise põhjused. Nüüd kasutan JavaScripti põhjusena Node.js ja MongoDB kasutamiseks.

• Node.js

  Node.js on platvorm kiirete ja skaleeritavate võrgurakenduste loomiseks - see on üsna palju, mida Node.js veebisait ütleb. Kuid Node.js on sellest olulisem: see on eelistatud käituskeskkond kõigi JavaScripti rakenduste jaoks, millel on juurdepääs I / O-le. Isegi kui te ei kavatse oma põhiserverirakendust Node.js-iga kirjutada, võite oma arendusprotsessi parandamiseks kasutada Node.js-i peale ehitatud tööriistu. Näiteks: Mocha.js üksuse testimiseks, Grunt.js automatiseeritud koostamisülesannete jaoks või isegi Sulgudes toimetamiseks täistekst koodi.

  Seega, kui kavatsete kirjutada JavaScripti rakendusi serverile või kliendile, peaksite Node.js-iga tundma õppima, sest peate seda iga päev kasutama. On huvitavaid alternatiivid , kuid ükski neist ei jõua isegi 10% -ni Node.js. kogukonnast.

• MongoDB

  MongoDB see on andmebaas NoSQL põhineb dokumentidel, mis kasutavad päringukeelena JavaScripti, võimaldades mul täiendada platvormi otsast lõpuni JavaScripti abil.

  MongoDB on a skeemita andmebaas mis võimaldab teil objekte paindlikult säilitada ja seetõttu muutuvate nõuetega kiiremini kohaneda. Veelgi enam, see on väga skaleeritav on põhineb kaardil vähendamisel , mis muudab selle sobivaks suurandmete rakenduste jaoks. MongoDB on nii paindlik, et seda saab kasutada skeemivaba andmebaasina, relatsioonide salvestusruumina (kuigi see ei toeta tehingud ) või isegi vastuste vahemällu salvestamise võtmeväärtuste salvestusena.

Serveri komponeerimine teenusega Express.js

Serveripoolne komponentimine pole kunagi lihtne. Aga koos Express.js (ja Connect.js) tekkis ‘vahevara’ idee. Minu arvates on vahetarkvara parim viis serveris komponentide määratlemiseks. Kui soovite võrrelda tuntud standardiga, on see torude ja filtrite lähedal.

Põhiidee on see, et teie komponent on osa torustikust (toru). Torujuhe töötleb päringut (sissetulev) ja genereerib vastuse (väljaminev), kuid selle komponent ei vastuta kogu vastuse eest. Selle asemel muudab ta lihtsalt seda, mida ta vajab, ja seejärel delegeerib selle torujuhtme järgmisse ossa. Kui torujuhtme viimane osa on töötlemise lõpetanud, saadetakse vastus kliendile tagasi.

Nimetame neid 'torujuhtme tükke' (torutükki) kui 'vahevara'. On selge, et saame luua kahte tüüpi vahevara:

• Vahendajad : need, kes töötlevad päringut ja vastust, kuid ei vastuta täielikult vastuse eest, delegeerivad seejärel järgmise vahevara juurde.

• Finaalid : need, kes vastutavad lõpliku vastuse eest täielikult. Nad töötlevad ja muudavad päringut ja vastust, kuid ei pea delegeerima järgmisele vahevara. Praktikas on arhitektuurse paindlikkuse võimaldamiseks soovitatav ikkagi delegeerida järgmisele vahevara (see tähendab, et lisage hiljem rohkem vahevara), isegi kui seda vahevara pole olemas (nii et sel juhul läheb vastus otse kliendile).

Konkreetse näitena käsitleme serveris komponenti „kasutaja haldamine”. Vahevara osas oleks meil nii lõpp-punkte kui ka vahendajaid. Lõpuks on meil sellised funktsioonid nagu kasutaja loomine ja kasutajate loendamine. Kuid enne selliste toimingute tegemist vajame autentimiseks oma vahendajaid (kuna me ei soovi kasutajate sisestamist ja loomist autoriseerimata taotlustega). Kui need autentimisvahendajad on loodud, võime need lihtsalt ühendada kõikjal, kus soovime varem autentimata funktsiooni autentitud funktsiooniks muuta.

Ühe lehe rakendused

Projekt Init keskendub loomisele ühe lehega rakendused (SPA: ühe lehe rakendus) . Enamikku veebiarendajaid on meelitatud proovima kasutada SPA-sid. Ehitasin mitu (enamasti varalisi) ja võin veendunult öelda, et need on lihtsalt veebirakenduste tulevik. Kas olete kunagi võrrelnud SPA-d mobiilside kaudu traditsioonilise veebirakendusega? Reaktsiooniaja erinevus on kümnetes sekundites.

Kas olete kunagi võrrelnud SPA-d mobiilside kaudu traditsioonilise veebirakendusega? Reaktsiooniaja erinevus on kümnetes sekundites.

SPA-d on veebi tulevik - miks te siis oma toodet pärandina ehitaksite? Levinud argument, mida kuulen, on see, et inimesed on seotud SEO-ga (otsingumootorite optimeerimine, otsingumootorite optimeerimine). Kui aga asju õigesti käsitleda, ei tohiks see probleem olla: Google'il endal on väga hea õpetus kuidas seda teha ja on mõned head kommentaarid siin ka.

MV * kliendipoolel koos Backbone.js, Marionette.js ja Twitter Bootstrapiga

Palju on räägitud raamid MVC * para SPA's . See on keeruline valik, kuid ma ütleksin, et 3 parimat on Backbone.js , Ember.js , on Angular.js .

Kõiki kolme hinnatakse hästi. Kuid milline neist on teie jaoks parim?

Kahjuks pean tunnistama, et mul on Angular.js-iga väga piiratud kogemus, nii et jätan teid sellest arutelust välja. Nüüd esindavad Ember.js ja Backbone.js kahte erinevat viisi sama probleemi ründamiseks.

Backbone.js see on minimalistlik, lihtsustatud ja pakub teile piisavalt lihtsa SPA loomiseks. Ember.js seevastu on SPA-de loomiseks täielik ja professionaalne raamistik. Sellel on rohkem atraktsioone, kuid ka pikem õppimiskõver.

Sõltuvalt teie rakenduse suurusest võib otsus olla sama lihtne kui analüüsida kasutatud funktsioonide määra võrreldes võimalike funktsioonidega, mis annab teile hea idee.

Initi puhul tahtsin kajastada enamikku stsenaariume, seega valisin SPA-de hõlpsaks loomiseks Backbone.js koos komponendiga Backbone.Marionette.View. Nii on iga komponent lihtne rakendus ja lõplik rakendus võib olla nii keeruline kui soovime.

Ka stiil on väljakutse, kuid võime jällegi tugineda raamistikele, mis meid aitavad. CSS-i jaoks pole midagi paremat kui Twitteri alglaadimine , mis pakub täielikku kasutusvalmis stiilide komplekti ja lihtne kohandada .

Bootstrap loodi keelt kasutades VÄHEM ja see on tasuta tarkvara, nii et saame seda vajadusel muuta. Kaasas on arvukalt kasutajaliidese juhtnuppe hästi dokumenteeritud Bootstrapi veebisaidil . PE veel on olemas kohandamismudel mis võimaldab teil luua oma Bootstrapi. Ta on kindlasti selle töö jaoks õige tüüp.

Parimad tavad: Grunt.js, Mocha.js, Chai.js, RequireJS ja CoverJS

Lõpuks peaksime määratlema mõned oma parimad tavad ja nägema, kuidas Init aitab teil neid juurutada ja hooldada. Meie lahendus on keskendunud mitmele tööriistale, mis omakorda põhinevad Node.js-l.

• Mocha.js on Chai.js :

  Need tööriistad võimaldavad teil rakendamise abil oma arenguprotsessi parandada TDD või BDD , pakkudes infrastruktuuri oma üksuste testide korraldamiseks ja testamenditäitja nende automaatseks käitamiseks.

  Seal on tuhandeid raamistikud JavaScripti ühikute testimiseks. Miks siis kasutada Mocha.js? Lühike vastus: see on paindlik ja täielik.

  Pikk vastus: sellel on kaks olulist omadust (liidesed, reporterid) ja oluline puudumine: väited. Las ma selgitan.

  • Liidesed : Võib-olla olete tuttav TDD mõistetega, nagu komplektid ja ühikutestid, või eelistate BDD käitumise spetsifikatsiooni ideid sõnadega 'kirjeldada' ja 'peaks' Mocha.js võimaldab teil kasutada mõlemat lähenemist.

  • Reporterid : Testi käivitamisel luuakse tulemuste aruanded ja saate neid vormindada mitme reporteri abil. Näiteks kui teil on vaja pideva integreerimise serveri toiteallikat, võite leida reporteri just selleks.

  • Väidete raamatukogu puudumine : kaugeltki pole probleem, Mocha.js loodi selleks, et saaksite kasutada teie valitud väidete kogu, andes teile veelgi suurema paindlikkuse. Seal on rikkalikud valikud , kuid siin siseneb väljale Chai.js.

  Chai.js on paindlik väitekogu, mis võimaldab teil valida kolme peamise väite stiili vahel:

  • Kinnitada : Klassikalise TDD ioonide väite klassikaline stiil. Näide:

    assert.equal(variavel, 'valor');

  • Oodata : Aheldatav väitmisstiil, mida kasutatakse kõige sagedamini BDD-s. Näide:

    expect(variavel).to.equal ('valor');

  • Peaks : Kasutatakse ka BDD-s, kuid ma eelistan seda oodata, kuna see peaks kõlama korduvalt käitumisspetsifikatsiooniga ‘it („ peaks midagi tegema .. “)’. Näide:

    variavel.should.equal ('valor');

  Chai.js sobib suurepäraselt Mocha.js-iga. Ainult nende kolme teegi abil saate testid kirjutada TDD, BDD või mis tahes mõeldavas stiilis.

• Grunt.js :

  Grunt.js võimaldab teil automatiseerida koostamisülesandeid, alates lihtsast kopeerimisest ja kleepimisest ning failide liitmisest kuni mallide eelkompileerimiseni, stiilikeele kompileerimiseni (st SASS ja LESS), üksuste testimiseni (koos mocha.js-iga), kiilumisega ja koodiga minimeerimine (näiteks UglifyJS või Sulgemise koostaja ). Võite lisada oma automatiseeritud ülesande Gruntile või otsida Grunti register ,, kus on saadaval sadu ja sadu pistikprogramme (pidage meeles: tööriistade kasutamine, mille taga on suured kogukonnad, tasub end ära). Grunt saab ka jälgida oma faile ja käivitavad toimingud, kui neid muudetakse.

• NõuaJS :

  RequireJS võib tunduda veel üks moodulite laadimise viis AMD , kuid võin teile kinnitada, et see on palju enamat. Selle mõistmiseks peame kõigepealt mainima mooduli nimeruumi ideed (näiteks demo.views.hello), mis väldib globaalse nimeruumi saastamist, pakkides iga mooduli oma nimeruumi. Probleem on selles, et neid mooduleid ei saa uuesti kasutada: kui muudate „eksemplari” nimeruumi, muudate kõigi „eksemplaride” nimeruumi. Vastupidiselt sellele võimaldab RequireJS määratleda algusest peale korduvkasutatavad moodulid. Lisaks aitab see teil lapsendada Sõltuvuse süstimine jaoks vältige oma moodulite juurdepääsu globaalsetele muutujatele .)

• CoverJS :

  Koodi katvus on teie testide hindamise mõõdik. Nagu nimigi ütleb, ütleb see teile, kui suure osa teie koodist katab praegune testikomplekt. CoverJS mõõdab teie testide koodikatvust instrumentide abil (koodiridade asemel JSCülekanne ) oma koodis ja genereerides oma koodi instrumenteeritud versiooni. Samuti saate oma serveri toitmiseks luua aruandeid Pidev integratsioon .

Funktsioonide valimiseks filiaalide kasutamine

Initiga alustades vajasin kasutajatele võimalust aktiveerida ja deaktiveerida mitmesuguseid funktsioone, mida nad oma projektides soovida võivad. Otsustasin teha selle funktsionaalsuse rakendamiseks radikaalse sammu, kasutades giti harusüsteemi.

Põhimõtteliselt esindab iga haru funktsiooni või funktsionaalsust, mida kasutaja võib soovida lisada. Kui alustate projekti nullist, alustage minimaalsest harust, mida vajate, ja lisage seejärel muud tehnoloogiad, ühendades soovitud harud. Oletame näiteks, et soovite oma projekti alustada Backbone.js ja Marionette.js. Noh, võite alustada haruga Backbone.js ja liita selle Marionette'i haruga, jätkates iga lisatava funktsionaalsuse kohta.

Praegu saab seda funktsionaalsuse lisamiseks mõeldud ühendamise ideed kasutada ainult tehnoloogiliste mallide jaoks (näiteks selgroog, sõlm, Express). Kuid tulevikus saate vahetada tagarakenduste (näiteks MongoDB-lt Postgresile) ja kliendi vahel.

Alustage projekti Initiga ja juurutage Heroku Today

Projekti alustamiseks pole kunagi varem olnud lihtsamat viisi. Lihtsalt minge GitHubi hoidla , kontrollige haru viimaste toimingutega (see on kasutajanimi, kuigi see võib tulevikus muutuda) ja seejärel:

1. Looge oma projekti jaoks kataloog (või kasutage olemasolevat).
2. Looge oma hoidla 'git init' abil (või kasutage olemasolevat hoidlat).

3. Lisage initiga pult

   git remote add init git://github.com/picanteverde/init.git

4. Laadige alla Heroku protsessifail

   kuidas leida nõustavaid kliente

   git pull init usermanager

5. Kui Heroku tööriistavöö on installitud, looge Heroku rakendus

   git pull init heroku-webprocess

6. Meeldib Heroku tööriistavöö installitud, looge Heroku rakendus

   heroku create

7. Lükake oma põhiharu Herokule

   git push heroku master
8. Külastage oma rakendust, mis töötab Herokul!

Nüüd saate tapjafunktsiooni välja töötada vaid mõne koodirea abil. Vähe sellest, vaid arendate kõige uuemate ja tõhusamate tehnoloogiate abil nii automatiseeritud arenduskomplektis kui võimalik.

Loodan, et saate seda kasutada Selles oma järgmise suure idee alustamiseks. Ärge unustage, et kontrolliksite, kas Initis on uusi parandusi ja funktsioone - selle arendamine on väga aktiivne ja ootan teie kommentaare.

Sisu on tõlkinud Eduardo Kienetz Transbrunko , tehniliste tõlgete turg.