Historien

Så du og din medstifter har denne flotte forretningsideen, ikke sant?

Du har lagt til funksjoner i hodet ditt.

Du spør ofte potensielle kunder om deres meninger, og de elsker deg alle.

Ok, så folk vil ha det. Det er til og med litt penger å tjene. Og den eneste grunnen til at de ikke kan få det, er fordi du ikke har implementert dem - ennå.

Så til slutt setter du deg ned en dag og sier 'La oss gjøre det!' Snart prøver du å finne ut hvordan du kan bruke applikasjonens forretningslogikk, drapsmodelfunksjonaliteten som kommer til å drive produktet fremover - du har en ide om hvordan du gjør det, og nå vet du at du kan gjøre det.

'Ferdig! Det fungerer!' du sier. Konseptbeviset ditt er en suksess! Alt som gjenstår å gjøre er å pakke det inn i en webapplikasjon.

'Ok, la oss lage nettstedet,' sier du.

Og så innser du sannheten: du må velge et programmeringsspråk; du må velge en plattform (moderne); du må velge noen rammer (moderne); du må konfigurere (og kjøpe) leverandører av plass, database og hosting; du trenger et administrasjonsgrensesnitt; du trenger et tillatelsessystem; du trenger en innholdsleder.

Du vil være kortfattet, du vil være smidig. Du vil bruke teknologier som vil hjelpe deg med å lykkes på kort og lang sikt. Og de er ikke alltid enkle å velge

Du har dusinvis og dusinvis av arkitektoniske beslutninger å ta. Og du vil ta de riktige: du vil bruke teknologier som gir deg rask utvikling, konstant iterasjon, maksimal effektivitet, hastighet, robusthet og mer. Du vil være kortfattet, du vil være smidig. Du vil bruke teknologier som vil hjelpe deg med å lykkes på kort og lang sikt. Og de er ikke alltid enkle å velge.

'Jeg er overveldet,' sier du mens du går bort og føler deg overveldet. Din energi er ikke den samme som før. Du prøver å passe brikkene sammen, men det er for mye arbeid.

Konseptbeviset ditt visner og dør sakte.

Forslaget

Etter å ha forlatt mange ideer på denne måten, bestemte jeg meg for å designe en løsning. Jeg kaller det prosjektet ' I det '(Start) (eller init.js).

Hjertet i ideen er å ha et enkelt prosjekt som starter alle de andre, la utvikleren eller den tekniske grunnleggeren ta disse beslutningene samtidig, og motta en passende mal for å komme i gang basert på disse beslutningene. Jeg vet hva de naysayers kommer til å si: 'En løsning kan ikke gjelde for alle problemer' (Hatere vil hate). Og de kan ha rett. Men vi kan prøve vårt beste for å lage en grov løsning, og jeg tror I det er nær nok.

For å bedre nå dette målet, må vi huske noen viktige ideer. Da jeg utviklet Init, vurderte jeg:

• Komponenter

  Modularisering er en nøkkelfunksjon i ethvert system, da det lar deg gjenbruke programvarekomponenter på tvers av forskjellige prosjekter - som er hovedmålet med I det . Men modularisering kommer også med en 'utskiftbarhet' etter produkt, som vil være vår beste allierte når vi angriper forskjellige typer problemer med 'nesten' den samme løsningen.

• Enkel utvikling

  For noen problemer er det et bedre sted skrevet inn [Brainf * ck] (https://en.wikipedia.org/wiki/Brainfuck). eller faen hjerner). Men implementer den løsningen (i Brainf * uck ) ville være nesten umulig å skrive, enn si å lese. Det vil koste deg tid og en enorm innsats. Generelt sett bør du bruke språk og plattformer som gjør utviklingen enkel, og ikke vanskelig for deg (eller noen som kan jobbe med det senere).

• Samfunnet

  Uansett hvilken plattform du velger, må du sørge for at det har et flott fellesskap og et som kan hjelpe deg med de vanligste og mindre vanlige problemene. Husk: jQuery er kanskje ikke mest rask , det meste ren , eller det fineste - men det er en vinner bare på grunn av det samfunnet .

Med disse målene i tankene skal jeg vise deg hvordan jeg tok mine egne beslutninger når jeg skapte I det .

I sin kjerne utnytter Init den full-stack JavaScript (Noen refererer til ham, eller en del av ham, som BETYD Stack ). Når du arbeider med dette settet, I det er i stand til å bruke bare ett språk mens du skaper et utrolig fleksibelt og fullverdig miljø for utvikling av webapplikasjoner. Oppsummert, I det lar deg bruke JavaScript ikke bare for klient- og serversideutvikling, men også for bygging, testing, layout og mer.

Men la oss avta litt og spør oss selv: er JavaScript virkelig en god idé?

Hvorfor valgte jeg JavaScript

Jeg har vært webutvikler siden 1998. På den tiden brukte vi Perl for det meste av serverutviklingen vår, og til og med da hadde vi JavaScript på klientsiden. Serverteknologiene på serversiden har endret seg enormt siden den gang: vi gikk gjennom bølge etter bølge av forskjellige teknologier og språk som PHP, ASP, JSP, .NET, Ruby, Python, for bare å nevne noen. Utviklere begynte å innse at bruk av to forskjellige språk i klient- og servermiljøer var kompliserende. De første forsøkene på å forene seg under ett språk prøvde å lage klientkomponenter på serversiden og kompilere dem til JavaScript. Dette fungerte ikke som forventet, og mange av disse prosjektene mislyktes (for eksempel å erstatte ASP MVC ASP.NET webskjemaer , og det kan sies det GWT vil bli erstattet av Polymer ). i nær fremtid). Men det var i utgangspunktet en utmerket idé: et enkelt språk på klienten og serveren, slik at vi kunne gjenbruke komponenter og ressurser (dette er nøkkelen: ressurser ).

Svaret var enkelt: bruk JavaScript på serveren.

Faktisk ble JavaScript født med JavaScript-serversiden på Netscape Enterprise Server, men språket var bare ikke klart den gangen. Etter år med prøving og feiling, Node.js til slutt dukket opp, som ikke bare satte JavaScript på serveren, men også fremmet ideen om ikke-blokkerende programmering , endre måten vi skriver “fread” (I / O) for alltid (les mer her .

I en setning: ikke-blokkerende planlegging tar sikte på å legge tidkrevende oppgaver til side, vanligvis angi hva som skal gjøres når disse oppgavene er fullført, og la prosessoren kunne håndtere andre forespørsler i mellomtiden.

Men disse ideene var ikke nye - så hvorfor ble de så populære hos Node.js? Enkel, ikke-blokkerende programmering kan oppnås på flere måter. Det enkleste er kanskje å bruke tilbakeringinger og a loop-hendelse . På de fleste språk er det ikke en enkel oppgave: mens tilbakeringing er en vanlig funksjon på noen språk, er det ikke en looping-begivenhet, og du holder deg vanligvis til eksterne biblioteker (f.eks. Python, med Twister ). Men i JavaScript, tilbakeringinger er innebygd i språket, så vel som hendelsessløyfen, og nesten alle programmerere som har dabbled i JavaScript er kjent med dem (eller i det minste har brukt dem, skjønt forstår ikke helt hva en looping-hendelse betyr ). Plutselig kan hver av oppstartene på Planet Earth gjenbruke utviklere (f.eks. Ressurser) både på klientsiden og på serversiden, og løse problemet 'Python Guru Needed' .

Plutselig kunne hver oppstart på Planet Earth gjenbruke utviklere (f.eks. Ressurser) både på klientsiden og på serversiden, og løste problemet 'Python Guru Needed'.

Så nå har vi en lynrask plattform (takket være ikke-blokkerende programmering) med et programmeringsspråk som er utrolig enkelt å bruke (takket være JavaScript). Men er det nok? Vil det vare? Jeg er sikker på at JavaScript kommer til å ha en viktig plass i fremtiden. La meg fortelle deg hvorfor:

• Funksjonell programmering

  JavaScript var det første programmeringsspråket ledet det funksjonelle paradigmet til massene (selvfølgelig kom Lisp først, men de fleste utviklere har aldri bygget en Lisp-applikasjon klar for produksjonsbruk). Lisp og selv, Javascript viktigste påvirkninger , de er fulle av innovative ideer. Disse ideene kan frigjøre våre sinn til å utforske nye teknikker, mønstre og paradigmer. Og de fører alle til JavaScript. Se monader , Kirkekoding , eller til og med (for et mer praktisk eksempel) samling av funksjoner] (http://underscorejs.org/#collections), fra Underscore.js som kan spare deg for linjer og kodelinjer.

• Dynamiske gjenstander og prototypet arv

  Klasseløs objektorientert programmering (og uten endeløse klassearv) tillater rask utvikling (opprett objekter, legg til metoder og bruk dem), men viktigst, reduserer refactoringstiden under vedlikeholdsoppgaver ved å la utvikleren endre forekomster av objekter i stedet for klasser. Denne hastigheten og fleksibiliteten baner vei for rask utvikling.

• JavaScript det internett

  JavaScript var designet for internett , det har vært her siden begynnelsen, og kommer ikke til å dra . Alle forsøk på å ødelegge den har mislyktes, se for eksempel fallet til Applets Java , erstatningen for VBScript for Microsoft, TypeScript (som er samlet til JavaScript), og Flash faller i hendene på mobilmarkedet og HTML5. Det er umulig å erstatte Javascript uten å bryte millioner av nettsider, så vårt langsiktige mål bør være å forbedre det. Og det er ingen bedre for den oppgaven enn ham Teknisk komité 39 av ECMA.

  OK, alternativer til JavaScript blir født hver dag, hvordan CoffeeScript , TypeScript , og de millioner av språkene som kompileres for JavaScript . Disse alternativene kan være nyttige i utviklingsstadier (gjennom kildekodetilordninger ), men de vil ikke etterligne JavaScript i det lange løp av to grunner: samfunnene deres vil aldri være større, og deres beste funksjonalitet vil bli vedtatt av ECMA-skriptet (f.eks. JavaScript). JavaScript er ikke som et monteringsspråk: det er et høyt nivå programmeringsspråk med kildekode du kan forstå - så bør du forstå.

Nå takk til Esprima-prosjekt , kan du lage dine egne verktøy for å leke med kildekoden, endre den, endre stilen, legge til kommentarer, instrumentering og alle slags ting du kan forestille deg når du spiller med Abstract Syntax Tree i programmet ditt som om du spilte med et DOM-tre.

End-to-end JavaScript: Node.js og MongoDB

Så det er grunnene til å bruke JavaScript. Nå skal jeg bruke JavaScript som en grunn til å bruke Node.js og MongoDB.

• Node.js

  Node.js er en plattform for å bygge raske og skalerbare nettverksapplikasjoner - det er egentlig det Node.js-nettstedet sier. Men Node.js er mer enn det: det er den foretrukne kjøretiden for alle applikasjoner med JavaScript I / O-tilgang. Selv om du ikke planlegger å skrive ditt hovedtjenerapplikasjon med Node.js, kan du bruke innebygde verktøy bygget på toppen av Node.js for å forbedre utviklingsprosessen. For eksempel: Mocha.js for enhetstesting, Grunt.js for automatiserte byggeoppgaver, eller til og med Braketter for å fullføre kodedigering.

  Så hvis du skal skrive server- eller klient-JavaScript-applikasjoner, bør du gjøre deg kjent med Node.js, fordi du trenger å bruke det daglig. Det er noen interessante alternativer ), men ingen av dem når til og med 10% av Node.js-fellesskapet.

• MongoDB

  MongoDB det er en database NoSQL basert på dokumenter som bruker JavaScript som spørrespråk, slik at JavaScript-plattformen kan fullføres helt fra start til slutt. Men det er ikke engang hovedårsaken til å velge denne databasen.

  MongoDB er en skjemafri database som lar objektene dine fortsette på en fleksibel måte og derfor tilpasse seg raskere til endrede krav. Videre er det høyt skalerbar Y basert på kartreduksjon , noe som gjør den egnet for datakrevende applikasjoner. MongoDB er så fleksibel at den kan brukes som en skjemafri dokumentdatabase, en relasjonsdatalager (selv om den mangler transaksjoner ), eller til og med nøkkelverdilagring for hurtigbufrede svar.

Servermodularisering med Express.js

Modularisering på serversiden er aldri lett. Men med Express.js (Y Connect.js ) kom ideen om ‘Mellomvare’ (eller mellomvare). Etter min mening er mellomvare den beste måten å definere komponenter på serveren. Hvis du vil sammenligne den med en kjent standard, kommer den ganske nær rør og filtre.

Den grunnleggende ideen er at komponenten din er en del av et rør. Rørledningen behandler forespørselen (input) og genererer et svar (output), men komponenten din er ikke ansvarlig for hele svaret. I stedet endrer du bare det du trenger, og delegerer deretter til det andre røret. Når det siste rørstykket er ferdig med prosessen, blir svaret sendt til klienten.

Vi refererer til disse 'rørstykkene' som 'mellomvare'. Det er klart at vi kan lage to typer mellomvare :

• Mellomliggende : De som behandler forespørselen og svaret, men ikke er helt ansvarlige for selve responsen, så de delegerer til neste mellomvare.

• Finaler : De som tar fullt ansvar i det endelige svaret. De behandler og endrer forespørselen og svaret, men de trenger ikke delegere til neste mellomvare. I praksis anbefales det uansett å delegere til en neste mellomvare for å tillate fleksibilitet i arkitekturen (f.eks. Legge til mer mellomvare senere), selv om den mellomvare ikke eksisterer (i så fall vil svaret gå direkte til klienten)

Som et konkret eksempel kan du vurdere en komponent 'administratorbruker' på serveren. Når det gjelder mellomvare, ville vi ha både sluttpunkter og mellommenn. For våre formål vil vi ha funksjoner som å opprette en bruker og oppføre brukere. Men før vi kan utføre disse handlingene, trenger vi våre mellomledd for autentisering (siden vi ikke ønsker forespørsler om å opprette uautentiserte brukere). Når vi har opprettet disse autentiseringsformidlene, kan vi ganske enkelt plugge dem inn hvor som helst vi vil gjøre en eksisterende ikke-autentiseringsfunksjon om til en med autentisering.

Enkeltsides applikasjoner

Prosjektet I det fokus på å skape applikasjoner med én side (SPA-applikasjoner) . Mange nettutviklere har blitt fristet mer enn en gang til å prøve å bygge SPAer. Jeg utviklet meg ved hjelp av flere (for det meste proprietære), og jeg kan trygt si at de rett og slett er fremtiden for webapplikasjoner. Har du noen gang sammenlignet et SPA med en vanlig webapplikasjon på en mobilforbindelse? Forskjellen i respons er titalls sekunder.

Har du noen gang sammenlignet et SPA med en vanlig webapplikasjon på en mobilforbindelse? Forskjellen i respons er titalls sekunder.

SPA er fremtiden på nettet - så hvorfor skulle du lage produktet ditt i en gammel form? Et vanlig argument jeg hører er at folk er bekymret for SEO. Men hvis du håndterer ting riktig, bør dette ikke være et problem: Google selv har en veldig bra opplæring om hvordan du gjør det, og det er veldig gode kommentarer her også.

MV * på klientsiden med Backbone.js, Marionette.js og Twitter Bootstrap

Mye er blitt sagt om MVC * rammer para SPAer . Det er en komplisert beslutning, men jeg vil si at topp 3 er det Backbone.js , Ember.js , Y Angular.js .

Alle tre er vel ansett. Men hvilken av dem er best for deg?

Dessverre må jeg innrømme at jeg har veldig begrenset erfaring med Angular.js, så jeg kommer til å la det være utenfor denne diskusjonen. Nå representerer Ember.js og Backbone.js to forskjellige måter å angripe det samme problemet på.

Backbone.js det er minimalistisk, forenklet og tilbyr deg nok til å lage et enkelt SPA. På den annen side er Ember.js et helt profesjonelt rammeverk for å lage SPAer. Det har mer frills, men også en større læringskurve.

Avhengig av størrelsen på søknaden din, kan beslutningen være like enkel som å se på forholdet mellom funksjonerBrukt / funksjonerTilgjengelig, noe som gir deg en god anelse.

I tilfelle av I det , Jeg ønsket å dekke de fleste scenarier, så jeg valgte Backbone.js for enkel SPA-oppretting, med Backbone.Marionette.View for modularisering. På denne måten er hver komponent en enkel applikasjon, og den endelige applikasjonen kan være så kompleks som vi vil ha den.

Styling er også en utfordring, men vi kan igjen ha rammer for å redde oss. For CSS er det ikke noe bedre enn Twitter Bootstrap , som tilbyr et komplett sett med stiler som er klare til bruk og er lett å tilpasse .

Booststrap ble opprettet ved hjelp av språket MINDRE som er åpen kildekode, slik at vi kan endre det hvis vi trenger det. Den kommer med massevis av brukervennlighetskontroller som er godt dokumentert på Bootstrap-siden . I tillegg er det en tilpasningsmodell som lar deg lage dine egne kontroller. Han er definitivt mannen for jobben.

Beste fremgangsmåter: Grunt.js, Mocha.js, Chai.js, RequireJS og CoverJS

Til slutt bør vi definere noen av våre beste fremgangsmåter, og se på hvordan Init kan hjelpe deg med å implementere og vedlikeholde dem. Løsningen vår er fokusert på flere verktøy, som er basert på Node.js.

• Mocha.js og Chai.js :

  Disse verktøyene lar deg forbedre utviklingsprosessen ved å søke TDD eller BDD , som gir infrastrukturen for å organisere enhetstester og en bærerakett for å kjøre dem automatisk.

  Det er Tusenvis av rammer for enhetstester for JavaScript. Så hvorfor bruke Mocha.js? Det korte svaret: det er fleksibelt og omfattende.

  Det lange svaret: det har to viktige funksjoner (grensesnitt, journalister) og ett viktig fravær ( påstander ). La meg forklare.

  • Grensesnitt : Kanskje du er vant til TDD-begreper i suiter og enhetstester, eller kanskje du foretrekker BDD-ideer om atferdsspesifikasjoner med “ beskriver 'Y' det burde ”. Mocha.js lar deg bruke begge tilnærminger.
  • Journalister : Å kjøre testen vil generere resultatrapporter, og du kan formatere resultatene ved hjelp av forskjellige journalister. For eksempel, hvis du må mate en kontinuerlig integreringsserver, kan du finne en reporter som gjør akkurat det.
  • Mangel på et påstandsbibliotek :: Mocha.js var ikke et problem, og designet slik at du kan bruke påstandsbiblioteket du ønsker, og tilby mer fleksibilitet. Det er Mange alternativer , men det er her Chai.js spiller inn.

  Chai.js er et fleksibelt påstandsbibliotek som lar deg bruke en av de tre viktigste stilene av påstander:

  • Påstå : Klassisk påstandsstil på old school. Eks.:

    assert.equal(variable, ”valor”);

  • Forvent : Type kjedbar påstand som er mest brukt i BDD. Eks.:

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

  • Bør : Brukes også i BDD, men jeg foretrekker Expect fordi Should fordi det høres repeterende ut med _'it _ atferdsspesifikasjonen ('should do something ..' - 'that should do something'). Eks.:

    variable.should.equal(“valor”);

  Chai.js passer perfekt sammen med Mocha.js. Ved å bruke bare disse to bibliotekene kan du skrive testene dine i TDD, BDD eller hvilken som helst stil du kan tenke deg.

• Grunt.js :

  Grunt.js lar deg automatisere byggeoppgaver, alt fra enkle kopierte og limte sammenkoblede filer, til forhåndskompilerte maler, kompilert språkstil (f.eks. SASS og LESS), enhetstesting (med mocha.js), linting og komprimering av kode (f.eks. med UglifyJS eller Closure Compiler ). Du kan legge til din egen automatiserte oppgave i Grunt, eller søke i gryntelogg , der det er hundrevis og hundrevis av plugins tilgjengelig (igjen, det er bra å bruke verktøy med store samfunn bak). Grunt kan også overvåke filene dine og utløse handlinger når de endres.

• KrevJS :

  RequireJS kan høres ut som en annen måte å laste moduler på AMD , men jeg kan forsikre deg om at det er mye mer enn det. For å forstå hvorfor, må vi først nevne ideen om modulnavnavstand (f.eks. Demo.views.hello), som unngår å forurense det globale navnområdet ved å pakke hver modul i sitt eget navneområde. Problemet er at disse modulene ikke kan brukes på nytt: Hvis du endrer navneområdet til en 'forekomst', endrer du navnefeltet til alle 'forekomster'. I motsetning til det lar RequireJS deg definere gjenbrukbare moduler fra bunnen av. (Det vil også hjelpe deg å adoptere Avhengighetsinjeksjon til hindre modulene dine i å få tilgang til globale variabler ).

• CoverJS :

  Kodedekning det er et mål å evaluere testingen din. Som navnet antyder, forteller den deg hvor mye kode som dekkes i din nåværende testpakke. CoverJS måler kodedekningen av testene dine ved å instrumentere utsagn (i stedet for kodelinjer som JSCoverage ) og generere en instrumentert versjon av koden din. Det genererer også rapporter for å mate serveren din kontinuerlig integrering .

Bruker _Branches_ (_ramas_) til å bytte funksjoner

Da jeg begynte I det Jeg trengte en måte for brukere å slå forskjellige funksjoner på og av som de måtte ønske seg i prosjektet. Jeg bestemte meg for å ta en radikal tilnærming med gits forgreningssystem for å implementere denne funksjonaliteten.

I hovedsak representerer hver gren en funksjon eller funksjonalitet som en bruker kanskje vil ha med. Hvis du starter et prosjekt fra bunnen av, start med den minste grenen du trenger, og legg deretter til andre teknologier ved å slå sammen grenen med de andre ønskede. La oss for eksempel si at du vil starte prosjektet med Backbone.js og Marionette.js. Vel, du kan starte på Backbone.js-grenen og slå den sammen med Marionette-grenen, og fortsette derfra for hver funksjonalitet du vil legge til.

Foreløpig kan ideen om å slå seg sammen for å legge til funksjonalitet bare brukes til teknologimaler (f.eks. Backbone, Node, Express). Men i fremtiden vil du kunne bytte mellom back-end (f.eks. Fra MongoDB til Postgres) og implementeringer på klientsiden.

Start et prosjekt med Init og distribuer på Heroku i dag

Det har aldri vært en enklere måte å starte et prosjekt på. Gå til GitHub-depot , sjekk filialen med de siste forpliktelsene (akkurat nå er det brukerstyring, selv om dette kan endre seg i fremtiden) og deretter:

1. Lag en katalog for prosjektet ditt (eller bruk en eksisterende).
2. Opprett depotet ditt med 'git init' (eller bruk et eksisterende depot)

3. Legg til en ekstern server med Init

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

4. Last ned filialen du ønsker

   git pull init usermanager

5. Skaff deg Heroku-prosessfilen

   git pull init heroku-webprocess

6. Med Heroku Toolbelt installert, opprett en app

   heroku create

7. Skyv mastergrenen til Heroku

   git push heroku master
8. Besøk applikasjonen din som kjører på Heroku!

Nå kan du begynne å utvikle drapefunksjonen din med bare noen få linjer med kode. Ikke bare det, men du vil utvikle deg med de nyeste og mest effektive teknologiene i en utviklingspakke som er så automatisert som mulig.

Håper du kan bruke I det for å starte din neste gode idé. Husk å sjekke Init repository for reparasjoner og funksjoner - utviklingen er ganske aktiv, og jeg ser frem til å høre din tilbakemelding.

Innhold oversatt av Pablo Fabregat, medlem av TransBunko , et marked for tekniske oversettelser.