Historien

Så du og partneren din hadde denne gode ideen for en bedrift, ikke sant?

Du har lagt til funksjonalitet i systemet mentalt.

Du spør ofte potensielle kunder hva de synes, og de elsker det alle sammen.

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

Så du setter deg endelig ned en dag og sier 'La oss gjøre dette!' Så du prøver å finne ut hvordan du kan implementere applikasjonens forretningslogikk, drapsmannfunksjonen som tar produktet videre: du har en ide om hvordan du gjør det, og du kjenner deg kan gjøre.

'Ferdig! Det fungerer! ”, Sier du. Konseptbeviset ditt er en suksess! Alt som mangler er emballasje 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 (moderne) plattform; du må velge noen (moderne) rammer; du må kjøpe (og konfigurere) lagring, databaser og hostingleverandører; du trenger et administrativt grensesnitt; du trenger et tillatelsessystem; du trenger en innholdsleder.

Du vil at det skal være lett, 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 beslutningene: Du vil bruke teknologier som muliggjør rask utvikling, konstant iterasjon, maksimal effektivitet, hastighet, robusthet og mer. Du vil at det skal være lett, 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 og føler meg veldig overveldet. Energien din er ikke lenger den samme. Du prøver å sette brikkene sammen, men det er for mye arbeid.

Konseptbeviset ditt tørker sakte opp og dør.

Forslaget

Etter å ha forlatt utallige ideer selv, bestemte jeg meg for å bygge en løsning. Jeg kaller det et prosjekt ‘ I det ’(Ou, init.js).

Den sentrale delen av ideen er å ha et enkelt prosjekt for å starte dem alle, slik at utvikleren eller den tekniske grunnleggeren kan ta alle disse viktige beslutningene samtidig, og motta en mal passende innledende grunnlag basert på disse beslutningene. Jeg vet hva motstandere vil si: 'en løsning kan ikke brukes på alle slags problemer' (hatere vil hate). Og de kan ha rett. Men vi kan gjøre vårt beste for å lage en passende løsning, og jeg tror Init kommer i nærheten.

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

• Komponenter

  Komponentisering er en nøkkelfunksjon i ethvert system, da det tillater gjenbruk av programvarekomponenter i forskjellige prosjekter - som er hovedmålet for Init. Men komponentisering kommer også med et biprodukt, 'utskiftbarhet', som vil være vår beste allierte i å takle flere forskjellige problemer med 'nesten' den samme løsningen.

• Enkel utvikling

  For noen problemer, er det noen som har en bedre løsning skrevet inn Brainf * ck . Men å implementere denne løsningen (i Brainfuck) vil være praktisk talt 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 enklere, ikke vanskeligere for deg (eller noen som kan jobbe med det senere).

• Samfunnet

  Uansett hvilken plattform du velger, må du sørge for at du har et stort fellesskap og en som kan hjelpe deg med de vanligste og uvanlige problemene. Husk: jQuery er kanskje ikke biblioteket raskere , renere , eller mer elegant - men det er en vinner bare på grunn av sin samfunnet .

Med tanke på disse målene vil jeg vise deg hvordan jeg tok mine beslutninger når jeg opprettet Init.

I sin kjerne utnytter Init den “paradigmet” full-stack JavaScript ’Paradigm (noen refererer til det, eller en delmengde av det, som BETYD stack ). Når du arbeider med en slik stabel, er Init i stand til å bruke et enkelt språk mens det skaper et utrolig fleksibelt og funksjonsrikt miljø for utvikling av webapplikasjoner. Kort sagt, det lar deg bruke JavaScript ikke bare for klient- og serverutvikling, men også for å bygge, teste, lage maler og mer.

Men la oss senke farten et øyeblikk og spør oss selv: er det virkelig en god idé å bruke JavaScript?

Hvorfor jeg valgte JavaScript

Jeg er webutvikler siden 1998. Der borte vi Perl for mest utvikling på serversiden, men selv da hadde vi JavaScript på klientsiden. Teknologier for webservere har endret seg enormt siden den gang: vi har passert bølge etter bølge av språk og teknologier som PHP, ASP, JSP, .NET, Ruby, Python, for å nevne noen. Utviklere begynte å innse at bruk av to forskjellige språk for klient- og servermiljøene var kompliserende. Første forsøk på å forene under ett enkelt språk var rettet mot å opprette klientkomponenter på serveren og kompilere dem for JavaScript. Dette fungerte ikke som forventet, og de fleste prosjekter mislyktes (for eksempel: ASP MVC erstattet ASP.NET webskjemaer , er GWT uten tvil blir erstattet i nær fremtid av Polymer ). Men det var en god idé: et enkelt språk på klienten og på serveren, slik at vi kunne bruke komponenter og ressurser på nytt (dette er stikkordet: ressurser ).

Svaret var enkelt: plasser JavaScript ikke server.

JavaScript ble faktisk [født med JavaScript-serversiden] (http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969) på Netscape Enterprise Server, men språket var bare ikke klart På den tiden. Etter år med prøving og feiling, har Node.js endelig dukket opp, som ikke bare satte JavaScript på serveren, men også fremmet ideen om programmering ikke-blokkerende , for alltid å endre måten vi skriver en “fread” (I / O) -lesning på her for å vite mer).

I en setning: ikke-blokkerende programmering tar sikte på å legge tidkrevende oppgaver til side, og generelt spesifisere hva som skal gjøres når disse oppgavene er fullført, og la prosessoren kunne håndtere andre forespørsler mens dette ikke skjer.

Men disse ideene var ikke nye - så hvorfor ble de så populære blant Node.js? Enkel, ikke-blokkerende programmering kan oppnås på flere måter. Det enkleste er kanskje å bruke tilbakeringinger og a hendelsessløyfe . På de fleste språk er dette ikke en lett oppgave: mens ‘tilbakeringing’ er et vanlig trekk på andre språk, er det ikke en hendelsessløyfe, og du vil ofte oppleve at du sliter med eksterne biblioteker (for eksempel: Python, med Twister ). Men i JavaScript, tilbakeringinger de er innebygd i språket, akkurat som begivenhetsløkker, og nesten alle programmerere som har berørt JavaScript er kjent med dem (eller i det minste brukt dem, selv om forstår egentlig ikke hva en hendelsessløyfe er ). Plutselig kunne hver oppstart på jorden gjenbruke utviklere (det vil si ressurser) på både klient- og serversiden, jobbtilbudsproblem : “Vi søker Guru i Python”.

Plutselig kunne hver oppstart på jorden gjenbruke utviklere (det vil si ressurser) både på klient- og server-siden, og løse problemet med jobbtilbudet: 'Vi ser etter en Python Guru'.

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

• Funksjonell programmering

  JavaScript var det første programmeringsspråket for å bringe det funksjonelle programmeringsparadigmet for massene (selvfølgelig kom Lisp først, men de fleste programmerere bygde aldri applikasjoner for produksjonsmiljøer ved hjelp av Lisp). Lisp og selv, viktigste påvirkninger av Javascript , er fulle av innovative ideer. Disse ideene kan frigjøre våre sinn til å utforske nye teknikker, mønstre og paradigmer. Og de tar alle JavaScript. Se på monader , Kirkenumre , eller til og med (for et mer reelt eksempel) funksjonene av samlinger gjøre Underscore.js , som kan spare deg for linjer og kodelinjer.

• Dynamiske gjenstander og prototype arv

  Klasseløs objektorientert programmering (og ingen endeløs klassehierarki) muliggjør rask utvikling (opprette objekter, legge til metoder og bruke dem), men, enda viktigere, reduserer refactoringstiden under vedlikeholdsoppgaver ved å la programmereren endre objektforekomster i stedet for klasser. Denne hastigheten og fleksibiliteten baner vei for rask utvikling.

• JavaScript er Internett

  JavaScript var designet for internett , har vært her siden begynnelsen, og vil ikke forsvinne . Alle forsøk på å ødelegge det har mislyktes: se for eksempel høsten til Java Applets , erstatter VBScript med Microsofts TypeScript (som kompilerer for JavaScript), og Flashs død i hendene på mobil- og HTML5-markedet. Det er umulig å erstatte JavaScript uten å bryte millioner av nettsider, så våre mål bør være å forbedre det. Og det er ingen bedre for jobben enn Teknisk komité 39 til ECMA.

  Ok, alternativer til JavaScript blir født hver dag, for eksempel CoffeeScript , TypeScript og som millioner av språk som kompilerer for JavaScript . Disse alternativene kan være nyttige i utviklingsstadier ( via kildekart ), men de klarer ikke å erstatte JavaScript i det lange løp av to grunner: fellesskapet deres vil aldri bli større, og deres beste funksjoner vil bli vedtatt av ECMA-skriptet (dvs. JavaScript). JavaScript er ikke et monteringsspråk: det er et programmeringsspråk på høyt nivå med kildekode du kan forstå - så du bør forstå det.

Nå takk til Esprima-prosjekt , kan du lage dine egne verktøy for å leke med kildekoden, endre den, endre stilen, legge til komponenter, instrument og alle slags ting du kan forestille deg, spille med Abstract Syntax Tree, på engelsk) i programmet ditt som om du jobbet 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 - dette er ganske mye hva Node.js-nettstedet sier. Men Node.js er viktigere enn dette: det er det foretrukne kjøretidsmiljøet for alle JavaScript-applikasjoner med tilgang til I / O. Selv om du ikke planlegger å skrive hovedserverapplikasjonen din med Node.js, kan du bruke 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 redigering full tekst av kode.

  Så hvis du skal skrive JavaScript-applikasjoner for serveren eller klienten, bør du bli kjent med Node.js, fordi du må 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 jeg kan fullføre plattformen med end-to-end JavaScript.

  MongoDB er en database uten skjema som lar deg vedvare objekter på en fleksibel måte og derfor tilpasse seg raskere til endrede krav. Dessuten er det høyt skalerbar er basert på kartreduksjon , noe som gjør den egnet for applikasjoner med store data. MongoDB er så fleksibel at den kan brukes som en skjemafri database, som relasjonslagring (selv om den ikke støtter transaksjoner ), eller til og med som en nøkkelverdilager for hurtigbufring av svar.

Serverkomponentisering med Express.js

Serverside-komponentisering er aldri lett. Men med Express.js (og Connect.js) kom ideen om ‘middleware’. Etter min mening er mellomvare den beste måten å definere komponenter på serveren. Hvis du vil sammenligne med en kjent standard, er den veldig nær rør og filtre.

Den grunnleggende ideen er at komponenten din er en del av en rørledning (et rør). Rørledningen behandler en forespørsel (innkommende) og genererer et svar (utgående), men komponenten er ikke ansvarlig for hele svaret. I stedet endrer han bare det han trenger og delegerer det til neste del av rørledningen. Når den siste delen av rørledningen er ferdigbehandlet, sendes svaret tilbake til kunden.

Vi refererer til disse ‘stykker av rørledningen’ (stykke rør) som ‘mellomvare’. Det er klart at vi kan lage to typer mellomvare:

• Mellommenn : de som behandler forespørselen og svaret, men ikke er fullt ansvarlige for selve svaret, delegerer deretter til neste mellomvare.

• Finaler : de med fullt ansvar for det endelige svaret. De behandler og endrer forespørselen og svaret, men trenger ikke delegere til neste mellomvare. I praksis anbefales det at du delegerer til neste mellomvare uansett for å tillate arkitektonisk fleksibilitet (det vil si legge til mer mellomvare senere), selv om den mellomvare ikke eksisterer (så i dette tilfellet går svaret rett til klienten).

Som et konkret eksempel kan du vurdere en “administrerende bruker” -komponent på serveren. Når det gjelder mellomvare, ville vi ha både sluttpunkter og mellomledd. For våre avslutninger vil vi ha funksjoner som å opprette en bruker og oppføre brukere. Men før vi kan utføre slike handlinger, trenger vi mellomleddene våre for autentisering (siden vi ikke vil at uautentiserte forespørsler skal legges inn og opprette brukere). Når disse autentiseringsformidlene er opprettet, kan vi bare plugge dem inn hvor vi vil lage en tidligere uautentisert funksjon til en autentisert funksjon.

Enkeltsides applikasjoner

Init-prosjektet fokuserer på å skape applikasjoner med én side (SPA’s: Single Page Application) . De fleste nettutviklere har blitt lokket til å prøve å bruke SPAer. Jeg bygde flere (for det meste proprietære), og jeg kan med overbevisning si at de rett og slett er fremtiden for webapplikasjoner. Har du noen gang sammenlignet et SPA med en tradisjonell webapplikasjon over en mobilforbindelse? Forskjellen i responstid er i størrelsesorden ti titalls sekunder.

Har du noen gang sammenlignet et SPA med en tradisjonell webapplikasjon over en mobilforbindelse? Forskjellen i responstid er i størrelsesorden ti titalls sekunder.

SPA er internettets fremtid - så hvorfor skulle du bygge produktet ditt på en eldre måte? Et vanlig argument jeg hører er at folk er opptatt av SEO (søkemotoroptimalisering, søkemotoroptimalisering). Men hvis du behandler ting riktig, bør dette ikke være et problem: Google selv har en veldig god opplæring om hvordan du gjør det, og det er noen gode kommentarer her også.

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

Mye er blitt sagt om rammer MVC * para SPA’s . Det er et vanskelig valg, men jeg vil si at de 3 beste er Backbone.js , Ember.js , er Angular.js .

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

Dessverre må jeg innrømme at jeg har svært begrenset erfaring med Angular.js, så jeg vil la deg 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 gir deg nok til å lage et enkelt SPA. Ember.js, derimot, er et komplett og profesjonelt rammeverk for å lage SPAer. Den har flere attraksjoner, men også en lengre læringskurve.

Avhengig av størrelsen på applikasjonen din, kan avgjørelsen være like enkel som å analysere frekvensen av funksjoner som brukes mot tilgjengelige funksjoner, noe som vil gi deg en god ide.

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

Stil er også en utfordring, men vi kan igjen stole på rammer for å hjelpe oss. For CSS er det ikke noe bedre enn Twitter Bootstrap , som tilbyr et komplett sett med bruksklare stiler og lett å tilpasse .

Bootstrap ble opprettet ved hjelp av språket MINDRE og det er gratis programvare, slik at vi kan endre det hvis vi trenger det. Den leveres med mange brukergrensesnittkontroller som er godt dokumentert på Bootstrap-nettstedet . PE ennå, det er en tilpasningsmodell som lar deg lage din egen Bootstrap. Han er definitivt den rette fyren 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 hvordan Init kan hjelpe deg med å implementere og vedlikeholde dem. Løsningen vår er sentrert på flere verktøy, som igjen er basert på Node.js.

• Mocha.js er Chai.js :

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

  Det er tusenvis av rammer for enhetstesting for JavaScript. Så hvorfor bruke Mocha.js? Kort svar: det er fleksibelt og komplett.

  Langt svar: den har to viktige egenskaper (grensesnitt, journalister) og et betydelig fravær: påstander. La meg forklare.

  • Grensesnitt : Kanskje du er kjent med TDD-begreper som suiter og enhetstester, eller kanskje du foretrekker BDDs atferdsspesifikasjonsideer med 'beskriv' og 'det skal'. Mocha.js lar deg bruke begge tilnærminger.

  • Journalister : Å kjøre testen vil generere resultatrapporter, og du kan formatere disse resultatene ved hjelp av flere journalister. Hvis du for eksempel trenger å drive en kontinuerlig integreringsserver, kan du finne en reporter som kan gjøre nettopp det.

  • Mangel på et bibliotek med påstander : langt fra å være et problem, Mocha.js ble designet for å tillate deg å bruke påstandsbiblioteket du valgte, noe som gir deg enda mer fleksibilitet. Det er rikelig med alternativer , men det er her Chai.js kommer inn i feltet.

  Chai.js er et fleksibelt påstandsbibliotek som lar deg velge mellom tre hovedformål:

  • Påstå : Klassisk stil med tradisjonell TDD-påstand. Eksempel:

    assert.equal(variavel, 'valor');

  • Forvent : Kjedbar påstandstilstand, mest brukt i BDD. Eksempel:

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

  • Bør : Brukes også i BDD, men jeg foretrekker Expect fordi det skal høres repeterende ut med atferdsspesifikasjonen ‘it (“ should do something .. ”)’. Eksempel:

    variavel.should.equal ('valor');

  Chai.js passer perfekt til Mocha.js. Ved å bruke bare disse tre 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 enkel kopiering og liming og filkombinasjon, til malkompilering, kompilering av stilspråk (dvs. SASS og LESS), enhetstesting (med mocha.js), linting og kode minifisering (for eksempel med UglifyJS eller Closure Compiler ). Du kan legge til din egen automatiserte oppgave i Grunt, eller søke i Gruntregister ,, der det er hundrevis og hundrevis av plugins tilgjengelig (husk: bruk av verktøy med store samfunn bak lønner seg). Grunt kan også overvåke filene dine og utløse handlinger når de endres.

• KrevJS :

  RequireJS kan høres ut som bare 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 (for eksempel demo.views.hello), som unngår å forurense det globale navneområ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 dette lar RequireJS deg definere gjenbrukbare moduler fra begynnelsen. I tillegg vil det hjelpe deg å adoptere Avhengighetsinjeksjon til unngå at modulene dine får tilgang til globale variabler .)

• CoverJS :

  Kodedekning er en beregning for å evaluere testene dine. Som navnet antyder, forteller dette deg hvor mye av koden din som dekkes av den nåværende testpakken. CoverJS måler kodedekningen av testene dine ved å instrumentere utsagn (i stedet for kodelinjer som JSCoverage ) i koden din og generere en instrumentert versjon av koden din. Du kan også generere rapporter for å mate serveren din Kontinuerlig integrering .

Bruke filialer for å velge funksjoner

Da jeg startet Init, trengte jeg en måte for brukere å aktivere og deaktivere ulike funksjoner de måtte ønske seg i prosjektene sine. Jeg bestemte meg for å ta det radikale trinnet med å bruke gits filialsystem 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 på den minste grenen du trenger, og legg deretter til andre teknologier ved å slå sammen med de ønskede grenene. La oss for eksempel si at du vil starte prosjektet med Backbone.js og Marionette.js. Vel, du kan starte med Backbone.js-grenen og slå den sammen med Marionette-grenen, og fortsette for hvert stykke funksjonalitet du vil legge til.

Foreløpig kan denne ideen om sammenslåing for å legge til funksjonalitet bare brukes til teknologimaler (for eksempel: Backbone, Node, Express). Men i fremtiden vil du kunne bytte mellom back-end-implementeringer (for eksempel fra MongoDB til Postgres) og klient.

Start et prosjekt med Init og distribuer Heroku Today

Det har aldri vært en enklere måte å starte et prosjekt på. Bare gå til depot på GitHub , sjekk filialen med de siste forpliktelsene (dette er brukerstyringen, selv om det kan endres i fremtiden) og deretter:

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

3. Legg til en fjernkontroll med init

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

4. Last ned Heroku-prosessfilen

   git pull init usermanager

5. Med Heroku Toolbelt installert, opprett et Heroku-program

   git pull init heroku-webprocess

6. Som Heroku Toolbelt installert, opprett et Heroku-program

   heroku create

7. Skyv mastergrenen din 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å kodelinjer. Ikke bare det, men du vil utvikle deg med de nyeste og mest effektive teknologiene i en utviklingspakke som er så automatisert som den kunne være.

Jeg håper du kan bruke I det for å starte din neste store idé. Husk å sjekke Init-depotet for nye reparasjoner og funksjoner - utviklingen er veldig aktiv, og jeg ser frem til dine kommentarer.

Innhold oversatt av Eduardo Kienetz, medlem av Transbrunko , et marked for tekniske oversettelser.