Historia

Joten sinulla ja perustajillasi on tämä hieno liikeidea, eikö?

Olet lisännyt ominaisuuksia päähäsi.

Kysyt usein potentiaalisilta asiakkailta heidän mielipiteitään, ja he kaikki rakastavat sitä.

Ok, niin ihmiset haluavat sitä. On jopa vähän rahaa ansaita. Ja ainoa syy, miksi he eivät voi saada sitä, on se, että et ole vielä toteuttanut niitä.

Sitten istut yhden päivän ja sanot 'Teemme sen!' Pian yrität selvittää, miten voit soveltaa sovelluksesi liiketoimintalogiikkaa, tappajatoimintoa, joka ajaa tuotetta eteenpäin - sinulla on idea, miten se tehdään, ja nyt tiedät, että voit tehdä sen.

'Valmis! Se toimii!' sinä sanot. Todiste konseptistasi on menestys! Ainoa mitä on jäljellä on pakata se verkkosovellukseen.

'Ok, tehdään sivusto', sanot.

Ja sitten huomaat totuuden: sinun on valittava ohjelmointikieli; sinun on valittava alusta (moderni); sinun on valittava joitain (moderneja) kehyksiä; sinun on määritettävä (ja ostettava) tilaa, tietokantaa ja isännöintipalveluja; tarvitset hallintaliittymän; tarvitset lupajärjestelmän; tarvitset sisällönhallinnan.

Haluat olla ytimekäs, haluat olla ketterä. Haluat käyttää tekniikoita, jotka auttavat sinua menestymään lyhyellä ja pitkällä aikavälillä. Ja niitä ei ole aina helppo valita

Sinulla on kymmeniä ja kymmeniä arkkitehtonisia päätöksiä. Ja haluat valita oikeat: haluat käyttää tekniikoita, jotka mahdollistavat nopean kehityksen, jatkuvan iteroinnin, maksimaalisen tehokkuuden, nopeuden, kestävyyden ja paljon muuta. Haluat olla ytimekäs, haluat olla ketterä. Haluat käyttää tekniikoita, jotka auttavat sinua menestymään lyhyellä ja pitkällä aikavälillä. Ja niitä ei ole aina helppo valita.

'Olen hukkua', sanot, kun menet pois ylikuormitettuna. Energiasi ei ole sama kuin ennen. Yrität sovittaa palat yhteen, mutta se on liikaa työtä.

Todiste käsitteestä kuihtuu ja kuolee hitaasti.

Ehdotus

Hylkääni tällä tavoin tonnia ideoita päätin suunnitella ratkaisun. Kutsun sitä projektiksi Sen sisällä '(Koti) (tai init.js).

Idean ydin on saada yksi projekti, joka käynnistää kaikki muut, antaa kehittäjän tai teknisen perustajan tehdä nämä päätökset samanaikaisesti ja saada asianmukainen malli aloittaakseen päätösten perusteella. Tiedän, mitä sanomattomat sanovat: 'Yksi ratkaisu ei sovi kaikkiin ongelmiin' (Haters vihaa). Ja he voivat olla oikeassa. Mutta voimme yrittää parhaamme mukaan luoda karkean ratkaisun, ja luulen Sen sisällä on tarpeeksi lähellä.

Tämän tavoitteen saavuttamiseksi meidän on pidettävä mielessä muutama keskeinen idea. Kun kehitin Initia, ajattelin:

• Komponentit

  Modulaatio on minkä tahansa järjestelmän keskeinen piirre, koska sen avulla voit käyttää ohjelmistokomponentteja uudelleen eri projekteissa - mikä on Sen sisällä . Mutta modulaarisuuteen liittyy myös 'korvattavuus' tuotteittain, mikä on paras liittolainen, kun on kyse hyökkäyksistä erityyppisiin ongelmiin 'melkein' samalla ratkaisulla.

• Kehityksen helppous

  Joihinkin ongelmiin joskus on kirjoitettu parempi ratkaisu [Brainf * ck] (https://fi.wikipedia.org/wiki/Brainfuck). tai vittu aivot). Mutta toteuta tuo ratkaisu (vuonna Brainf * uck ) olisi lähes mahdotonta kirjoittaa, saati lukea. Se maksaisi aikaa ja valtavasti vaivaa. Yleensä sinun tulee käyttää kieliä ja alustoja, jotka tekevät kehityksestä helppoa eikä vaikeaa sinulle (tai jollekin, joka voi työskennellä sen kanssa myöhemmin).

• Yhteisö

  Minkä tahansa alustan valitsetkin, varmista, että sillä on loistava yhteisö ja sellainen, joka voi auttaa sinua yleisimmissä ongelmissa ja niissä, jotka eivät ole niin yleisiä. Muista: jQuery ei ehkä ole eniten nopea , eniten puhdas , tai fanciest - mutta se on voittaja vain sen takia Yhteisö .

Näiden tavoitteiden mielessä aion näyttää sinulle, kuinka tein omat päätökseni luodessani Sen sisällä .

Ytimessä Init käyttää hyväkseen koko pino JavaScript '(Jotkut ihmiset viittaavat häneen tai hänen osaansa TÄRKE pino ). Kun työskentelet tämän sarjan kanssa, Sen sisällä se pystyy käyttämään vain yhtä kieltä ja samalla luomaan uskomattoman joustavan ja monipuolisen ympäristön verkkosovellusten kehittämiseksi. Yhteenvetona, Sen sisällä antaa sinun käyttää JavaScriptiä paitsi asiakas- ja palvelinpuolen kehitykseen myös rakennukseen, testaukseen, asetteluun ja muuhun.

Hidastetaan kuitenkin vähän ja kysytään itseltämme: onko JavaScript todella hyvä idea?

Miksi valitsin JavaScriptin

Olen ollut web-kehittäjä vuodesta 1998 lähtien. Tuolloin käytimme Perl suurimman osan palvelinpuolen kehityksestämme, ja jo silloin meillä oli asiakaspuolen JavaScript. Palvelinpuolen verkkotekniikat ovat muuttuneet siitä lähtien valtavasti - käytiin läpi aallon toisensa jälkeen erilaisia ​​tekniikoita ja kieliä, kuten PHP, ASP, JSP, .NET, Ruby, Python, vain muutamia mainitakseni. Kehittäjät alkoivat ymmärtää, että kahden eri kielen käyttö asiakas- ja palvelinympäristöissä vaikeutti asioita. Alun perin yritettiin yhtenäistyä yhdellä kielellä yritettiin luoda palvelinpuolen asiakaskomponentteja ja koota ne JavaScriptiksi. Tämä ei toiminut odotetulla tavalla, ja monet näistä projekteista epäonnistuivat (esimerkiksi ASP MVC: n korvaaminen ASP.NET-verkkolomakkeet , ja voidaan sanoa niin GWT korvataan seuraavalla: Polymeeri ). lähitulevaisuudessa). Mutta se oli pohjimmiltaan erinomainen idea: yksi kieli asiakkaalla ja palvelimella, jonka avulla voimme käyttää komponentteja ja resursseja uudelleen (tämä on avain: resursseja ).

Vastaus oli yksinkertainen: käytä JavaScriptiä palvelimella.

Itse asiassa JavaScript syntyi JavaScript-palvelimen puoli Netscape Enterprise Server -palvelimessa, mutta kieli ei juuri ollut vielä valmis. Vuosien kokeilujen ja erehdysten jälkeen Node.js lopulta syntyi, joka ei vain laittanut JavaScriptiä palvelimelle, vaan myös edistänyt ajatusta ei-estävä ohjelmointi , muuttamalla tapaa kirjoittaa 'fread' (I / O) ikuisesti (lue lisää tässä .

Lauseessa: ei-estävä ajoitus pyrkii asettamaan aikaa vievät tehtävät syrjään, yleensä määrittelemällä, mitä pitäisi tehdä, kun nämä tehtävät on suoritettu, ja antamalla prosessorin käsitellä muita pyyntöjä sillä välin.

Mutta nuo ideat eivät olleet uusia - joten miksi ne tulivat niin suosituiksi Node.js: n kanssa? Yksinkertainen, estämätön ohjelmointi voidaan saavuttaa monin tavoin. Ehkä helpoin on käyttää soittopyyntöjä ja a loop-tapahtuma . Useimmilla kielillä se ei ole helppo tehtävä: vaikka soittopyynnöt ovat joillakin kielillä yleinen piirre, silmukointitapahtuma ei ole, ja huomaat yleensä kiinni ulkoisista kirjastoista (esim. Python, Twister ). Mutta JavaScriptissä soittopyynnöt ovat sisäänrakennettu kielelle, samoin kuin tapahtumasilmukalle, ja melkein kaikki JavaScript-ohjelmia käyttäneet ohjelmoijat tuntevat ne (tai ainakin ovat käyttäneet niitä, vaikka eivät ymmärrä täysin, mitä silmukointitapahtuma tarkoittaa ). Yhtäkkiä kukin Planet Earth -aloitusyrityksistä voisi käyttää kehittäjiä (esim. Resursseja) uudelleen sekä asiakas- että palvelinpuolella ratkaistakseen 'Guru Python tarvitaan' -ongelma .

Yhtäkkiä jokainen Planet Earth -aloitusohjelma voi käyttää kehittäjiä (esim. Resursseja) uudelleen sekä asiakas- että palvelinpuolella ratkaistakseen 'Python Guru Needed' -ongelman.

Joten nyt meillä on uskomattoman nopea foorumi (kieltävän ohjelmoinnin ansiosta) ohjelmointikielellä, jota on uskomattoman helppo käyttää (JavaScriptin ansiosta). Mutta riittääkö? Kestääkö se? Olen varma, että JavaScriptillä on tärkeä paikka tulevaisuudessa. Anna minun kertoa sinulle miksi:

• Toiminnallinen ohjelmointi

  JavaScript oli ensimmäinen ohjelmointikieli johti toiminnallista paradigmaa massoille (tietysti Lisp oli tietysti ensimmäinen, mutta useimmat kehittäjät eivät ole koskaan rakentaneet Lisp-sovellusta valmiina tuotantokäyttöön). Lisp ja itse, Javascriptin päävaikutukset , ne ovat täynnä innovatiivisia ideoita. Nuo ideat voivat vapauttaa mielemme tutkia uusia tekniikoita, malleja ja paradigmoja. Ja ne kaikki johtavat JavaScriptiin. Katso monadit , Kirkon koodaus tai jopa (käytännön esimerkkinä) toimintojen kokoelma] (http://underscorejs.org/#collections), osoitteesta Alaviiva.js mikä voi säästää rivejä ja koodirivejä.

• Dynaamiset objektit ja prototyyppinen perintö

  Luokittelematon objektisuuntautunut ohjelmointi (ja ilman loputtomia luokan perintöjä) mahdollistaa nopean kehityksen (luo objekteja, lisää menetelmiä ja käytä niitä), mutta mikä tärkeintä, lyhentää uudelleenrakennusaikaa huoltotöiden aikana antamalla kehittäjän muokata objektien esiintymiä luokkien sijaan. Tämä nopeus ja joustavuus luo tietä nopealle kehitykselle.

• JavaScript it internet

  JavaScript oli suunniteltu Internetiin , on ollut täällä alusta alkaen, ja ei aio lähteä . Kaikki yritykset tuhota se ovat epäonnistuneet, katsokaa esimerkiksi Appletit Java , VBScript-korvike Microsoft, TypeScript (joka on koottu JavaScriptiin), ja Flashin putoaminen matkapuhelinmarkkinoiden ja HTML5: n käsissä. Javascriptia on mahdotonta korvata rikkomatta miljoonia verkkosivuja, joten pitkän aikavälin tavoitteemme tulisi olla sen parantaminen. Ja tähän tehtävään ei ole ketään parempaa kuin Tekninen komitea 39 ECMA.

  Ok, vaihtoehtoja JavaScriptille syntyy joka päivä, miten CoffeeScript , TypeScript , ja miljoonat kielet, jotka kääntyvät JavaScriptiin . Nämä vaihtoehdot voivat olla hyödyllisiä kehitysvaiheissa (kautta lähdekoodikartoitukset ), mutta he eivät pysty esiintymään JavaScriptiä pitkällä aikavälillä kahdesta syystä: heidän yhteisönsä eivät koskaan ole suurempia, ja ECMA-skripti (esim. JavaScript) hyväksyy heidän parhaat toimintonsa. JavaScript ei ole kuin kokoonpanokieli: se on korkean tason ohjelmointikieli, jonka lähdekoodi on ymmärrettävissä - sinun pitäisi siis ymmärtää.

Kiitos nyt Esprima-projekti , voit luoda omia työkaluja pelaamaan lähdekoodilla, muokkaamalla sitä, muuttamalla sen tyyliä, lisäämällä kommentteja, instrumentointia ja kaikenlaisia ​​asioita, joita voit kuvitella pelatessasi ohjelman abstraktin syntaksipuun kanssa ikään kuin pelaat DOM-puun kanssa.

Päästä päähän JavaScript: Node.js ja MongoDB

Joten nämä ovat syitä käyttää JavaScriptiä. Aion käyttää nyt JavaScriptiä syynä käyttämään Node.js: ää ja MongoDB: tä.

• Node.js

  Node.js on alusta nopeaan ja skaalautuvaan verkkosovellusten rakentamiseen - niin pohjimmiltaan Node.js-sivusto sanoo. Mutta Node.js on muutakin: se on ensisijainen ajoaika kaikille sovelluksille, joilla on JavaScript I / O -käyttöoikeus. Vaikka et aio kirjoittaa pääpalvelinsovellusta Node.js: n avulla, voit käyttää Node.js: n päälle rakennettuja sisäänrakennettuja työkaluja kehitysprosessisi parantamiseen. Esimerkiksi: Mocha.js yksikkötestausta varten, Grunt.js automatisoituihin rakennustehtäviin tai jopa Suluissa loppuun koodin muokkaus.

  Joten jos aiot kirjoittaa palvelimen tai asiakasohjelman JavaScript-sovelluksia, sinun tulisi tutustua Node.js: ään, koska sinun on käytettävä sitä päivittäin. On joitain mielenkiintoisia vaihtoehtoja ), mutta yksikään niistä ei tavoita edes 10% Node.js-yhteisöstä.

• MongoDB

  MongoDB se on tietokanta NoSQL perustuu asiakirjoihin, jotka käyttävät kyselykielenä JavaScriptiä, mikä sallii JavaScriptiympäristön loppuun saattamisen. Mutta se ei ole edes tärkein syy tämän tietokannan valitsemiseen.

  MongoDB on a schemaless-tietokanta jonka avulla objektisi voivat säilyä joustavasti ja sopeutua siten nopeammin muuttuviin vaatimuksiin. Lisäksi se on erittäin skaalautuva Y perustuu kartan pienennykseen , mikä tekee siitä sopivan datanintensiivisiin sovelluksiin. MongoDB on niin joustava, että sitä voidaan käyttää skeemattomana asiakirjatietokantana, relaatiotietovarastona (vaikka siitä puuttuu liiketoimia ) tai jopa avaimen arvoinen tallennus välimuistissa oleville vastauksille.

Palvelimen modulaatio Express.js: n avulla

Palvelinpuolen modulaatio ei ole koskaan helppoa. Mutta kanssa Express.js (Y Connect.js ) tuli idea 'Väliohjelmisto' (tai väliohjelmisto). Mielestäni väliohjelmisto on paras tapa määritellä komponentit palvelimella. Jos haluat verrata sitä tunnettuun standardiin, se on melko lähellä putkia ja suodattimia.

Perusidea on, että komponenttisi on osa putkea. Putki käsittelee pyynnön (syötteen) ja tuottaa vastauksen (lähdön), mutta komponenttisi ei ole vastuussa täydellisestä vastauksesta. Sen sijaan muokkaat vain tarvitsemasi ja siirrät sen sitten toiselle putkikappaleelle. Kun viimeinen putkiosa on saanut prosessin päätökseen, vastaus lähetetään asiakkaalle.

Kutsumme näitä 'putkikappaleita' väliohjelmiksi. Selvästi voimme luoda kahdenlaisia väliohjelmisto :

• Välituote : Ne, jotka käsittelevät pyynnön ja vastauksen, mutta eivät ole täysin vastuussa itse vastauksesta, joten he siirtävät seuraavan väliohjelmiston.

• Finaalit : Ne, jotka ottavat täyden vastuun lopullisessa vastauksessa. He käsittelevät ja muokkaavat pyyntöä ja vastausta, mutta heidän ei tarvitse delegoida seuraavaa väliohjelmistoa. Käytännössä on suositeltavaa delegoida joka tapauksessa seuraavaan väliohjelmistoon arkkitehtuurin joustavuuden takaamiseksi (esim. Lisäämällä lisää väliohjelmia myöhemmin), vaikka kyseistä väliohjelmistoa ei olisikaan (siinä tapauksessa vastaus menee suoraan asiakkaalle)

Tarkastellaan konkreettisena esimerkkinä komponenttia 'järjestelmänvalvojan käyttäjä' palvelimella. Väliohjelmistojen osalta meillä olisi sekä päätepisteitä että välittäjiä. Loppuun mennessä meillä olisi ominaisuuksia, kuten käyttäjän luominen ja käyttäjien luettelointi. Mutta ennen kuin voimme suorittaa nuo toiminnot, tarvitsemme välittäjämme todennukseen (koska emme halua pyyntöjen luoda todentamattomia käyttäjiä). Kun olemme luoneet nämä todennusvälittäjät, voimme yksinkertaisesti liittää ne mihin tahansa kohtaan, jossa haluamme muuttaa olemassa olevan muun kuin todennusominaisuuden yhdeksi todennukseksi.

Yhden sivun sovellukset

Projekti Sen sisällä keskittyä luomiseen yhden sivun sovellukset (SPAs-Single-Applications) . Monet web-kehittäjät ovat houkutelleet useammin kuin kerran yrittää rakentaa kylpylöitä. Olen kehittänyt useita (lähinnä omistettuja), ja voin vakuuttaa, että ne ovat yksinkertaisesti verkkosovellusten tulevaisuus. Oletko koskaan vertaillut kylpylää tavalliseen mobiilisovelluksen verkkosovellukseen? Vastausero on kymmeniä sekunteja.

Oletko koskaan vertaillut kylpylää tavalliseen mobiilisovelluksen verkkosovellukseen? Vastausero on kymmeniä sekunteja.

Kylpylät ovat verkon tulevaisuus - joten miksi tekisit tuotteesi vanhassa muodossa? Yleinen argumentti, jonka kuulen, on se, että ihmiset ovat huolissaan hakukoneoptimoinnista. Mutta jos käsittelet asioita oikein, tämän ei pitäisi olla ongelma: Googlella itsellään on erittäin hyvä opetusohjelma miten se tehdään, ja on erittäin hyviä kommentteja tässä liian.

Asiakaspuolen MV * Backbone.js, Marionette.js ja Twitter Bootstrap

Paljon on sanottu MVC * -kehykset SPA-alueille . Se on monimutkainen päätös, mutta sanon, että kolme parasta ovat Backbone.js , Ember.js , Y Angular.js .

Kaikki kolme ovat hyvin pidettyjä. Mutta mikä niistä on sinulle paras?

Valitettavasti minun on myönnettävä, että minulla on hyvin rajallinen kokemus Angular.js: stä, joten jätän sen pois tästä keskustelusta. Ember.js ja Backbone.js edustavat nyt kahta eri tapaa hyökätä samaan ongelmaan.

Backbone.js se on minimalistinen, yksinkertainen ja tarjoaa sinulle tarpeeksi yksinkertaisen kylpylän luomiseen. Toisaalta Ember.js on täysin ammattimainen kehys SPA-alueiden luomiseen. Siinä on enemmän röyhelöitä, mutta myös suurempi oppimiskäyrä.

Sovelluksen koosta riippuen päätös voi olla yhtä helppo kuin tarkastelemalla FeaturesUsed / featuresAvailable -suhdetta, mikä antaa sinulle hyvän vihjeen.

Siinä tapauksessa että Sen sisällä , Halusin käsitellä useimpia skenaarioita, joten valitsin Backbone.js: n helpoksi SPA: n luomiseksi. Tällä tavoin kukin komponentti on yksinkertainen sovellus, ja lopullinen sovellus voi olla niin monimutkainen kuin haluamme sen olevan.

Muotoilu on myös haaste, mutta meillä voi jälleen olla puitteet pelastaaksemme meidät. CSS: lle ei ole mitään parempaa kuin Twitter Bootstrap , joka tarjoaa täydellisen valikoiman tyylejä, jotka ovat käyttövalmiita ja ovat helppo muokata .

Booststrap luotiin kieltä käyttäen VÄHEMMÄN joka on avoimen lähdekoodin, joten voimme muokata sitä tarvittaessa. Siinä on runsaasti käytettävyyden valvontaa hyvin dokumentoitu Bootstrap-sivustolla . Lisäksi on räätälöintimalli jonka avulla voit luoda omia ohjaimia. Hän on ehdottomasti mies.

Parhaat käytännöt: Grunt.js, Mocha.js, Chai.js, RequireJS ja CoverJS

Lopuksi meidän tulisi määritellä joitain parhaita käytäntöjämme ja tarkastella, kuinka Init voi auttaa sinua toteuttamaan ja ylläpitämään niitä. Ratkaisumme on keskittynyt useisiin työkaluihin, jotka perustuvat Node.js-tiedostoon.

• Mocha.js ja Chai.js :

  Näiden työkalujen avulla voit parantaa kehitysprosessiasi soveltamalla TDD tai BDD , joka tarjoaa infrastruktuurin yksikkötestien järjestämiseksi ja kantoraketin, joka suorittaa ne automaattisesti.

  On Tuhansia kehyksiä JavaScript-yksikötesteille. Joten miksi käyttää Mocha.js: ää? Lyhyt vastaus: se on joustava ja kattava.

  Pitkä vastaus: sillä on kaksi tärkeää ominaisuutta (käyttöliittymät, toimittajat) ja yksi tärkeä poissaolo ( väitteitä ). Anna minun selittää.

  • Liitännät : Ehkä olet tottunut pakettien TDD-käsitteisiin ja yksikkötesteihin, tai ehkä pidät parempana BDD-ideoista käyttäytymismäärityksistä ' kuvaa 'Y' sen pitäisi ”. Mocha.js antaa sinun käyttää molempia lähestymistapoja.
  • Toimittajat Testin suorittaminen tuottaa tulosraportteja, ja voit muotoilla tulokset käyttämällä erilaisia ​​toimittajia. Esimerkiksi, jos joudut syöttämään jatkuvan integroinnin palvelinta, löydät toimittajan tekemään juuri sen.
  • Väitteiden kirjaston puute :: kaukana ongelmasta, Mocha.js on suunniteltu antamaan sinun käyttää valitsemaasi väitekirjastoa tarjoamalla enemmän joustavuutta. On Monet vaihtoehdot , mutta siellä Chai.js tulee pelaamaan.

  Chai.js on joustava väitekirjasto, jonka avulla voit käyttää mitä tahansa kolmesta tärkeimmistä väitetyyleistä:

  • Väitä : Klassinen vanhan koulun väitetyyli. Esim .:

    assert.equal(variable, ”valor”);

  • Odottaa : Yleisimmin käytetty ketjutettava väitetyyppi BDD: ssä. Esim .:

    expect(variable).to.equal(“valor”);

  • Pitäisi : Käytetään myös BDD: ssä, mutta mieluummin odotan, koska pitäisi, koska se kuulostaa toistuvalta _'it _ käyttäytymismäärityksellä ('pitäisi tehdä jotain ..' - 'sen pitäisi tehdä jotain'). Esim .:

    variable.should.equal(“valor”);

  Chai.js sulautuu täydellisesti Mocha.js: n kanssa. Vain näitä kahta kirjastoa käyttämällä voit kirjoittaa testisi TDD-, BDD- tai millä tahansa kuviteltavalla tyylillä.

• Grunt.js :

  Grunt.js: n avulla voit automatisoida rakennustehtäviä kaikesta yksinkertaisista kopioiduista ja liitetyistä ketjutetuista tiedostoista esikäännettyihin malleihin, käännettyyn kielityyliin (esim. SASS ja LESS), yksikötestaukseen (mocha.js: n kanssa), nukkaamiseen ja koodin pakkaamiseen (esim. UglifyJS tai Sulkemisen kääntäjä ). Voit lisätä oman automatisoidun tehtävän Gruntiin tai tehdä hakuja murista loki , jossa on saatavana satoja ja satoja laajennuksia (taas työkalujen käyttäminen, joiden takana on suuria yhteisöjä, maksaa hyvin). Grunt voi myös valvoa tiedostojasi ja laukaista toimintoja, kun niitä muokataan.

• VaadiJS :

  RequireJS saattaa kuulostaa toiselta tavalta ladata moduuleja AMD , mutta voin vakuuttaa teille, että se on paljon enemmän. Ymmärtääkseen miksi meidän on ensin mainittava ajatus moduulien nimiavaruudesta (esim. Demo.views.hello), joka välttää globaalin nimitilan saastuttamisen käärimällä kukin moduuli omaan nimitilaansa. Ongelmana on, että näitä moduuleja ei voi käyttää uudelleen: jos muokkaat ”instanssin” nimiavaruutta, muutat kaikkien ”instanssien” nimitilaa. Toisin kuin RequireJS, voit määrittää uudelleenkäytettävät moduulit tyhjästä. (Lisäksi se auttaa sinua adoptoimaan Riippuvuuden injektio varten estää moduulejasi pääsemästä globaaleihin muuttujiin ).

• KansiJS :

  Koodin kattavuus se on metrinen mittari testiesi arvioimiseksi. Kuten nimestä käy ilmi, se kertoo, kuinka paljon koodia nykyinen testipaketti sisältää. CoverJS mittaa testiesi koodikattavuutta instrumentoimalla lauseita (koodirivien sijaan JSC: n kattavuus ) ja koodin instrumentoidun version luominen. Se luo myös raportteja palvelimesi syötteeksi jatkuva integraatio .

Ominaisuuksien vaihtaminen _Branches_ (_ramas_) -toiminnon avulla

Kun aloitin Sen sisällä Tarvitsin tapaa, jolla käyttäjät voivat ottaa käyttöön ja poistaa käytöstä erilaisia ​​ominaisuuksia, joita he saattavat haluta projektissaan. Päätin käyttää radikaalia lähestymistapaa gitin haaroitusjärjestelmän kanssa tämän toiminnon toteuttamiseksi.

Pohjimmiltaan kukin haara edustaa ominaisuutta tai toimintoa, jonka käyttäjä saattaa haluta sisällyttää. Jos aloitat projektin alusta alkaen, aloita tarvitsemastasi vähimmäishausta ja lisää sitten muita tekniikoita yhdistämällä haara muihin haluttuihin. Oletetaan esimerkiksi, että haluat aloittaa projektisi Backbone.js- ja Marionette.js-tiedostoilla. Voit aloittaa Backbone.js-haarasta ja yhdistää sen Marionette-haaraan jatkamalla sieltä jokaisen lisättävän toiminnon kohdalla.

Toistaiseksi yhdistämisen ajatusta toiminnallisuuden lisäämiseksi voidaan käyttää vain tekniikkamalleissa (esim. Selkäranka, solmu, Express). Mutta tulevaisuudessa voit vaihtaa taustapalvelujen (esim. MongoDB: stä Postgresiin) ja asiakaspuolen toteutusten välillä.

Aloita projekti Initin kanssa ja ota Heroku käyttöön

Koskaan ei ole ollut helpompaa tapaa aloittaa projekti. Mene GitHub-arkisto , tarkista haara uusimmilla sitoumuksilla (tällä hetkellä se on käyttäjän ylläpitäjä, vaikka tämä saattaa muuttua tulevaisuudessa) ja sitten:

1. Luo hakemisto projektillesi (tai käytä olemassa olevaa).
2. Luo arkisto 'git init': llä (tai käytä olemassa olevaa arkistoa)

3. Lisää etäpalvelin Init-toiminnolla

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

4. Lataa haluamasi haara

   git pull init usermanager

5. Lataa Heroku-prosessitiedosto

   git pull init heroku-webprocess

6. Kanssa Heroku-työkaluvyö asennettu, luo sovellus

   heroku create

7. Työnnä päähaara Herokulle

   git push heroku master
8. Käy sovelluksessasi, joka toimii Herokulla!

Nyt voit aloittaa tappajaominaisuutesi kehittämisen vain muutamalla koodirivillä. Paitsi että, kehität uusimpia ja tehokkaimpia tekniikoita kehityskokonaisuudessa, joka on mahdollisimman automatisoitu.

Toivottavasti voit käyttää Sen sisällä aloittaaksesi seuraavan upean ideasi. Muista tarkistaa Init-arkistosta korjaukset ja ominaisuudet - sen kehitys on melko aktiivista, ja odotan innolla palautettasi.

Sisällön on kääntänyt Pablo Fabregat, jäsen TransBunko , teknisten käännösten markkinat.