Init.js: Panduan tentang Mengapa dan Bagaimana JavaScript Full-Stack

Cerita

Jadi, Anda dan co-founder Anda memiliki ide bisnis yang bagus ini, bukan?

Anda telah menambahkan fitur dalam pikiran Anda.

Sering kali, Anda meminta pendapat pelanggan potensial, dan mereka semua menyukainya.

Oke, jadi orang menginginkannya. Bahkan ada sejumlah uang yang akan dihasilkan. Dan satu-satunya alasan mereka tidak dapat memilikinya adalah karena Anda belum menerapkannya—belum.

Jadi akhirnya, suatu hari Anda duduk dan berkata, "Ayo lakukan!" Segera, Anda mencoba mencari cara untuk menerapkan logika bisnis aplikasi Anda, fitur pembunuh yang akan mendorong produk ke depan: Anda memiliki ide tentang bagaimana melakukannya, dan Anda tahu Anda bisa melakukannya.

"Selesai! Berhasil!" kamu bilang. Bukti konsep Anda sukses! Yang tersisa hanyalah mengemasnya menjadi aplikasi web.

“Oke, mari kita buat situsnya”, katamu.

Dan kemudian, Anda menyadari kebenarannya: Anda harus memilih bahasa pemrograman; Anda harus memilih platform (modern); anda perlu memilih beberapa kerangka kerja (modern); Anda perlu mengonfigurasi (dan membeli) penyimpanan, database, dan penyedia hosting; Anda memerlukan antarmuka admin; Anda memerlukan sistem izin; Anda memerlukan pengelola konten.

Anda memiliki puluhan keputusan arsitektur untuk dibuat. Dan Anda ingin membuat yang tepat: Anda ingin menggunakan teknologi yang memungkinkan pengembangan cepat, iterasi konstan, efisiensi maksimal, kecepatan, ketahanan, dan banyak lagi. Anda ingin kurus, Anda ingin gesit. Anda ingin menggunakan teknologi yang akan membantu Anda sukses dalam jangka pendek dan panjang. Dan mereka tidak selalu mudah untuk dipilih.

"Saya kewalahan," kata Anda, saat Anda merasa kewalahan. Energi Anda tidak sama seperti dulu. Anda mencoba menyatukan semuanya, tetapi itu terlalu banyak pekerjaan.

Bukti konsep Anda perlahan layu dan mati.

Proposal

Setelah meninggalkan banyak ide sendiri dengan cara ini, saya memutuskan untuk merancang solusi. Saya menyebutnya proyek 'Init' (atau, init.js).

Inti dari idenya adalah memiliki satu proyek untuk memulai semuanya, membiarkan pengembang atau pendiri teknis membuat semua keputusan penting ini sekaligus, dan menerima template awal yang sesuai berdasarkan keputusan tersebut. Saya tahu apa yang akan dikatakan pencela, "Satu solusi tidak dapat diterapkan pada setiap masalah" (pembenci akan membenci). Dan mereka mungkin benar. Tapi kita bisa melakukan yang terbaik untuk membuat solusi perkiraan, dan saya pikir Init cukup dekat.

Untuk mencapai tujuan ini dengan baik, kita harus mengingat beberapa ide kunci. Saat mengembangkan Init, saya mempertimbangkan:

• Komponen

  Komponenisasi adalah karakteristik utama dari sistem apa pun karena memungkinkan Anda untuk menggunakan kembali komponen perangkat lunak di berbagai proyek—yang merupakan tujuan utama Init. Tetapi komponenisasi juga dilengkapi dengan produk sampingan, “replaceability”, yang akan menjadi sekutu terbaik kita dalam mengatasi beberapa masalah berbeda dengan solusi yang “hampir” sama.

• Kemudahan Pengembangan

  Beberapa masalah, di suatu tempat memiliki solusi terbaik yang ditulis dalam Brainf*ck. Tetapi menerapkan solusi itu (dalam Brainfuck) hampir tidak mungkin untuk ditulis, apalagi dibaca. Ini akan menghabiskan waktu dan usaha yang luar biasa. Secara umum, Anda harus menggunakan bahasa dan platform yang membuat pengembangan lebih mudah, bukan mempersulit Anda (atau siapa pun yang mungkin mengerjakannya nanti).

• Masyarakat

  Platform apa pun yang Anda pilih, pastikan ia memiliki komunitas yang besar, dan yang dapat membantu Anda dengan masalah yang paling umum dan tidak biasa. Ingat: jQuery mungkin bukan perpustakaan tercepat, terbersih, atau paling elegan—tetapi merupakan pemenang hanya karena komunitasnya.

Dengan mengingat tujuan ini, selanjutnya saya akan menunjukkan kepada Anda bagaimana saya membuat keputusan sendiri dalam membuat Init.

Pada intinya, Init memanfaatkan paradigma 'full-stack JavaScript' (beberapa orang menyebutnya, atau bagian darinya, sebagai MEAN Stack). Dengan bekerja dengan tumpukan seperti itu, Init dapat menggunakan hanya satu bahasa sambil menciptakan lingkungan yang sangat fleksibel dan berfitur lengkap untuk mengembangkan aplikasi web. Singkatnya, Init memungkinkan Anda menggunakan JavaScript tidak hanya untuk pengembangan klien dan server, tetapi juga untuk membangun, menguji, membuat templat, dan banyak lagi.

Tapi mari kita memperlambat sejenak dan bertanya pada diri sendiri: apakah benar-benar ide yang baik untuk menggunakan JavaScript?

Mengapa Saya Memilih JavaScript

Saya telah menjadi pengembang web sejak tahun 1998. Saat itu kami menggunakan Perl untuk sebagian besar pengembangan sisi server kami, tetapi bahkan sejak itu kami memiliki JavaScript di sisi klien. Teknologi server web telah sangat berubah sejak saat itu: kami melewati gelombang demi gelombang bahasa dan teknologi seperti PHP, AP, JSP, .NET, Ruby, Python, hanya untuk beberapa nama. Pengembang mulai menyadari bahwa menggunakan dua bahasa yang berbeda untuk lingkungan klien dan server adalah hal yang rumit. Upaya awal untuk menyatukan dalam satu bahasa mencoba membuat komponen klien di server dan mengompilasinya ke JavaScript. Ini tidak berfungsi seperti yang diharapkan dan sebagian besar proyek tersebut gagal (misalnya: ASP MVC menggantikan formulir web ASP.NET, dan GWT bisa dibilang akan diganti dalam waktu dekat oleh Polymer). Tapi itu adalah ide bagus, pada dasarnya: satu bahasa di klien dan server, memungkinkan kami untuk menggunakan kembali komponen dan sumber daya (ini adalah kata kunci: resources ).

Jawabannya sederhana: letakkan JavaScript di server.

JavaScript sebenarnya lahir dengan JavaScript Server Side di Netscape Enterprise Server, tetapi bahasanya belum siap pada saat itu. Setelah bertahun-tahun trial and error, Node.js akhirnya muncul yang tidak hanya menempatkan JavaScript di server, tetapi juga mempromosikan ide pemrograman non-blocking, mengubah cara kita menulis "fread" (I/O) selamanya (baca di sini untuk lebih).

Tetapi ide-ide itu bukanlah hal baru—jadi mengapa mereka menjadi begitu populer di Node.js? Pemrograman sederhana tanpa pemblokiran dapat dicapai dengan beberapa cara. Mungkin yang paling mudah adalah menggunakan callback dan loop acara. Dalam kebanyakan bahasa, itu bukan tugas yang mudah: sementara 'panggilan balik' adalah fitur umum dalam beberapa bahasa lain, loop peristiwa tidak, dan Anda sering menemukan diri Anda bergulat dengan perpustakaan eksternal (misalnya: Python, dengan Tornado). Tetapi dalam JavaScript, panggilan balik dibangun ke dalam bahasa, seperti halnya loop acara, dan hampir setiap programmer yang bahkan mencoba-coba JavaScript akrab dengan mereka (atau setidaknya pernah menggunakannya, bahkan jika mereka tidak begitu mengerti apa acaranya. lingkaran adalah). Tiba-tiba, setiap startup di Bumi dapat menggunakan kembali pengembang (yaitu, sumber daya) di sisi klien dan server, memecahkan masalah posting pekerjaan "Dibutuhkan Python Guru".

Jadi sekarang kami memiliki platform yang sangat cepat (berkat pemrograman non-blocking) dengan bahasa pemrograman yang sangat mudah digunakan (berkat JavaScript). Tapi apakah itu cukup? Apakah itu akan bertahan? Saya yakin JavaScript akan memiliki tempat penting di masa depan. Biarkan saya memberi tahu Anda alasannya:

• Pemrograman Fungsional

  JavaScript adalah bahasa pemrograman pertama yang membawa paradigma fungsional ke massa (tentu saja, Lisp datang lebih dulu, tetapi kebanyakan programmer tidak pernah membangun aplikasi siap produksi menggunakan Lisp). Lisp dan Self, pengaruh utama Javascript, penuh dengan ide-ide inovatif. Ide-ide itu bisa membebaskan pikiran kita untuk mengeksplorasi teknik, pola, dan paradigma baru. Dan mereka semua terbawa ke JavaScript. Lihatlah monad, nomor Gereja, atau bahkan (untuk contoh yang lebih praktis) fungsi koleksi Underscore.js, yang dapat menghemat baris dan baris kode.

• Objek Dinamis dan pewarisan Prototipe

  Pemrograman Berorientasi Objek tanpa kelas (dan tanpa hierarki kelas tanpa akhir) memungkinkan pengembangan cepat (membuat objek, menambahkan metode, dan menggunakannya), tetapi, yang paling penting, mengurangi waktu refactoring selama tugas pemeliharaan dengan mengizinkan programmer untuk memodifikasi instance objek. kelas. Kecepatan dan fleksibilitas ini membuka jalan bagi perkembangan pesat.

• JavaScript adalah Internet

  JavaScript dirancang untuk Internet, sudah ada sejak awal, dan tidak akan hilang. Semua upaya untuk menghancurkannya telah gagal: lihat, misalnya, jatuhnya Java Applet, penggantian VBScript oleh Microsoft's TypeScript (yang dikompilasi ke JavaScript), dan kematian Flash di tangan pasar seluler dan HTML5. Tidak mungkin mengganti Javascript tanpa merusak jutaan halaman web, jadi tujuan kami ke depan adalah untuk meningkatkannya. Dan tidak ada yang lebih baik untuk pekerjaan itu selain Technical Committee 39 dari ECMA.

  Oke, alternatif untuk JavaScript lahir setiap hari, seperti CoffeeScript, TypeScript, dan jutaan bahasa yang dikompilasi ke JavaScript. Alternatif ini mungkin berguna untuk tahap pengembangan (melalui peta sumber), tetapi mereka akan gagal menggantikan JavaScript dalam jangka panjang karena dua alasan: komunitas mereka tidak akan pernah lebih besar, dan fitur terbaik mereka akan diadopsi oleh skrip ECMA (yaitu, JavaScript ). JavaScript bukan sebagai bahasa rakitan: ini adalah bahasa pemrograman tingkat tinggi dengan kode sumber yang dapat Anda pahami—jadi Anda harus memahaminya.

JavaScript ujung ke ujung: Node.js dan MongoDB

Jadi, itulah alasan untuk menggunakan JavaScript. Sekarang, saya akan menggunakan JavaScript sebagai alasan untuk menggunakan Node.js dan MongoDB.

• Node.js

  Node.js adalah platform untuk membangun aplikasi jaringan yang cepat dan skalabel—begitulah yang dikatakan situs Node.js. Tetapi Node.js lebih dari itu: ini adalah lingkungan runtime yang disukai untuk aplikasi JavaScript apa pun dengan akses I/O. Bahkan jika Anda tidak berencana untuk menulis aplikasi server utama Anda dengan Node.js, Anda dapat menggunakan alat yang dibangun di atas Node.js untuk meningkatkan proses pengembangan Anda. Misalnya: Mocha.js untuk pengujian unit, Grunt.js untuk tugas pembuatan otomatis, atau bahkan Brackets untuk pengeditan kode teks lengkap.

  Jadi, jika Anda akan menulis aplikasi JavaScript untuk server atau klien, Anda harus melihat beberapa contoh Node.js, karena Anda akan membutuhkan dan menggunakannya setiap hari. Ada beberapa alternatif yang menarik, tetapi tidak ada yang bahkan 10% dari komunitas Node.js.

• MongoDB

  MongoDB adalah database berbasis dokumen NoSQL yang menggunakan JavaScript sebagai bahasa kuerinya, memungkinkan saya untuk menyelesaikan platform JavaScript ujung ke ujung. Tapi itu bahkan bukan alasan utama untuk memilih database ini.

  MongoDB adalah database tanpa skema yang memungkinkan Anda untuk mempertahankan objek Anda dengan cara yang fleksibel dan dengan demikian beradaptasi lebih cepat terhadap perubahan persyaratan. Plus, ini sangat skalabel dan berbasis pengurangan peta, yang membuatnya cocok untuk aplikasi data besar. MongoDB sangat fleksibel sehingga dapat digunakan sebagai database dokumen tanpa skema, penyimpanan data relasional (meskipun tidak memiliki transaksi), atau bahkan sebagai penyimpanan nilai kunci untuk respons caching.

  

Komponenisasi Server dengan Express.js

Komponenisasi sisi server tidak pernah mudah. Tetapi dengan Express.js (dan Connect.js) muncul ide 'middleware'. Menurut saya, middleware adalah cara terbaik untuk mendefinisikan komponen di server. Jika Anda ingin membandingkannya dengan pola yang diketahui, itu cukup dekat dengan pipa dan filter.

Ide dasarnya adalah bahwa komponen Anda adalah bagian dari pipa. Pipeline memproses permintaan (input) dan menghasilkan respons (output), tetapi komponen Anda tidak bertanggung jawab atas seluruh respons. Alih-alih, itu hanya memodifikasi apa yang diperlukan dan kemudian mendelegasikan ke bagian berikutnya dari pipa. Ketika bagian terakhir dari pipa selesai diproses, respons dikirim kembali ke klien.

Kami menyebut 'potongan-potongan pipa' ini sebagai 'middleware'. Jelas, kita dapat membuat dua jenis middleware:

• Perantara : Mereka yang memproses permintaan dan respons, tetapi tidak sepenuhnya bertanggung jawab atas respons itu sendiri, sehingga mereka mendelegasikan ke middleware berikutnya.

• Final : Mereka yang bertanggung jawab penuh atas respon akhir. Mereka memproses dan memodifikasi permintaan dan respons, tetapi tidak perlu mendelegasikan ke middleware berikutnya. Dalam praktiknya, Anda tetap disarankan untuk mendelegasikan ke middleware berikutnya untuk memungkinkan fleksibilitas arsitektur (yaitu, menambahkan lebih banyak middleware nanti), bahkan jika middleware tersebut tidak ada (dalam hal ini respons akan langsung ke klien).

Sebagai contoh konkret, pertimbangkan komponen 'pengelola pengguna' di server. Dalam hal middleware, kami memiliki final dan intermediet. Untuk final kami, kami akan memiliki fitur seperti membuat pengguna dan membuat daftar pengguna. Tetapi sebelum kami dapat melakukan tindakan tersebut, kami memerlukan perantara kami untuk otentikasi (karena kami tidak ingin permintaan yang tidak diautentikasi masuk dan membuat pengguna). Setelah kami membuat perantara autentikasi ini, kami dapat mencolokkannya di mana saja kami ingin mengubah fitur yang sebelumnya tidak diautentikasi menjadi fitur yang diautentikasi.

Aplikasi Satu Halaman

Proyek Init berfokus pada pembuatan aplikasi satu halaman (SPA). Sebagian besar pengembang web telah tergoda lebih dari sekali untuk mencoba SPA. Saya telah membangun beberapa (kebanyakan berpemilik), dan saya dapat mengatakan dengan yakin bahwa itu hanyalah masa depan aplikasi web. Pernahkah Anda membandingkan SPA dengan aplikasi web biasa pada koneksi seluler? Perbedaan responsivitas ada di urutan puluhan detik.

SPA adalah masa depan web—jadi mengapa Anda membangun produk dalam bentuk lama? Argumen umum yang saya dengar adalah bahwa orang khawatir tentang SEO. Tetapi jika Anda menanganinya dengan benar, ini seharusnya tidak menjadi masalah: Google sendiri memiliki tutorial yang sangat bagus tentang cara melakukannya, dan ada beberapa komentar bagus di sini juga.

MV Sisi Klien* dengan Backbone.js, Marionette.js, dan Twitter Bootstrap

Banyak yang telah dikatakan tentang kerangka kerja MVC* untuk SPA. Ini adalah pilihan yang sulit, tetapi saya akan mengatakan bahwa tiga teratas adalah Backbone.js, Ember.js, dan Angular.js.

Ketiganya sangat dihormati. Tapi mana yang terbaik untuk Anda?

Sayangnya, saya harus mengakui bahwa saya memiliki pengalaman yang sangat terbatas dengan Angular.js, jadi saya akan mengabaikannya dari diskusi ini (untuk lebih lanjut tentang ini, lihat tutorial Angular.js). Sekarang, Ember.js dan Backbone.js mewakili dua cara berbeda untuk menyerang masalah yang sama.

Backbone.js minimal, sederhana, dan menawarkan Anda cukup untuk membuat SPA sederhana. Ember.js, di sisi lain, adalah kerangka kerja yang lengkap dan profesional untuk membuat SPA. Ini memiliki lebih banyak lonceng dan peluit, tetapi juga kurva belajar yang lebih besar.

Tergantung pada ukuran aplikasi Anda, keputusannya bisa semudah melihat rasio fitur yang digunakan/fitur yang tersedia, yang akan memberi Anda petunjuk besar.

Dalam kasus Init, saya ingin membahas sebagian besar skenario, jadi saya memilih Backbone.js untuk pembuatan SPA yang mudah, dengan Backbone.Marionette.View untuk komponenisasi. Dengan cara ini, setiap komponen adalah aplikasi sederhana, dan aplikasi akhir bisa serumit yang kita inginkan.

Penataan gaya juga merupakan tantangan, tetapi kita dapat mengandalkan kerangka kerja lagi untuk menyelamatkan kita. Untuk CSS, tidak ada yang lebih baik dari Twitter Bootstrap, yang menawarkan serangkaian gaya lengkap yang siap digunakan langsung dan mudah disesuaikan.

Bootstrap dibuat menggunakan bahasa KURANG, dan bersifat open source, sehingga kami dapat memodifikasinya jika perlu. Muncul dengan banyak kontrol UX yang didokumentasikan dengan baik di situs Bootstrap. Plus, ada model penyesuaian yang memungkinkan Anda membuatnya sendiri. Ini pasti orang untuk pekerjaan itu.

Praktik Terbaik: Grunt.js, Mocha.js, Chai.js, RequireJS, dan CoverJS

Terakhir, kita harus mendefinisikan beberapa praktik terbaik kita, dan melihat bagaimana Init dapat membantu Anda menerapkan dan memeliharanya. Solusi kami berpusat pada beberapa alat, yang didasarkan pada Node.js itu sendiri.

• Mocha.js dan Chai.js :

  Alat-alat ini memungkinkan Anda untuk meningkatkan proses pengembangan Anda dengan menerapkan TDD atau BDD, menyediakan infrastruktur untuk mengatur pengujian unit Anda dan runner untuk menjalankannya secara otomatis.

  Ada ribuan kerangka kerja pengujian unit untuk JavaScript. Jadi mengapa menggunakan Mocha.js? Jawaban singkatnya: fleksibel dan lengkap.

  Jawaban panjangnya: ia memiliki dua fitur penting (antarmuka, reporter) dan satu ketidakhadiran yang signifikan (pernyataan). Mari saya jelaskan.

  • Antarmuka : mungkin Anda terbiasa dengan konsep TDD suite dan unit test, atau mungkin Anda lebih suka ide BDD tentang spesifikasi perilaku dengan "jelaskan" dan "seharusnya". Mocha.js memungkinkan Anda menggunakan kedua pendekatan.

  • Reporter : menjalankan tes Anda akan menghasilkan laporan hasil, dan Anda dapat memformat hasil ini menggunakan berbagai reporter. Misalnya, jika Anda perlu memberi makan server Continuous Integration, Anda dapat menemukan reporter untuk melakukan hal itu.

  • Kurangnya perpustakaan pernyataan : jauh dari masalah, Mocha.js dirancang untuk memungkinkan Anda menggunakan perpustakaan pernyataan pilihan Anda, memberi Anda lebih banyak fleksibilitas. Ada banyak pilihan, tetapi di sinilah Chai.js berperan.

  Chai.js adalah pustaka pernyataan fleksibel yang memungkinkan Anda menggunakan salah satu dari tiga gaya pernyataan utama:

  • Assert : Gaya penegasan klasik dari sekolah tua TDD. Misalnya:

     assert.equal(variable, ”value”);

  • Harapkan : Gaya pernyataan yang dapat dirantai, paling umum digunakan di BDD. Misalnya:

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

  • Should : Juga digunakan di BDD, tapi saya lebih suka Expect karena Should terdengar berulang dengan spesifikasi perilaku 'it ("harus melakukan sesuatu..")'. Misalnya:

     variable.should.equal(“value”);

  Chai.js berpadu sempurna dengan Mocha.js. Dengan hanya menggunakan dua pustaka ini, Anda dapat menulis pengujian dalam TDD, BDD, atau gaya apa pun yang dapat dibayangkan.

• Grunt.js :

  Grunt.js memungkinkan Anda untuk mengotomatiskan tugas-tugas pembangunan, mulai dari copy-paste sederhana dan penggabungan file, hingga pra-kompilasi template, kompilasi gaya bahasa (yaitu, SASS dan KURANG), pengujian unit (dengan mocha.js), linting dan minifikasi kode (misalnya, dengan UglifyJS atau Closure Compiler). Anda dapat menambahkan tugas otomatis Anda sendiri ke Grunt, atau mencari registri Grunt, di mana terdapat ratusan dan ratusan plugin yang tersedia (sekali lagi, menggunakan alat dengan komunitas hebat di belakangnya akan terbayar). Grunt juga dapat memantau file Anda dan memicu tindakan saat diubah.

• Membutuhkan JS :

  RequireJS mungkin terdengar seperti cara lain untuk memuat modul dengan AMD, tetapi saya dapat memastikan bahwa itu lebih dari itu. Untuk memahami alasannya, pertama-tama kita perlu menyebutkan gagasan tentang namespace modul (misalnya, demo.views.hello), yang menghindari polusi namespace global dengan membungkus setiap modul dalam namespacenya sendiri. Masalahnya adalah, modul-modul ini tidak dapat digunakan kembali: jika Anda mengubah namespace dari satu 'instance', Anda sedang memodifikasi namespace dari semua 'instance'. Berbeda dengan itu, RequireJS memungkinkan Anda menentukan modul yang dapat digunakan kembali sejak awal. (Selain itu, ini akan membantu Anda merangkul Injeksi Ketergantungan untuk menghindari modul Anda mengakses variabel global.)

• CoverJS :

  Cakupan kode adalah metrik untuk mengevaluasi pengujian Anda. Seperti namanya, ini memberi tahu Anda berapa banyak kode Anda yang dicakup oleh rangkaian pengujian Anda saat ini. CoverJS mengukur cakupan kode pengujian Anda dengan melengkapi pernyataan (bukan baris kode seperti JSCoverage) dalam kode Anda dan menghasilkan versi kode yang diinstrumentasi. Itu juga dapat menghasilkan laporan untuk memberi makan Server Integrasi Berkelanjutan Anda.

Menggunakan Cabang untuk Beralih Fitur

Ketika saya memulai Init, saya membutuhkan cara bagi pengguna untuk mengaktifkan dan menonaktifkan berbagai fitur yang mungkin mereka inginkan dalam proyek mereka. Saya memutuskan untuk mengambil pendekatan radikal ke sistem cabang git untuk mengimplementasikan fungsi ini.

Intinya, setiap cabang mewakili fitur atau fungsionalitas yang mungkin ingin disertakan oleh pengguna. Jika Anda memulai proyek dari bawah ke atas, mulailah dari cabang minimal yang Anda perlukan, lalu tambahkan teknologi lain dengan menggabungkan cabang yang diinginkan. Misalnya, Anda ingin memulai proyek Anda dengan Backbone.js dan Marionette.js. Nah, Anda dapat memulai di cabang Backbone.js dan menggabungkannya dengan cabang Marionette, melanjutkan untuk setiap fungsi yang ingin Anda tambahkan.

Untuk saat ini, ide penggabungan untuk menambah fungsionalitas ini hanya dapat digunakan untuk template teknologi (misalnya, Backbone, Node, Express). Namun di masa mendatang, Anda akan dapat beralih antara implementasi back-end (misalnya, dari MongoDB ke Postgres) dan klien.

Mulai Proyek dengan Init dan Deploy ke Heroku Hari Ini

Tidak pernah ada cara yang lebih mudah untuk memulai sebuah proyek. Cukup buka repo GitHub, periksa cabang dengan komit terbaru (saat ini adalah pengelola pengguna, meskipun ini mungkin berubah di masa mendatang) dan kemudian:

1. Buat direktori untuk proyek Anda (atau gunakan yang sudah ada).
2. Buat repositori Anda dengan "git init" (atau gunakan repositori yang ada).

3. Tambahkan remote dengan init

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

4. Dapatkan cabang yang Anda inginkan

    git pull init usermanager

5. Dapatkan file proses Heroku

    git pull init heroku-webprocess

6. Dengan Heroku Toolbelt terpasang, buat aplikasi Heroku

    heroku create

7. Dorong cabang master Anda ke Heroku

    git push heroku master

8. Kunjungi aplikasi Anda, aktif dan berjalan di Heroku!

Sekarang Anda dapat mulai mengembangkan fitur pembunuh hanya dengan beberapa baris kode. Tidak hanya itu, tetapi Anda akan berkembang dengan teknologi terbaru dan paling efisien dalam rangkaian pengembangan yang seotomatis mungkin.

Saya harap Anda dapat menggunakan Init untuk memulai ide besar Anda berikutnya. Ingatlah untuk memeriksa repositori Init untuk perbaikan dan fitur baru—pengembangannya sangat aktif, dan saya menantikan tanggapan Anda.