Init.js: przewodnik po tym, dlaczego i jak korzystać z pełnego stosu JavaScript

Historia

Więc ty i twój współzałożyciel macie świetny pomysł na biznes, prawda?

Dodajesz funkcje w swoim umyśle.

Często pytasz potencjalnych klientów o opinie i wszyscy to uwielbiają.

Ok, więc ludzie tego chcą. Jest nawet trochę pieniędzy do zarobienia. A jedynym powodem, dla którego nie mogą go mieć, jest to, że go nie zaimplementowałeś – jeszcze.

Więc w końcu siadasz pewnego dnia i mówisz: „Zróbmy to!” Wkrótce próbujesz wymyślić, jak wdrożyć logikę biznesową swojej aplikacji, zabójczą funkcję, która będzie napędzać produkt do przodu: masz pomysł, jak to zrobić i wiesz, że możesz to zrobić.

"Gotowy! To działa!" mówisz. Twój dowód koncepcji to sukces! Pozostało tylko spakować go do aplikacji internetowej.

„Ok, stwórzmy stronę”, mówisz.

I wtedy zdajesz sobie sprawę z prawdy: musisz wybrać język programowania; musisz wybrać (nowoczesną) platformę; musisz wybrać niektóre (nowoczesne) frameworki; musisz skonfigurować (i kupić) pamięć masową, bazy danych i dostawców hostingu; potrzebujesz interfejsu administratora; potrzebujesz systemu uprawnień; potrzebujesz menedżera treści.

Masz do podjęcia dziesiątki decyzji architektonicznych. I chcesz tworzyć właściwe: chcesz korzystać z technologii, które pozwalają na szybki rozwój, ciągłą iterację, maksymalną wydajność, szybkość, niezawodność i nie tylko. Chcesz być szczupły, chcesz być zwinny. Chcesz korzystać z technologii, które pomogą Ci odnieść sukces w perspektywie krótko- i długoterminowej. I nie zawsze są łatwe do wybrania.

„Jestem przytłoczony”, mówisz, gdy czujesz się przytłoczony. Twoja energia nie jest taka sama jak kiedyś. Próbujesz poskładać rzeczy w całość, ale to za dużo pracy.

Twój dowód koncepcji powoli więdnie i umiera.

Propozycja

Po tym, jak sam porzuciłem w ten sposób masę pomysłów, postanowiłem zaprojektować rozwiązanie. Nazywam to projektem „Init” (lub init.js).

Istotą idei jest posiadanie jednego projektu, aby rozpocząć je wszystkie, aby umożliwić deweloperowi lub założycielowi technicznemu podjęcie wszystkich tych niezbędnych decyzji naraz i otrzymać odpowiedni szablon startowy oparty na tych decyzjach. Wiem, co powiedzą krytycy: „Jedno rozwiązanie nie może mieć zastosowania do każdego problemu” (nienawidzący będą nienawidzić). I mogą mieć rację. Ale możemy zrobić co w naszej mocy, aby stworzyć przybliżone rozwiązanie i myślę, że Init jest całkiem blisko.

Aby jak najlepiej osiągnąć ten cel, musimy pamiętać o kilku kluczowych pomysłach. Tworząc Init, brałem pod uwagę:

• składniki

  Komponentyzacja jest kluczową cechą każdego systemu, ponieważ umożliwia ponowne wykorzystanie komponentów oprogramowania w różnych projektach — co jest głównym celem Init. Ale komponowanie wiąże się również z produktem ubocznym, „wymianą”, który będzie naszym najlepszym sprzymierzeńcem w rozwiązywaniu kilku różnych problemów za pomocą „prawie” tego samego rozwiązania.

• Łatwość rozwoju

  Jakiś problem, gdzieś ma rozwiązanie najlepiej napisane w Brainf*ck. Ale zaimplementowanie tego rozwiązania (w Brainfuck) będzie prawie niemożliwe do pisania, nie mówiąc już o czytaniu. Będzie to kosztować czas i ogromny wysiłek. Ogólnie rzecz biorąc, powinieneś używać języków i platform, które ułatwiają programowanie, a nie utrudniają Tobie (lub każdemu, kto może nad tym pracować później).

• Społeczność

  Niezależnie od wybranej platformy, upewnij się, że ma dużą społeczność i taką, która może pomóc Ci w rozwiązywaniu najczęstszych i nietypowych problemów. Pamiętaj: jQuery może nie być najszybszą, najczystszą ani najbardziej elegancką biblioteką — ale wygrywa tylko dzięki swojej społeczności.

Mając na uwadze te cele, pokażę Ci, jak podejmowałem własne decyzje podczas tworzenia Init.

W swej istocie Init korzysta z paradygmatu „pełnego stosu JavaScript” (niektórzy odnoszą się do niego lub jego podzbioru jako MEAN Stack). Pracując z takim stosem, Init jest w stanie używać tylko jednego języka, jednocześnie tworząc niezwykle elastyczne i w pełni funkcjonalne środowisko do tworzenia aplikacji internetowych. Krótko mówiąc, Init pozwala używać JavaScript nie tylko do tworzenia klientów i serwerów, ale także do budowania, testowania, tworzenia szablonów i nie tylko.

Ale zwolnijmy na chwilę i zadajmy sobie pytanie: czy naprawdę dobrym pomysłem jest używanie JavaScript?

Dlaczego wybrałem JavaScript

Zajmuję się tworzeniem stron internetowych od 1998 roku. W tamtych czasach używaliśmy Perla do większości prac programistycznych po stronie serwera, ale nawet od tego czasu po stronie klienta mieliśmy JavaScript. Od tamtego czasu technologie serwerów WWW bardzo się zmieniły: przechodziliśmy przez kolejne fale języków i technologii, takich jak PHP, AP, JSP, .NET, Ruby, Python, żeby wymienić tylko kilka. Deweloperzy zaczęli zdawać sobie sprawę, że używanie dwóch różnych języków dla środowisk klienta i serwera komplikuje sprawę. Początkowe próby unifikacji w ramach jednego języka próbowały stworzyć komponenty klienta na serwerze i skompilować je do JavaScript. To nie działało zgodnie z oczekiwaniami i większość tych projektów nie powiodła się (na przykład: ASP MVC zastępując formularze internetowe ASP.NET, a GWT prawdopodobnie zostanie zastąpiony w najbliższej przyszłości przez Polymer). Ale w gruncie rzeczy był to świetny pomysł: jeden język na kliencie i serwerze, pozwalający na ponowne wykorzystanie komponentów i zasobów (to jest słowo kluczowe: resources ).

Odpowiedź była prosta: umieść JavaScript na serwerze.

JavaScript faktycznie narodził się z JavaScript Server Side w Netscape Enterprise Server, ale język po prostu nie był wtedy gotowy. Po latach prób i błędów w końcu pojawił się Node.js, który nie tylko umieścił JavaScript na serwerze, ale także promował ideę programowania bez blokowania, zmieniając na zawsze sposób, w jaki piszemy „fread” (I/O) (czytaj tutaj więcej).

Ale te pomysły nie były nowe — dlaczego więc stały się tak popularne dzięki Node.js? Proste, nieblokujące programowanie można osiągnąć na kilka sposobów. Być może najłatwiej jest użyć wywołań zwrotnych i pętli zdarzeń. W większości języków nie jest to łatwe zadanie: podczas gdy „wywołania zwrotne” są powszechną funkcją w niektórych innych językach, pętla zdarzeń nie jest i często zmagasz się z zewnętrznymi bibliotekami (na przykład: Python, z Tornado). Ale w JavaScript wywołania zwrotne są wbudowane w język, podobnie jak pętla zdarzeń, i prawie każdy programista, który nawet parał się JavaScriptem, jest z nimi zaznajomiony (lub przynajmniej ich używał, nawet jeśli nie do końca rozumie, co się dzieje pętla jest). Nagle każdy startup na Ziemi mógł ponownie wykorzystać programistów (tj. zasoby) zarówno po stronie klienta, jak i serwera, rozwiązując problem ze stanowiskiem pracy „Potrzebny guru Pythona”.

Więc teraz mamy niesamowicie szybką platformę (dzięki programowaniu bez blokowania) z językiem programowania, który jest niesamowicie łatwy w użyciu (dzięki JavaScript). Ale czy to wystarczy? Czy to będzie trwać? Jestem pewien, że JavaScript zajmie w przyszłości ważne miejsce. Powiem ci, dlaczego:

• Programowanie funkcjonalne

  JavaScript był pierwszym językiem programowania, który udostępnił masom paradygmat funkcjonalny (oczywiście Lisp był pierwszy, ale większość programistów nigdy nie zbudowała aplikacji gotowej do produkcji przy użyciu Lispa). Lisp i Self, główne inspiracje Javascriptu, są pełne innowacyjnych pomysłów. Te pomysły mogą uwolnić nasze umysły do ​​odkrywania nowych technik, wzorców i paradygmatów. I wszystkie przenoszą się na JavaScript. Spójrz na monady, liczby kościelne, a nawet (dla bardziej praktycznego przykładu) funkcje kolekcji Underscore.js, które mogą zaoszczędzić ci linijek i linijek kodu.

• Obiekty dynamiczne i dziedziczenie prototypów

  Programowanie obiektowe bez klas (i bez niekończących się hierarchii klas) pozwala na szybki rozwój (tworzenie obiektów, dodawanie metod i używanie ich), ale co najważniejsze, skraca czas refaktoryzacji podczas zadań konserwacyjnych, umożliwiając programiście modyfikację instancji obiektów zajęć. Ta szybkość i elastyczność torują drogę do szybkiego rozwoju.

• JavaScript to Internet

  JavaScript został zaprojektowany z myślą o Internecie, jest tu od samego początku i nie znika. Wszystkie próby jego zniszczenia nie powiodły się: patrz na przykład upadek apletów Java, zastąpienie VBScript przez TypeScript Microsoftu (który kompiluje się do JavaScript) oraz upadek Flasha z rąk rynku mobilnego i HTML5. Nie da się zastąpić Javascript bez zniszczenia milionów stron internetowych, więc naszym celem na przyszłość powinno być jego ulepszanie. I nie ma nikogo lepszego do tego zadania niż Komitet Techniczny 39 z ECMA.

  Ok, alternatywy dla JavaScriptu rodzą się codziennie, takie jak CoffeeScript, TypeScript i miliony języków, które kompilują się do JavaScript. Te alternatywy mogą być przydatne na etapach rozwoju (poprzez mapy źródłowe), ale na dłuższą metę nie zastąpią JavaScript z dwóch powodów: ich społeczności nigdy nie będą większe, a ich najlepsze cechy zostaną zaadoptowane przez skrypt ECMA (tj. JavaScript ). JavaScript nie jest językiem asemblerowym: jest to język programowania wysokiego poziomu z kodem źródłowym, który możesz zrozumieć — więc powinieneś go zrozumieć.

Kompleksowy JavaScript: Node.js i MongoDB

To są powody, dla których warto używać JavaScript. Teraz użyję JavaScript jako powodu do używania Node.js i MongoDB.

• Node.js

  Node.js to platforma do tworzenia szybkich i skalowalnych aplikacji sieciowych — tak właśnie mówi witryna Node.js. Ale Node.js to coś więcej: jest to preferowane środowisko uruchomieniowe dla dowolnej aplikacji JavaScript z dostępem I/O. Nawet jeśli nie planujesz pisać swojej głównej aplikacji serwerowej za pomocą Node.js, możesz użyć narzędzi zbudowanych na Node.js, aby usprawnić proces rozwoju. Na przykład: Mocha.js do testów jednostkowych, Grunt.js do automatycznych zadań kompilacji, a nawet nawiasy do edycji kodu pełnotekstowego.

  Tak więc, jeśli zamierzasz pisać aplikacje JavaScript dla serwera lub klienta, powinieneś spojrzeć na kilka przykładów Node.js, ponieważ będziesz go potrzebować i używać na co dzień. Istnieje kilka interesujących alternatyw, ale żadna z nich nie występuje nawet na 10% społeczności Node.js.

• MongoDB

  MongoDB to oparta na dokumentach baza danych NoSQL, która używa JavaScript jako języka zapytań, co pozwala mi uzupełnić kompleksową platformę JavaScript. Ale to nawet nie jest główny powód, aby wybrać tę bazę danych.

  MongoDB to baza danych pozbawiona schematów, która umożliwia utrwalanie obiektów w elastyczny sposób, a tym samym szybsze dostosowywanie się do zmian wymagań. Ponadto jest wysoce skalowalny i oparty na redukcji map, dzięki czemu nadaje się do zastosowań związanych z dużymi zbiorami danych. MongoDB jest tak elastyczny, że może być używany jako baza danych dokumentów bez schematów, relacyjny magazyn danych (chociaż nie zawiera transakcji), a nawet jako magazyn klucz-wartość do buforowania odpowiedzi.

  

Komponentyzacja serwera za pomocą Express.js

Komponentyzacja po stronie serwera nigdy nie jest łatwa. Ale wraz z Express.js (i Connect.js) pojawił się pomysł „oprogramowania pośredniczącego”. Moim zdaniem middleware to najlepszy sposób na zdefiniowanie komponentów na serwerze. Jeśli chcesz to porównać do znanego wzorca, jest on bardzo zbliżony do rur i filtrów.

Podstawowa idea polega na tym, że twój komponent jest częścią potoku. Potok przetwarza żądanie (dane wejściowe) i generuje odpowiedź (wyjście), ale składnik nie jest odpowiedzialny za całą odpowiedź. Zamiast tego modyfikuje tylko to, czego potrzebuje, a następnie deleguje do następnego elementu potoku. Gdy ostatni element potoku zakończy przetwarzanie, odpowiedź jest wysyłana z powrotem do klienta.

Te „elementy rurociągu” nazywamy „oprogramowaniem pośredniczącym”. Oczywiście możemy stworzyć dwa rodzaje oprogramowania pośredniego:

• Pośrednicy : te, które przetwarzają żądanie i odpowiedź, ale nie są w pełni odpowiedzialne za samą odpowiedź, więc delegują do następnego oprogramowania pośredniczącego.

• Finały : Osoby z pełną odpowiedzialnością za ostateczną odpowiedź. Przetwarzają i modyfikują żądanie i odpowiedź, ale nie muszą delegować do następnego oprogramowania pośredniczącego. W praktyce zaleca się, aby mimo wszystko delegować do następnego oprogramowania pośredniczącego, aby umożliwić elastyczność architektoniczną (tj. dodanie większej ilości oprogramowania pośredniczącego później), nawet jeśli to oprogramowanie pośredniczące nie istnieje (w takim przypadku odpowiedź zostanie przesłana bezpośrednio do klienta).

Jako konkretny przykład rozważmy komponent „menedżer użytkowników” na serwerze. Jeśli chodzi o oprogramowanie pośredniczące, mielibyśmy zarówno finały, jak i półprodukty. Na nasze finały mielibyśmy takie funkcje, jak tworzenie użytkownika i wystawianie użytkowników. Ale zanim będziemy mogli wykonać te czynności, potrzebujemy naszych pośredników do uwierzytelniania (ponieważ nie chcemy, aby nieuwierzytelnione żądania przychodzące i tworzące użytkowników). Po utworzeniu tych półproduktów uwierzytelniania możemy po prostu podłączyć je w dowolnym miejscu, w którym chcemy przekształcić wcześniej nieuwierzytelnioną funkcję w funkcję uwierzytelnioną.

Aplikacje jednostronicowe

Projekt Init skupia się na tworzeniu aplikacji jednostronicowych (SPA). Większość twórców stron internetowych nie raz miała ochotę spróbować swoich sił w SPA. Zbudowałem kilka (w większości autorskich) i mogę śmiało powiedzieć, że są one po prostu przyszłością aplikacji webowych. Czy kiedykolwiek porównałeś SPA do zwykłej aplikacji internetowej na połączeniu mobilnym? Różnica w responsywności jest rzędu kilkudziesięciu sekund.

SPA to przyszłość sieci — dlaczego więc miałbyś budować swój produkt w starszej formie? Często słyszę, że ludzie martwią się o SEO. Ale jeśli poradzisz sobie z tym poprawnie, nie powinno to stanowić problemu: samo Google ma bardzo dobry samouczek, jak to zrobić, i tutaj są też dobre komentarze.

MV* po stronie klienta z Backbone.js, Marionette.js i Twitter Bootstrap

Wiele już powiedziano o frameworkach MVC* dla SPA. To trudny wybór, ale powiedziałbym, że trzy najlepsze to Backbone.js, Ember.js i Angular.js.

Wszystkie trzy są bardzo dobrze oceniane. Ale który z nich jest dla Ciebie najlepszy?

Niestety muszę przyznać, że mam bardzo ograniczone doświadczenie z Angular.js, więc zostawię to z tej dyskusji (więcej na ten temat w tutorialu Angular.js). Teraz Ember.js i Backbone.js reprezentują dwa różne sposoby atakowania tego samego problemu.

Backbone.js jest minimalistyczny, uproszczony i oferuje tylko tyle, aby stworzyć proste SPA. Z kolei Ember.js to kompletny i profesjonalny framework do tworzenia SPA. Ma więcej dzwonków i gwizdków, ale także większą krzywą uczenia się.

W zależności od rozmiaru aplikacji, decyzja może być tak prosta, jak przyjrzenie się stosunkowi funkcji Użyte/Dostępne, co da ci dużą wskazówkę.

W przypadku Init chciałem uwzględnić większość scenariuszy, więc wybrałem Backbone.js do łatwego tworzenia SPA, z Backbone.Marionette.View do komponowania. W ten sposób każdy komponent jest prostą aplikacją, a ostateczna aplikacja może być tak złożona, jak byśmy tego chcieli.

Stylizacja też jest wyzwaniem, ale znowu możemy liczyć na frameworki, które nas ratują. W przypadku CSS nie ma nic lepszego niż Twitter Bootstrap, który oferuje kompletny zestaw stylów, które są zarówno gotowe do użycia po wyjęciu z pudełka, jak i łatwe do dostosowania.

Bootstrap został stworzony przy użyciu języka LESS i jest open source, więc w razie potrzeby możemy go modyfikować. Zawiera mnóstwo kontrolek UX, które są dobrze udokumentowane na stronie Bootstrap. Dodatkowo istnieje model dostosowywania, który pozwala tworzyć własne. To zdecydowanie człowiek do tego zadania.

Najlepsze praktyki: Grunt.js, Mocha.js, Chai.js, RequireJS i CoverJS

Na koniec powinniśmy zdefiniować niektóre z naszych najlepszych praktyk i przyjrzeć się, w jaki sposób Init może pomóc w ich wdrożeniu i utrzymaniu. Nasze rozwiązanie skupia się na kilku narzędziach, które bazują na samym Node.js.

• Mocha.js i Chai.js :

  Narzędzia te pozwalają usprawnić proces rozwoju poprzez zastosowanie TDD lub BDD, zapewniając infrastrukturę do organizowania testów jednostkowych oraz program uruchamiający do ich automatycznego uruchamiania.

  Istnieją tysiące struktur testów jednostkowych dla JavaScript. Dlaczego więc używać Mocha.js? Krótka odpowiedź: jest elastyczny i kompletny.

  Długa odpowiedź: ma dwie ważne cechy (interfejsy, reportaże) i jedną istotną nieobecność (zaświadczenia). Pozwól mi wyjaśnić.

  • Interfejsy : może jesteś przyzwyczajony do koncepcji pakietów i testów jednostkowych TDD, a może wolisz koncepcje BDD dotyczące specyfikacji zachowania z „opisać” i „powinno”. Mocha.js pozwala korzystać z obu podejść.

  • Reporterzy : uruchomienie testu spowoduje wygenerowanie raportów z wynikami, które można sformatować za pomocą różnych reporterów. Na przykład, jeśli potrzebujesz załadować serwer Continuous Integration, możesz znaleźć reportera, który właśnie to zrobi.

  • Brak biblioteki asercji : Mocha.js nie stanowi problemu, aby umożliwić korzystanie z wybranej biblioteki asercji, dając jeszcze większą elastyczność. Istnieje wiele opcji, ale tutaj w grę wchodzi Chai.js.

  Chai.js to elastyczna biblioteka asercji, która umożliwia korzystanie z dowolnego z trzech głównych stylów asercji:

  • Assert : Klasyczny styl asercji ze starej szkoły TDD. Np:

     assert.equal(variable, ”value”);

  • Spodziewaj się: styl asercji z możliwością tworzenia łańcuchów, najczęściej używany w BDD. Np:

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

  • Powinien : używany również w BDD, ale wolę Oczekiwać, ponieważ powinien brzmieć powtarzalnie ze specyfikacją zachowania „to („powinien coś zrobić..”)”. Np:

     variable.should.equal(“value”);

  Chai.js doskonale łączy się z Mocha.js. Używając tylko tych dwóch bibliotek, możesz pisać swoje testy w TDD, BDD lub dowolnym stylu, jaki można sobie wyobrazić.

• Grunt.js :

  Grunt.js pozwala zautomatyzować zadania budowania, począwszy od prostego kopiowania i wklejania i łączenia plików, do wstępnej kompilacji szablonów, kompilacji języka stylów (tj. SASS i LESS), testowania jednostkowego (z mocha.js), lintingu i minimalizacja kodu (np. za pomocą UglifyJS lub Closure Compiler). Możesz dodać własne automatyczne zadanie do Grunta lub przeszukać rejestr Grunta, w którym dostępne są setki i setki wtyczek (ponownie, korzystanie z narzędzi ze świetnymi społecznościami za nimi się opłaca). Grunt może również monitorować twoje pliki i uruchamiać akcje, gdy są modyfikowane.

• Wymagaj JS :

  RequireJS może brzmieć jak kolejny sposób ładowania modułów z AMD, ale zapewniam Cię, że to znacznie więcej. Aby zrozumieć dlaczego, najpierw musimy wspomnieć o idei przestrzeni nazw modułów (np. demo.views.hello), która pozwala uniknąć zanieczyszczania globalnej przestrzeni nazw poprzez owijanie każdego modułu we własną przestrzeń nazw. Problem polega na tym, że te moduły nie nadają się do ponownego użycia: jeśli modyfikujesz przestrzeń nazw jednej „instancji”, modyfikujesz przestrzeń nazw wszystkich „instancji”. W przeciwieństwie do tego, RequireJS pozwala od samego początku definiować moduły wielokrotnego użytku. (Ponadto pomoże to w zaakceptowaniu wstrzykiwania zależności, aby uniknąć sytuacji, w której moduły mają dostęp do zmiennych globalnych).

• OkładkaJS :

  Pokrycie kodu to miara oceny testów. Jak sama nazwa wskazuje, informuje, jaka część kodu jest objęta bieżącym zestawem testów. CoverJS mierzy pokrycie kodu testów przez instrumentację instrukcji (zamiast wierszy kodu, takich jak JSCoverage) w kodzie i generowanie oprzyrządowanej wersji kodu. Może również generować raporty, które zasilają Twój Continuous Integration Server.

Używanie gałęzi do przełączania funkcji

Kiedy uruchamiałem Init, potrzebowałem sposobu, aby użytkownicy mogli aktywować i dezaktywować różne funkcje, które mogą chcieć w swoim projekcie. Zdecydowałem się na radykalne podejście do systemu branchowego git, aby zaimplementować tę funkcjonalność.

Zasadniczo każda gałąź reprezentuje funkcję lub funkcjonalność, którą użytkownik może chcieć uwzględnić. Jeśli zaczynasz projekt od podstaw, zacznij od minimalnej gałęzi, której potrzebujesz, a następnie dodaj inne technologie, łącząc się z żądanymi gałęziami. Załóżmy na przykład, że chcesz rozpocząć swój projekt z Backbone.js i Marionette.js. Cóż, możesz zacząć od gałęzi Backbone.js i połączyć ją z gałęzią Marionette, kontynuując do przodu dla każdego fragmentu funkcjonalności, który chcesz dodać.

Na razie pomysł łączenia w celu dodania funkcjonalności można wykorzystać tylko w przypadku szablonów technologicznych (np. Backbone, Node, Express). Ale w przyszłości będziesz mógł przełączać się między back-endem (np. z MongoDB na Postgres) a implementacjami klienckimi.

Rozpocznij projekt z Init i wdróż w Heroku już dziś

Nigdy nie było prostszego sposobu na rozpoczęcie projektu. Po prostu przejdź do repozytorium GitHub, sprawdź gałąź z najnowszymi zatwierdzeniami (obecnie jest to usermanager, chociaż może się to zmienić w przyszłości), a następnie:

1. Utwórz katalog dla swojego projektu (lub użyj istniejącego).
2. Utwórz swoje repozytorium za pomocą „git init” (lub użyj istniejącego repozytorium).

3. Dodaj pilota z init

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

4. Zdobądź oddział, który chcesz

    git pull init usermanager

5. Pobierz plik procesu Heroku

    git pull init heroku-webprocess

6. Po zainstalowaniu paska narzędzi Heroku utwórz aplikację Heroku

    heroku create

7. Prześlij swoją główną gałąź do Heroku

    git push heroku master

8. Odwiedź swoją aplikację, działającą w Heroku!

Teraz możesz zacząć rozwijać swoją zabójczą funkcję za pomocą zaledwie kilku linijek kodu. Nie tylko to, ale będziesz programować przy użyciu najnowszych, najbardziej wydajnych technologii w pakiecie programistycznym, który jest tak zautomatyzowany, jak to tylko możliwe.

Mam nadzieję, że możesz użyć Init do rozpoczęcia kolejnego wielkiego pomysłu. Pamiętaj, aby sprawdzić repozytorium Init pod kątem nowych poprawek i funkcji — jego rozwój jest bardzo aktywny i czekam na Wasze opinie.