Tarina

Joten sinulla ja perustajillasi on tämä loistava idea yrityksestä, eikö?

Olet lisännyt mielessäsi ominaisuuksia.

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

Ok, niin ihmiset haluavat sitä. Tulee jopa rahaa. Ja ainoa syy, miksi heillä ei ole sitä, on, että et ole vielä toteuttanut sitä.

Joten istut yhden päivän ja sanot: 'Tehdään se!' Pian yrität selvittää, miten sovelluksesi liiketoimintalogiikka, tappajaominaisuus, joka ajaa tuotetta eteenpäin: sinulla on idea siitä, miten se tehdään, ja tiedät itsesi voi tee se.

'Tehty! Se toimii!' sinä sanot. Todiste konseptistasi on menestys! Jäljellä on vain pakata se verkkosovellukseen.

'Ok, luodaan sivusto', sanot.

Ja sitten huomaat totuuden: sinun on valittava ohjelmointikieli; sinun on valittava (moderni) alusta; sinun on valittava joitain (moderneja) kehyksiä; sinun on määritettävä (ja ostettava) tallennustila, tietokannat ja isännöintipalvelut; tarvitset järjestelmänvalvojan käyttöliittymän; tarvitset käyttöoikeusjärjestelmän; tarvitset sisällönhallinnan.

Haluat olla laiha, 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ä kymmeniä arkkitehtoniset päätökset tehdä. Ja haluat tehdä oikeat: haluat käyttää tekniikoita, jotka mahdollistavat nopean kehityksen, jatkuvan iteroinnin, maksimaalisen tehokkuuden, nopeuden, kestävyyden ja paljon muuta. Haluat olla laiha, 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 sinusta tuntuu hukkua. Energianne ei ole sama kuin se oli kerran. Yrität koota asioita yhteen, mutta se on liikaa työtä.

Todiste käsitteestä haihtuu ja kuolee hitaasti.

Ehdotus

Hylkääni itseni tällä tavoin, päätin suunnitella ratkaisun. Kutsun sitä Sen sisällä ’Projekti (tai init.js).

Idean ydin on saada yksi projekti kaikkien käynnistämiseksi, antaa kehittäjä tai tekninen perustaja tekee kaikki nämä olennaiset päätökset kerralla ja saa kyseisiin päätöksiin sopivan lähtökohdan. Tiedän, mitä arvostelijat sanovat: 'Yksi ratkaisu ei sovi kaikkiin ongelmiin' (vihaajat vihaavat). Ja he saattavat olla oikeassa. Mutta voimme tehdä parhaamme arvioidun ratkaisun luomiseksi, ja mielestäni Init on melko lähellä.

Tämän tavoitteen saavuttamiseksi meidän on pidettävä mielessä muutama keskeinen idea. Kehittäessäni Initia harkitsin:

• Komponentit

  Komponentointi on minkä tahansa järjestelmän keskeinen piirre, koska sen avulla voit käyttää ohjelmistokomponentteja uudelleen eri projekteissa - mikä on Initin päätavoite. Komponentointiin liittyy kuitenkin myös sivutuote, 'korvattavuus', joka on paras liittolainen hyökätä useisiin erilaisiin ongelmiin 'melkein' samalla ratkaisulla.

• Kehityksen helppous

  Joku ongelma, jossain on ratkaisu, joka on kirjoitettu parhaiten Brainf * ck . Mutta ratkaisun toteuttaminen (Brainfuckissa) on melkein mahdotonta kirjoittaa, saati lukea. Se maksaa sinulle aikaa ja valtavasti vaivaa. Yleensä sinun tulee käyttää kieliä ja alustaa, jotka tekevät kehityksestä helpompaa, ei vaikeampaa sinulle (tai kenellekään, joka saattaa työskennellä sen kanssa myöhemmin).

• Yhteisö

  Valitaksesi minkä tahansa alustan, varmista, että sillä on suuri yhteisö ja joka voi auttaa sinua yleisimpien ja harvinaisimpien ongelmien ratkaisemisessa. Muista: jQuery ei ehkä ole nopein , puhtain , tai tyylikkäin kirjasto - mutta on voittaja vain sen vuoksi Yhteisö .

Pidä nämä tavoitteet mielessä ja seuraavaksi näytän sinulle, kuinka tein omat päätökseni luodessani Initia.

Ytimessä Init käyttää hyväkseen koko pino JavaScript ’Paradigma (jotkut ihmiset viittaavat siihen tai sen osajoukkoon nimellä TÄRKE pino ). Työskentelemällä sellaisen kanssa pino , Init pystyy käyttämään vain yhtä kieltä ja luomaan uskomattoman joustavan ja täysin varustellun ympäristön verkkosovellusten kehittämiseen. Lyhyesti sanottuna Initin avulla voit käyttää JavaScriptiä paitsi asiakas- ja palvelinkehityksessä myös rakennuksessa, testauksessa, mallinnuksessa ja muussa.

Mutta antaa hidastua hetkeksi ja kysyä itseltämme: onko todella hyvä käyttää JavaScriptiä?

Miksi valitsin JavaScriptin

Olen ollut verkkokehittäjä vuodesta 1998. Silloin käytimme Perliä suurimmaksi osaksi palvelinpuolen kehitystyötä, mutta siitä lähtien meillä on ollut JavaScript asiakaspuolella. Verkkopalvelinteknologiat ovat muuttuneet siitä lähtien valtavasti: käytiin läpi aallon kielen ja tekniikoiden, kuten PHP, AP, 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. Ensimmäiset yritykset yhtenäistyä yhdellä kielellä yritti luoda palvelimelle asiakaskomponentteja ja koota ne JavaScriptiin. Tämä ei toiminut odotetulla tavalla ja suurin osa näistä projekteista epäonnistui (esimerkiksi: ASP MVC: n korvaaminen ASP.NET-verkkolomakkeet ja GWT epäilemättä korvataan lähitulevaisuudessa Polymeeri ). Mutta se oli pohjimmiltaan hieno idea: yksi kieli asiakkaalla ja palvelimella, jolloin voimme käyttää komponentteja ja resursseja uudelleen (tämä on avainsana: resursseja ).

Vastaus oli yksinkertainen: aseta JavaScript palvelimelle.

JavaScript todella syntynyt JavaScript-palvelinpuolella Netscape Enterprise Server -palvelimessa, mutta kieli ei yksinkertaisesti ollut vielä valmis. Vuosien kokeilujen ja erehdysten jälkeen Node.js vihdoin syntyi, joka paitsi lisäsi JavaScriptin palvelimelle, myös edisti ajatusta ei-estävä ohjelmointi , muuttamalla tapaa kirjoittaa 'leipä' (I / O) ikuisesti (lue tässä lisää).

Yhdessä lauseessa: esto-ohjelmoinnin tavoitteena on laittaa aikaa vievät tehtävät sivuun, yleensä määrittämällä, mitä pitäisi tehdä, kun nämä tehtävät on suoritettu, ja sallimalla prosessorin käsitellä muita pyyntöjä sillä välin.

Mutta nämä ideat eivät olleet uusia - niin miksi niistä tuli niin suosittuja Node.js: n kanssa? Yksinkertainen, estämätön ohjelmointi voidaan saavuttaa useilla tavoilla. Ehkä helpoin on käyttää soittopyyntöjä ja tapahtumasilmukka . Useimmilla kielillä se ei ole helppo tehtävä: vaikka soittopyynnöt ovat yleinen ominaisuus joillakin muilla kielillä, tapahtumasilmukka ei ole, ja huomaat usein kamppailevasi ulkoisten kirjastojen kanssa (esimerkiksi: Python, Twister ). Mutta JavaScriptissä soittopyynnöt ovat sisäänrakennettu kielelle, samoin kuin tapahtumasilmukka, ja melkein kaikki ohjelmoijat, jotka ovat jopa pilanneet JavaScriptin, tuntevat ne (tai ovat ainakin käyttäneet niitä, vaikka he olisivatkin eivät oikein ymmärrä tapahtumasilmukkaa ). Yhtäkkiä jokainen maapallon startup voisi käyttää uudelleen kehittäjiä (ts. Resursseja) sekä asiakas- että palvelinpuolella ratkaistakseen tarvitsemansa Python-gurun. työpaikkaongelma .

Yhtäkkiä jokainen maapallon käynnistys voisi käyttää kehittäjiä (ts. Resursseja) uudestaan ​​sekä asiakas- että palvelinpuolella ratkaistakseen 'Python Guru Needed' -työpaikkaongelman.

Joten nyt meillä on uskomattoman nopea foorumi (kieltäytymättömä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 tuo toiminnallinen paradigma massoille (tietysti Lisp tuli ensin, mutta useimmat ohjelmoijat eivät ole koskaan rakentaneet tuotantovalmiita sovelluksia Lisp: n avulla). Lisp ja itse, Javascriptin tärkeimmät vaikutteet , ovat täynnä innovatiivisia ideoita. Nuo ideat voisivat vapauttaa mielemme tutkia uusia tekniikoita, malleja ja paradigmoja. Ja ne kaikki siirtyvät JavaScriptiin. Katso monadit , Kirkon numerot tai jopa (käytännön esimerkin vuoksi) Alaviiva.js S kokoelmatoiminnot , mikä voi säästää rivejä ja koodirivejä.

• Dynaamiset objektit ja prototyyppinen perintö

  Kohdekeskeinen ohjelmointi ilman luokkia (ja ilman loputtomia luokkien hierarkioita) mahdollistaa nopean kehityksen (luo objekteja, lisää menetelmiä ja käytä niitä), mutta mikä tärkeintä, vähentää uudelleenrakennusaikaa huoltotöiden aikana antamalla ohjelmoijan muokata objektien esiintymiä sen sijaan luokkiin. Tämä nopeus ja joustavuus luo tietä nopealle kehitykselle.

• JavaScript on Internet

  JavaScript oli suunniteltu Internetiin , se on ollut täällä alusta alkaen, ja se on ei mene pois . Kaikki yritykset tuhota se ovat epäonnistuneet: katso esimerkiksi Java-sovelmat , VBScriptin korvaama Microsoftin TypeScript (joka kääntyy JavaScriptiin), ja Flashin häviäminen mobiilimarkkinoiden ja HTML5: n käsissä. Javascriptia on mahdotonta korvata rikkomatta miljoonia verkkosivuja, joten tulevaisuuden tavoitteidemme tulisi olla sen parantaminen. Ja työhön ei ole ketään parempaa kuin Tekninen komitea 39 ECMA: lta.

  Ok, vaihtoehdot JavaScriptille syntyvät joka päivä, kuten CoffeeScript , TypeScript ja miljoonia kieliä, jotka kääntyvät JavaScriptiin . Nämä vaihtoehdot voivat olla hyödyllisiä kehitysvaiheissa ( lähdekarttojen kautta ), mutta he eivät pysty syrjäyttämään JavaScriptiä pitkällä aikavälillä kahdesta syystä: heidän yhteisönsä eivät koskaan ole suurempia, ja heidän parhaat ominaisuudet otetaan käyttöön ECMA-komentosarjalla (eli JavaScript). JavaScript ei ole kokoonpanokieli: se on korkean tason ohjelmointikieli, jonka lähdekoodi on ymmärrettävä - joten sinun pitäisi ymmärtää se.

Nyt kiitos Express-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 pelaamalla ohjelman abstraktin syntaksipuun kanssa ikään kuin työskentelisit DOM-puu.

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

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

• Node.js

  Node.js on alusta nopeaan ja skaalautuvaan verkkosovellukseen - se on melkein mitä Node.js-sivusto sanoo. Mutta Node.js on muutakin: se on ensisijainen ajonaikainen ympäristö kaikille JavaScript-sovelluksille, joilla on I / O-käyttöoikeus. Vaikka et aio kirjoittaa pääpalvelinsovellusta Node.js: n avulla, voit käyttää Node.js: n päälle rakennettuja työkaluja kehitysprosessisi parantamiseen. Esimerkiksi: Mocha.js yksikkötestausta varten, Grunt.js automatisoituihin koontitehtäviin tai jopa Suluissa koko tekstin koodin muokkausta varten.

  Joten, jos aiot kirjoittaa JavaScript-sovelluksia palvelimelle tai asiakkaalle, sinun tulisi tarkastella joitain Node.js-esimerkkejä , koska tarvitset ja käytät sitä päivittäin. On joitain mielenkiintoisia vaihtoehtoja , mutta yksikään niistä ei ole edes 10%: lla Node.js-yhteisöstä.

• MongoDB

  MongoDB on NoSQL asiakirjapohjainen tietokanta, joka käyttää kyselykielenä JavaScriptiä, jolloin saan täydellisen JavaScript-alustan loppuun. Mutta se ei ole edes tärkein syy valita tämä tietokanta.

  MongoDB on a skeematon tietokanta jonka avulla voit säilyttää kohteesi joustavasti ja sopeutua siten nopeammin vaatimusten muutoksiin. Lisäksi se on erittäin hyvä skaalautuva ja kartan vähennys perustuu , jotka tekevät siitä sopivan isojen tietojen sovelluksiin. MongoDB on niin joustava, että sitä voidaan käyttää skeemattomana asiakirjatietokantana, relaatiotietovarastona (vaikka siitä puuttuu liiketoimia ) tai jopa avainarvovaraajana vastausten välimuistiin tallentamiseen.

Palvelimen komponentointi Express.js: n kanssa

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

Perusidea on, että komponenttisi on osa putkistoa. Putki käsittelee pyynnön (syötteen) ja tuottaa vastauksen (lähdön), mutta komponenttisi ei ole vastuussa koko vastauksesta. Sen sijaan se vain muokkaa mitä tarvitsee ja delegoi sitten putken seuraavaan osaan. Kun putkilinjan viimeinen kappale on valmis, vastaus lähetetään takaisin asiakkaalle.

Viittaamme näihin ”putkilinjan kappaleisiin” väliohjelmistoina. Voimme selvästi luoda kahdenlaisia ​​väliohjelmia:

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

• Finaalit : Ne, joilla on täysi vastuu lopullisesta vastauksesta. 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 mahdollistamiseksi (ts. Lisäämällä lisää väliohjelmistoja myöhemmin), vaikka kyseistä väliohjelmistoa ei olisikaan (jolloin vastaus menee suoraan asiakkaalle).

Tarkastellaan konkreettisena esimerkkinä palvelimen ”käyttäjähallinta” -komponenttia. Väliohjelmistojen osalta meillä olisi sekä finaaleja että välituotteita. Finaaleissamme meillä olisi sellaisia ​​ominaisuuksia kuin käyttäjän luominen ja käyttäjien luettelointi. Mutta ennen kuin voimme suorittaa nämä toimet, tarvitsemme välituotteemme todennukseen (koska emme halua, että tunnistamattomat pyynnöt tulevat ja luovat käyttäjiä). Kun olemme luoneet nämä todennuksen välituotteet, voimme vain liittää ne mihin tahansa kohtaan, josta haluamme muuttaa aiemmin tunnistamattoman ominaisuuden todennetuksi ominaisuudeksi.

Yhden sivun sovellukset

Init-projekti keskittyy luomiseen yhden sivun sovellukset (SPA) . Useimmat verkkokehittäjät ovat houkutelleet useammin kuin kerran kokeilla käsiään kylpylöissä. Olen rakentanut useita (enimmäkseen omia), ja voin sanoa luottavaisin mielin, että ne ovat yksinkertaisesti verkkosovellusten tulevaisuus. Oletko koskaan vertaillut kylpylää tavalliseen mobiilisovelluksen verkkosovellukseen? Reagoivuusero on luokkaa kymmeniä sekunteja.

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

Kylpylät ovat verkon tulevaisuus - miksi rakennat 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 tehdä niin, ja on joitain hyviä kommentteja tässä yhtä hyvin.

Client Side MV *, jossa Backbone.js, Marionette.js ja Twitter Bootstrap

Paljon on sanottu MVC * -kehykset SPA-alueille . Se on kova valinta, mutta sanoisin, että kolme parasta ovat Backbone.js , Ember.js ja Angular.js .

Kaikki kolme ovat erittäin arvostettuja. Mutta mikä niistä sopii sinulle parhaiten?

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

Backbone.js on minimaalinen, yksinkertainen ja tarjoaa sinulle vain tarpeeksi yksinkertaisen kylpylän luomiseksi. Ember.js puolestaan ​​on täydellinen ja ammattimainen kehys SPA-alueiden luomiselle. Siinä on enemmän kelloja ja pilliä, mutta myös suurempi oppimiskäyrä.

Sovelluksen koosta riippuen päätös voi olla yhtä helppoa kuin tarkastelemalla featuresUsed / featuresAvailable -suhdetta, mikä antaa sinulle suuren vihjeen.

Initin tapauksessa halusin käsitellä useimmat skenaariot, joten valitsin Backbone.js: n helpoksi SPA: n luomiseksi Backbone.Marionette.View -komponenttina. Tällä tavoin jokainen komponentti on yksinkertainen sovellus, ja lopullinen sovellus voi olla niin monimutkainen kuin haluamme sen olevan.

Muotoilu on myös haaste, mutta voimme jälleen luottaa kehyksiin pelastaaksemme meidät. CSS: lle ei ole parempaa Twitter Bootstrap , joka tarjoaa täydellisen sarjan tyylejä, jotka ovat sekä käyttövalmiita heti pakkauksesta että helppo muokata .

Bootstrap luotiin VÄHEMMÄN kieli, ja se on avoimen lähdekoodin, joten voimme muokata sitä tarvittaessa. Sen mukana tulee tonnia UX-ohjaimia, jotka ovat hyvin dokumentoitu Bootstrap-sivustolla . Lisäksi on räätälöintimalli jonka avulla voit luoda oman. Se 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 itse Node.js: ään.

• 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 juoksijan suorittamaan ne automaattisesti.

  On tuhansia yksikön testikehyksiä JavaScriptiä varten. Joten miksi käyttää Mocha.js: ää? Lyhyt vastaus: se on joustava ja täydellinen.

  Pitkä vastaus: sillä on kaksi tärkeää ominaisuutta (rajapinnat, toimittajat) ja yksi merkittävä poissaolo (väitteet). Anna minun selittää.

  • Liitännät : Ehkä olet tottunut pakettien TDD-käsitteisiin ja yksikkötesteihin, tai ehkä mieluummin BDD-ideoita käyttäytymismäärityksistä, joissa on 'kuvaa' ja 'sen pitäisi'. Mocha.js antaa sinun käyttää molempia lähestymistapoja.

  • Toimittajat : testin suorittaminen tuottaa raportit tuloksista, ja voit muotoilla nämä tulokset käyttämällä erilaisia ​​toimittajia. Jos esimerkiksi haluat syöttää jatkuvan integroinnin palvelinta, löydät toimittajan tekemään juuri tämän.

  • Väitekirjaston puute : Mocha.js ei suinkaan ole ongelma, vaan se on suunniteltu antamaan sinun käyttää valitsemaasi väitekirjastoa, mikä antaa sinulle entistä enemmän joustavuutta. On paljon vaihtoehtoja , mutta tässä Chai.js tulee esiin.

  Chai.js on joustava väitekirjasto, jonka avulla voit käyttää mitä tahansa kolmesta tärkeimmästä väitetyylistä:

  • Väitä : Klassinen väitystyyli TDD: n vanhasta koulusta. Esim.:

    assert.equal(variable, ”value”);

  • Odottaa : Ketjutettava väitetyyli, yleisimmin käytetty BDD: ssä. Esim.:

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

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

    variable.should.equal(“value”);

  Chai.js yhdistyy 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 antaa sinun automatisoida rakennustehtävät, aina yksinkertaisesta kopioinnista ja liittämisestä tiedostojen yhdistämiseen, mallin esikokoelmaan, tyylikielen (eli SASS ja LESS) kokoamiseen, yksikötestaukseen (mocha.js: n kanssa), nukkaamiseen ja koodin pienentäminen (esim UglifyJS tai Sulkemisen kääntäjä ). Voit lisätä oman automatisoidun tehtävän Gruntiin tai tehdä hakuja Grunt-rekisteri , jossa on saatavilla satoja ja satoja laajennuksia (jälleen kerran työkalujen käyttäminen, joiden takana on mahtavia yhteisöjä, maksaa itsensä takaisin). Grunt voi myös valvoa tiedostojasi ja laukaista toimintoja, kun niitä muokataan.

• VaadiJS :

  RequireJS saattaa kuulostaa aivan uudelta tavalta ladata moduuleja AMD , mutta voin varmistaa, 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 yhden ”esiintymän” nimiavaruutta, muutat kaikkien ”esiintymien” nimiavaruutta. Toisin kuin RequireJS, voit määrittää uudelleenkäytettävät moduulit heti alusta alkaen. (Lisäksi se auttaa sinua omaksumaan Riippuvuuden injektio että vältä moduulien käyttämästä globaaleja muuttujia .)

• KansiJS :

  Koodin kattavuus on mittari testien arvioimiseksi. Kuten nimestä voi päätellä, se kertoo, kuinka suuri osa koodistasi on nykyisen testipakettisi peittämä. CoverJS mittaa testiesi koodikattavuutta instrumentoimalla lauseita (koodirivien sijaan JSC: n kattavuus ) koodissasi ja luomalla koodattu instrumentoitu versio. Se voi myös luoda raportteja syötteeksi Jatkuva integraatio Palvelin.

Ominaisuuksien käyttäminen ominaisuuksien vaihtamiseen

Kun aloitin Initin, tarvitsin tapaa, jolla käyttäjät voivat aktivoida ja deaktivoida erilaisia ​​ominaisuuksia, joita he saattavat haluta projektissaan. Päätin lähestyä radikaalisti gitin haarajärjestelmää tämän toiminnon toteuttamiseksi.

Pohjimmiltaan kukin haara edustaa ominaisuutta tai toimintoa, jonka käyttäjä voi haluta sisällyttää. Jos aloitat projektin alusta alkaen, aloita tarvitsemallasi haaralla ja lisää sitten muita tekniikoita sulauttamalla haluamasi haarat. Oletetaan esimerkiksi, että haluat aloittaa projektisi Backbone.js- ja Marionette.js-tiedostoilla. No, voit aloittaa Backbone.js-haarasta ja yhdistää sen Marionette-haaraan jatkamalla kaikkia lisäyksiä, joita haluat lisätä.

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

Aloita projekti Initilla ja ota käyttöön Heroku tänään

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

1. Luo hakemisto projektillesi (tai käytä olemassa olevaa).
2. Luo arkisto git init -ohjelmassa (tai käytä olemassa olevaa arkistoa).

3. Lisää kaukosäädin initillä

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

4. Hanki haluamasi haara

   git pull init usermanager

5. Lataa Heroku-prosessitiedosto

   git pull init heroku-webprocess

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

   heroku create

7. Työnnä päähaara Herokulle

   git push heroku master
8. Käy sovelluksessasi, käynnissä Herokulla!

Nyt voit alkaa kehittää tappajaominaisuuttasi vain muutamalla koodirivillä. Paitsi että, kehität uusimpia ja tehokkaimpia tekniikoita kehityskokonaisuudessa, joka on niin automatisoitu kuin mahdollista.

Toivon, että voit käyttää Sen sisällä aloittaa seuraava iso ideasi. Muista tarkistaa, että Init-arkistossa ei ole uusia korjauksia ja ominaisuuksia - sen kehitys on erittäin aktiivista, ja odotan innolla palautettasi.