Init.js: Ein Leitfaden zum Warum und Wie von Full-Stack-JavaScript

Die Geschichte

Sie und Ihr Mitgründer haben also diese großartige Geschäftsidee, richtig?

Sie haben in Gedanken Funktionen hinzugefügt.

Häufig fragen Sie potenzielle Kunden nach ihrer Meinung, und alle lieben es.

Ok, die Leute wollen es also. Es gibt sogar etwas Geld zu verdienen. Und der einzige Grund, warum sie es nicht haben können, ist, dass Sie es noch nicht implementiert haben.

Also setzt du dich eines Tages hin und sagst: „Lass es uns tun!“ Bald versuchen Sie herauszufinden, wie Sie die Geschäftslogik Ihrer App implementieren können, das Killer-Feature, das das Produkt vorantreiben wird: Sie haben eine Vorstellung davon, wie es geht, und Sie wissen, dass Sie es tun können.

"Getan! Es klappt!" du sagst. Ihr Proof of Concept ist ein Erfolg! Alles, was übrig bleibt, ist, es in eine Web-App zu packen.

„Ok, lass uns die Seite erstellen“, sagst du.

Und dann erkennen Sie die Wahrheit: Sie müssen eine Programmiersprache wählen; Sie müssen eine (moderne) Plattform wählen; Sie müssen einige (moderne) Frameworks auswählen; Sie müssen Speicher, Datenbanken und Hosting-Anbieter konfigurieren (und kaufen); Sie benötigen eine Admin-Oberfläche; Sie brauchen ein Berechtigungssystem; Sie brauchen einen Content-Manager.

Sie müssen zig architektonische Entscheidungen treffen. Und Sie möchten die richtigen erstellen: Sie möchten Technologien verwenden, die eine schnelle Entwicklung, ständige Iteration, maximale Effizienz, Geschwindigkeit, Robustheit und mehr ermöglichen. Sie wollen schlank sein, Sie wollen agil sein. Sie wollen Technologien einsetzen, die Ihnen kurz- und langfristig zum Erfolg verhelfen. Und sie sind nicht immer leicht zu erkennen.

„Ich bin überwältigt“, sagst du, wenn du dich überwältigt fühlst. Deine Energie ist nicht mehr so ​​wie sie einmal war. Sie versuchen, die Dinge zusammenzusetzen, aber es ist zu viel Arbeit.

Ihr Proof of Concept verkümmert langsam und stirbt.

Der Antrag

Nachdem ich auf diese Weise selbst unzählige Ideen aufgegeben hatte, beschloss ich, eine Lösung zu entwickeln. Ich nenne es das 'Init'-Projekt (oder init.js).

Der Kern der Idee ist, ein einziges Projekt zu haben, um sie alle zu starten, den Entwickler oder den technischen Gründer alle diese wesentlichen Entscheidungen auf einmal treffen zu lassen und basierend auf diesen Entscheidungen eine geeignete Startvorlage zu erhalten. Ich weiß, was Kritiker sagen werden: „Eine Lösung kann nicht für jedes Problem gelten“ (Hasser werden hassen). Und sie könnten Recht haben. Aber wir können unser Bestes tun, um eine ungefähre Lösung zu erstellen, und ich denke, Init kommt dem ziemlich nahe.

Um dieses Ziel bestmöglich zu erreichen, müssen wir einige Schlüsselideen im Hinterkopf behalten. Bei der Entwicklung von Init habe ich Folgendes berücksichtigt:

• Komponenten

  Die Komponentenisierung ist ein Schlüsselmerkmal jedes Systems, da es Ihnen ermöglicht, Softwarekomponenten über verschiedene Projekte hinweg wiederzuverwenden – was das Hauptziel von Init ist. Aber die Komponentisierung bringt auch ein Nebenprodukt mit sich, die „Ersetzbarkeit“, die unser bester Verbündeter sein wird, wenn es darum geht, mehrere unterschiedliche Probleme mit „fast“ derselben Lösung anzugehen.

• Leichtigkeit der Entwicklung

  Irgendein Problem, irgendwo gibt es eine Lösung, am besten in Brainf*ck geschrieben. Aber die Implementierung dieser Lösung (in Brainfuck) wird fast unmöglich zu schreiben, geschweige denn zu lesen sein. Es kostet Sie Zeit und einen enormen Aufwand. Im Allgemeinen sollten Sie Sprachen und Plattformen verwenden, die die Entwicklung einfacher und nicht schwieriger für Sie (oder jeden, der später daran arbeiten könnte) machen.

• Gemeinschaft

  Für welche Plattform Sie sich auch entscheiden, stellen Sie sicher, dass es eine große Community gibt, die Ihnen bei den häufigsten und ungewöhnlichsten Problemen helfen kann. Denken Sie daran: jQuery ist vielleicht nicht die schnellste, sauberste oder eleganteste Bibliothek – aber nur wegen seiner Community ein Gewinner.

Unter Berücksichtigung dieser Ziele zeige ich Ihnen als Nächstes, wie ich meine eigenen Entscheidungen bei der Erstellung von Init getroffen habe.

Im Kern nutzt Init das „Full-Stack-JavaScript“-Paradigma (einige Leute bezeichnen es oder eine Teilmenge davon als MEAN-Stack). Durch die Arbeit mit einem solchen Stack ist Init in der Lage, nur eine einzige Sprache zu verwenden und gleichzeitig eine unglaublich flexible und voll funktionsfähige Umgebung für die Entwicklung von Web-Apps zu schaffen. Kurz gesagt, mit Init können Sie JavaScript nicht nur für die Client- und Serverentwicklung verwenden, sondern auch zum Erstellen, Testen, Erstellen von Vorlagen und mehr.

Aber lassen Sie uns einen Moment langsamer werden und uns fragen: Ist es wirklich eine gute Idee, JavaScript zu verwenden?

Warum ich mich für JavaScript entschieden habe

Ich bin seit 1998 Webentwickler. Damals verwendeten wir Perl für den größten Teil unserer serverseitigen Entwicklung, aber selbst seitdem hatten wir JavaScript auf der Clientseite. Webserver-Technologien haben sich seitdem enorm verändert: Wir haben eine Welle nach der anderen von Sprachen und Technologien wie PHP, AP, JSP, .NET, Ruby, Python durchlaufen, um nur einige zu nennen. Die Entwickler begannen zu erkennen, dass die Verwendung von zwei verschiedenen Sprachen für die Client- und Serverumgebungen die Dinge komplizierter machte. Die anfänglichen Versuche zur Vereinheitlichung unter einer einzigen Sprache versuchten, Clientkomponenten auf dem Server zu erstellen und sie in JavaScript zu kompilieren. Dies funktionierte nicht wie erwartet und die meisten dieser Projekte scheiterten (zum Beispiel: ASP MVC ersetzt ASP.NET-Webformulare und GWT wird wohl in naher Zukunft durch Polymer ersetzt). Aber es war im Wesentlichen eine großartige Idee: eine einzige Sprache auf dem Client und dem Server, die es uns ermöglicht, Komponenten und Ressourcen wiederzuverwenden (das ist das Schlüsselwort: Ressourcen ).

Die Antwort war einfach: Installieren Sie JavaScript auf dem Server.

JavaScript wurde tatsächlich mit JavaScript Server Side in Netscape Enterprise Server geboren, aber die Sprache war zu diesem Zeitpunkt einfach noch nicht bereit. Nach Jahren des Ausprobierens entstand schließlich Node.js, das nicht nur JavaScript auf den Server brachte, sondern auch die Idee der nicht blockierenden Programmierung förderte und die Art und Weise, wie wir einen „Fread“ (I/O) schreiben, für immer veränderte (lesen Sie hier für mehr).

Aber diese Ideen waren nicht neu – warum also wurden sie bei Node.js so beliebt? Eine einfache, nicht blockierende Programmierung kann auf verschiedene Weise erreicht werden. Am einfachsten ist es vielleicht, Rückrufe und eine Ereignisschleife zu verwenden. In den meisten Sprachen ist das keine leichte Aufgabe: Während „Callbacks“ in einigen anderen Sprachen ein gemeinsames Merkmal sind, ist eine Ereignisschleife dies nicht, und Sie finden sich oft mit externen Bibliotheken auseinander (z. B. Python mit Tornado). Aber in JavaScript sind Callbacks in die Sprache eingebaut, ebenso wie die Ereignisschleife, und fast jeder Programmierer, der sich auch nur mit JavaScript beschäftigt hat, ist damit vertraut (oder hat sie zumindest verwendet, auch wenn er nicht ganz versteht, was das Ereignis ist Schleife ist). Plötzlich konnte jedes Startup auf der Erde Entwickler (dh Ressourcen) sowohl auf der Client- als auch auf der Serverseite wiederverwenden, wodurch das „Python Guru Needed“-Stellenproblem gelöst wurde.

Jetzt haben wir also eine unglaublich schnelle Plattform (dank nicht blockierender Programmierung) mit einer Programmiersprache, die unglaublich einfach zu bedienen ist (dank JavaScript). Aber reicht es? Wird es dauern? Ich bin mir sicher, dass JavaScript in Zukunft einen wichtigen Platz einnehmen wird. Lassen Sie mich Ihnen sagen, warum:

• Funktionale Programmierung

  JavaScript war die erste Programmiersprache, die das funktionale Paradigma der Masse zugänglich machte (natürlich war Lisp zuerst da, aber die meisten Programmierer haben noch nie eine produktionsreife Anwendung mit Lisp erstellt). Lisp und Self, die Haupteinflüsse von Javascript, sind voller innovativer Ideen. Diese Ideen könnten unseren Geist befreien, um neue Techniken, Muster und Paradigmen zu erforschen. Und sie alle werden auf JavaScript übertragen. Werfen Sie einen Blick auf Monaden, Kirchennummern oder sogar (für ein praktischeres Beispiel) die Sammlungsfunktionen von Underscore.js, mit denen Sie Zeilen um Zeilen Code sparen können.

• Dynamische Objekte und prototypische Vererbung

  Die objektorientierte Programmierung ohne Klassen (und ohne endlose Klassenhierarchien) ermöglicht eine schnelle Entwicklung (Erstellen von Objekten, Hinzufügen von Methoden und deren Verwendung), verkürzt aber vor allem die Refactoring-Zeit während Wartungsaufgaben, indem es dem Programmierer ermöglicht, stattdessen Instanzen von Objekten zu ändern von Klassen. Diese Schnelligkeit und Flexibilität ebnet den Weg für eine rasante Entwicklung.

• JavaScript ist das Internet

  JavaScript wurde für das Internet entwickelt, es war von Anfang an da und wird nicht verschwinden. Alle Versuche, es zu zerstören, sind gescheitert: Siehe zum Beispiel den Niedergang von Java Applets, die Ersetzung von VBScript durch Microsofts TypeScript (das zu JavaScript kompiliert) und den Niedergang von Flash durch den Mobilmarkt und HTML5. Es ist unmöglich, Javascript zu ersetzen, ohne Millionen von Webseiten zu beschädigen, daher sollten unsere Ziele für die Zukunft darin bestehen, es zu verbessern. Und niemand ist besser für diesen Job geeignet als das Technische Komitee 39 von ECMA.

  Ok, Alternativen zu JavaScript werden jeden Tag geboren, wie CoffeeScript, TypeScript und die Millionen von Sprachen, die zu JavaScript kompiliert werden. Diese Alternativen könnten für Entwicklungsphasen (über Quellkarten) nützlich sein, aber sie werden JavaScript auf lange Sicht aus zwei Gründen nicht ersetzen: Ihre Communitys werden niemals größer sein und ihre besten Eigenschaften werden von ECMA-Skripten (d. h. JavaScript ). JavaScript ist keine Assemblersprache: Es ist eine höhere Programmiersprache mit Quellcode, den Sie verstehen können – also sollten Sie ihn verstehen.

End-to-End-JavaScript: Node.js und MongoDB

Das sind also die Gründe, JavaScript zu verwenden. Jetzt werde ich JavaScript als Grund für die Verwendung von Node.js und MongoDB verwenden.

• Node.js

  Node.js ist eine Plattform zum Erstellen schneller und skalierbarer Netzwerkanwendungen – das ist ziemlich genau das, was die Node.js-Site sagt. Aber Node.js ist mehr als das: Es ist die bevorzugte Laufzeitumgebung für jede JavaScript-Anwendung mit E/A-Zugriff. Auch wenn Sie nicht vorhaben, Ihre Hauptserveranwendung mit Node.js zu schreiben, können Sie Tools verwenden, die auf Node.js aufbauen, um Ihren Entwicklungsprozess zu verbessern. Zum Beispiel: Mocha.js für Unit-Tests, Grunt.js für automatisierte Build-Aufgaben oder sogar Brackets für die Volltext-Code-Bearbeitung.

  Wenn Sie also JavaScript-Anwendungen für den Server oder den Client schreiben, sollten Sie sich einige Node.js-Beispiele ansehen, da Sie es täglich benötigen und verwenden werden. Es gibt einige interessante Alternativen, aber keine davon macht auch nur 10 % der Node.js-Community aus.

• MongoDB

  MongoDB ist eine auf NoSQL-Dokumenten basierende Datenbank, die JavaScript als Abfragesprache verwendet, wodurch ich die End-to-End-JavaScript-Plattform vervollständigen kann. Aber das ist noch nicht einmal der Hauptgrund, sich für diese Datenbank zu entscheiden.

  MongoDB ist eine schemalose Datenbank, die es Ihnen ermöglicht, Ihre Objekte flexibel zu persistieren und sich so schneller an geänderte Anforderungen anzupassen. Außerdem ist es hochgradig skalierbar und basiert auf Map-Reduce, wodurch es für Big-Data-Anwendungen geeignet ist. MongoDB ist so flexibel, dass es als schemalose Dokumentendatenbank, als relationaler Datenspeicher (obwohl Transaktionen fehlen) oder sogar als Schlüsselwertspeicher zum Zwischenspeichern von Antworten verwendet werden kann.

  

Serverkomponenten mit Express.js

Die serverseitige Komponentenisierung ist nie einfach. Aber mit Express.js (und Connect.js) kam die Idee der „Middleware“. Middleware ist meiner Meinung nach der beste Weg, um Komponenten auf dem Server zu definieren. Wenn Sie es mit einem bekannten Muster vergleichen möchten, ist es ziemlich nah an Rohren und Filtern.

Die Grundidee ist, dass Ihre Komponente Teil einer Pipeline ist. Die Pipeline verarbeitet eine Anfrage (Eingabe) und generiert eine Antwort (Ausgabe), aber Ihre Komponente ist nicht für die gesamte Antwort verantwortlich. Stattdessen ändert es nur das, was es tun muss, und delegiert dann an das nächste Stück der Pipeline. Wenn das letzte Stück der Pipeline die Verarbeitung beendet hat, wird die Antwort an den Client zurückgesendet.

Wir bezeichnen diese „Stücke der Pipeline“ als „Middleware“. Natürlich können wir zwei Arten von Middleware erstellen:

• Vermittler : Diejenigen, die die Anfrage und die Antwort verarbeiten, aber nicht vollständig für die Antwort selbst verantwortlich sind, also delegieren sie an die nächste Middleware.

• Finale : Diejenigen, die die volle Verantwortung für die endgültige Antwort tragen. Sie verarbeiten und modifizieren die Anfrage und die Antwort, müssen aber nicht an die nächste Middleware delegieren. In der Praxis wird empfohlen, dass Sie trotzdem an eine nächste Middleware delegieren, um architektonische Flexibilität zu ermöglichen (dh später weitere Middleware hinzuzufügen), selbst wenn diese Middleware nicht vorhanden ist (in diesem Fall geht die Antwort direkt an den Client).

Betrachten Sie als konkretes Beispiel eine „Benutzermanager“-Komponente auf dem Server. In Bezug auf die Middleware hätten wir sowohl Finals als auch Intermediates. Für unser Finale hätten wir Funktionen wie das Erstellen eines Benutzers und das Auflisten von Benutzern. Aber bevor wir diese Aktionen ausführen können, benötigen wir unsere Zwischenprodukte für die Authentifizierung (da wir nicht möchten, dass nicht authentifizierte Anfragen eingehen und Benutzer erstellen). Sobald wir diese Authentifizierungs-Zwischenprodukte erstellt haben, können wir sie einfach überall dort anschließen, wo wir ein zuvor nicht authentifiziertes Feature in ein authentifiziertes Feature umwandeln möchten.

Single-Page-Anwendungen

Das Init-Projekt konzentriert sich auf die Erstellung von Single-Page-Applikationen (SPAs). Die meisten Webentwickler waren mehr als einmal versucht, sich an SPAs zu versuchen. Ich habe mehrere (meistens proprietäre) erstellt und kann mit Zuversicht sagen, dass sie einfach die Zukunft von Webanwendungen sind. Haben Sie jemals ein SPA mit einer normalen Web-App auf einer mobilen Verbindung verglichen? Der Unterschied in der Reaktionsfähigkeit liegt in der Größenordnung von zehn Sekunden.

SPAs sind die Zukunft des Webs – warum also sollten Sie Ihr Produkt in einer Legacy-Form entwickeln? Ein häufiges Argument, das ich höre, ist, dass die Leute sich Sorgen um SEO machen. Aber bei richtiger Handhabung sollte das kein Problem sein: Google selbst hat ein sehr gutes Tutorial dazu, und auch hier gibt es einige gute Kommentare.

Clientseitiges MV* mit Backbone.js, Marionette.js und Twitter Bootstrap

Über MVC*-Frameworks für SPAs ist viel gesagt worden. Es ist eine schwierige Wahl, aber ich würde sagen, dass die ersten drei Backbone.js, Ember.js und Angular.js sind.

Alle drei sind sehr angesehen. Aber welches ist das Beste für Sie?

Leider muss ich zugeben, dass ich nur sehr begrenzte Erfahrung mit Angular.js habe, also werde ich es aus dieser Diskussion herauslassen (weitere Informationen dazu finden Sie im Angular.js-Tutorial). Ember.js und Backbone.js stellen nun zwei verschiedene Möglichkeiten dar, dasselbe Problem anzugehen.

Backbone.js ist minimal, simpel und bietet Ihnen gerade genug, um ein einfaches SPA zu erstellen. Ember.js hingegen ist ein vollständiges und professionelles Framework zum Erstellen von SPAs. Es hat mehr Schnickschnack, aber auch eine größere Lernkurve.

Abhängig von der Größe Ihrer Anwendung kann die Entscheidung so einfach sein wie ein Blick auf das Verhältnis FeaturesUsed/FeaturesAvailable, das Ihnen einen großen Hinweis gibt.

Im Fall von Init wollte ich die meisten Szenarien abdecken, also habe ich Backbone.js für die einfache SPA-Erstellung und Backbone.Marionette.View für die Komponentenisierung ausgewählt. Auf diese Weise ist jede Komponente eine einfache Anwendung, und die endgültige App kann so komplex sein, wie wir es möchten.

Das Styling ist ebenfalls eine Herausforderung, aber wir können uns wieder auf Frameworks verlassen, die uns aus der Patsche helfen. Für CSS gibt es nichts Besseres als Twitter Bootstrap, das einen vollständigen Satz von Stilen bietet, die sofort einsatzbereit und einfach anzupassen sind.

Bootstrap wurde mit der LESS-Sprache erstellt und ist Open Source, sodass wir es bei Bedarf ändern können. Es enthält eine Menge UX-Steuerelemente, die auf der Bootstrap-Site gut dokumentiert sind. Außerdem gibt es ein Anpassungsmodell, mit dem Sie Ihr eigenes erstellen können. Es ist definitiv der Mann für den Job.

Best Practices: Grunt.js, Mocha.js, Chai.js, RequireJS und CoverJS

Abschließend sollten wir einige unserer Best Practices definieren und uns ansehen, wie Init Sie bei der Implementierung und Wartung unterstützen kann. Unsere Lösung basiert auf mehreren Tools, die selbst auf Node.js basieren.

• Mocha.js und Chai.js :

  Mit diesen Tools können Sie Ihren Entwicklungsprozess verbessern, indem Sie TDD oder BDD anwenden, indem Sie die Infrastruktur zum Organisieren Ihrer Komponententests und einen Runner zum automatischen Ausführen bereitstellen.

  Es gibt Tausende von Unit-Test-Frameworks für JavaScript. Warum also Mocha.js verwenden? Die kurze Antwort: Es ist flexibel und vollständig.

  Die lange Antwort: Es hat zwei wichtige Merkmale (Schnittstellen, Reporter) und eine wesentliche Abwesenheit (Behauptungen). Lassen Sie mich erklären.

  • Schnittstellen : Vielleicht sind Sie an TDD-Konzepte von Suiten und Komponententests gewöhnt, oder vielleicht bevorzugen Sie BDD-Ideen von Verhaltensspezifikationen mit „beschreiben“ und „es sollte“. Mit Mocha.js können Sie beide Ansätze verwenden.

  • Reporter : Wenn Sie Ihren Test ausführen, werden Ergebnisberichte erstellt, und Sie können diese Ergebnisse mit verschiedenen Reportern formatieren. Wenn Sie zum Beispiel einen Continuous-Integration-Server versorgen müssen, können Sie einen Reporter finden, der genau das tut.

  • Fehlende Assertionsbibliothek : Mocha.js ist weit davon entfernt, ein Problem zu sein, sondern wurde entwickelt, um Ihnen die Verwendung der Assertionsbibliothek Ihrer Wahl zu ermöglichen, was Ihnen noch mehr Flexibilität bietet. Es gibt viele Möglichkeiten, aber hier kommt Chai.js ins Spiel.

  Chai.js ist eine flexible Assertionsbibliothek, mit der Sie einen der drei wichtigsten Assertionsstile verwenden können:

  • Assert : Klassischer Assertionsstil aus der alten TDD-Schule. Z.B:

     assert.equal(variable, ”value”);

  • Expect : Chainable Assertion Style, am häufigsten in BDD verwendet. Z.B:

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

  • Should : Wird auch in BDD verwendet, aber ich bevorzuge Expect, weil Should mit der Verhaltensspezifikation 'es ("sollte etwas ...") wiederholt klingt. Z.B:

     variable.should.equal(“value”);

  Chai.js lässt sich perfekt mit Mocha.js kombinieren. Mit nur diesen beiden Bibliotheken können Sie Ihre Tests in TDD, BDD oder jedem erdenklichen Stil schreiben.

• Grunt.js :

  Mit Grunt.js können Sie Build-Aufgaben automatisieren, von einfachem Kopieren und Einfügen und Verketten von Dateien bis hin zur Vorkompilierung von Vorlagen, Kompilierung von Stilsprachen (dh SASS und LESS), Komponententests (mit mocha.js), Linting und Code-Minifizierung (z. B. mit UglifyJS oder Closure Compiler). Sie können Grunt Ihre eigene automatisierte Aufgabe hinzufügen oder die Grunt-Registrierung durchsuchen, wo Hunderte und Aberhunderte von Plugins verfügbar sind (auch hier zahlt sich die Verwendung von Tools mit großartigen Communities aus). Grunt kann auch Ihre Dateien überwachen und Aktionen auslösen, wenn sie geändert werden.

• RequireJS :

  RequireJS klingt vielleicht nur nach einer anderen Möglichkeit, Module mit AMD zu laden, aber ich kann Ihnen versichern, dass es viel mehr als das ist. Um zu verstehen, warum, müssen wir zuerst die Idee des Modul-Namensraums (zB demo.views.hello) erwähnen, die eine Verunreinigung des globalen Namensraums vermeidet, indem jedes Modul in seinen eigenen Namensraum eingeschlossen wird. Das Problem ist, dass diese Module nicht wiederverwendbar sind: Wenn Sie den Namensraum einer 'Instanz' ändern, ändern Sie den Namensraum aller 'Instanzen'. Im Gegensatz dazu können Sie mit RequireJS von Anfang an wiederverwendbare Module definieren. (Außerdem hilft es Ihnen, Dependency Injection zu nutzen, um zu vermeiden, dass Ihre Module auf globale Variablen zugreifen.)

• CoverJS :

  Die Codeabdeckung ist eine Metrik zur Bewertung Ihrer Tests. Wie der Name schon sagt, sagt es Ihnen, wie viel Ihres Codes von Ihrer aktuellen Testsuite abgedeckt wird. CoverJS misst die Codeabdeckung Ihrer Tests, indem es Anweisungen (anstelle von Codezeilen wie JSCoverage) in Ihrem Code instrumentiert und eine instrumentierte Version Ihres Codes generiert. Es kann auch Berichte generieren, um Ihren Continuous Integration Server zu füttern.

Verwenden von Verzweigungen zum Umschalten von Funktionen

Als ich mit Init anfing, brauchte ich eine Möglichkeit für Benutzer, verschiedene Funktionen zu aktivieren und zu deaktivieren, die sie möglicherweise in ihrem Projekt haben möchten. Ich habe mich entschieden, einen radikalen Ansatz für das Branch-System von git zu wählen, um diese Funktionalität zu implementieren.

Im Wesentlichen stellt jede Verzweigung ein Merkmal oder eine Funktionalität dar, die ein Benutzer möglicherweise einbeziehen möchte. Wenn Sie ein Projekt von Grund auf neu starten, beginnen Sie mit dem minimal benötigten Zweig und fügen Sie dann andere Technologien hinzu, indem Sie sie mit den gewünschten Zweigen zusammenführen. Angenommen, Sie möchten Ihr Projekt mit Backbone.js und Marionette.js beginnen. Nun, Sie können mit dem Backbone.js-Zweig beginnen und ihn mit dem Marionette-Zweig zusammenführen, um für jede Funktionalität, die Sie hinzufügen möchten, fortzufahren.

Diese Idee des Zusammenführens zum Hinzufügen von Funktionalität kann vorerst nur für Technologievorlagen (z. B. Backbone, Node, Express) verwendet werden. Aber in Zukunft werden Sie in der Lage sein, zwischen Backend- (z. B. von MongoDB zu Postgres) und Client-Implementierungen zu wechseln.

Starten Sie ein Projekt mit Init und stellen Sie es noch heute in Heroku bereit

Noch nie war es einfacher, ein Projekt zu starten. Gehen Sie einfach zum GitHub-Repo, suchen Sie nach dem Zweig mit den neuesten Commits (im Moment ist es usermanager, obwohl sich dies in Zukunft ändern könnte) und dann:

1. Erstellen Sie das Verzeichnis für Ihr Projekt (oder verwenden Sie ein vorhandenes).
2. Erstellen Sie Ihr Repository mit „git init“ (oder verwenden Sie das vorhandene Repository).

3. Fügen Sie eine Fernbedienung mit init hinzu

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

4. Holen Sie sich die gewünschte Filiale

    git pull init usermanager

5. Holen Sie sich die Heroku-Prozessdatei

    git pull init heroku-webprocess

6. Erstellen Sie mit installiertem Heroku Toolbelt eine Heroku-App

    heroku create

7. Pushen Sie Ihren Master-Branch nach Heroku

    git push heroku master

8. Besuchen Sie Ihre App, die auf Heroku läuft!

Jetzt können Sie mit der Entwicklung Ihres Killer-Features mit nur wenigen Codezeilen beginnen. Darüber hinaus entwickeln Sie mit den neuesten und effizientesten Technologien in einer Entwicklungssuite, die so automatisiert wie möglich ist.

Ich hoffe, dass Sie Init nutzen können, um Ihre nächste große Idee in Gang zu bringen. Denken Sie daran, das Init-Repository auf neue Korrekturen und Funktionen zu überprüfen – seine Entwicklung ist sehr aktiv, und ich freue mich auf Ihr Feedback.