Init.js: Full-Stack JavaScript'in Nedeni ve Nasılına İlişkin Kılavuz

Hikaye

Yani, siz ve kurucu ortağınız bir iş için harika bir fikriniz var, değil mi?

Zihninize özellikler ekliyorsunuz.

Sık sık potansiyel müşterilere fikirlerini sorarsınız ve hepsi buna bayılır.

Tamam, yani insanlar bunu istiyor. Hatta yapılacak bir miktar para var. Ve sahip olamamalarının tek nedeni, henüz uygulamamış olmanızdır.

Sonunda bir gün oturup “Hadi yapalım!” diyorsunuz. Yakında, uygulamanızın iş mantığını nasıl uygulayacağınızı bulmaya çalışıyorsunuz, ürünü ileriye götürecek öldürücü özellik: nasıl yapılacağına dair bir fikriniz var ve bunu yapabileceğinizi biliyorsunuz.

"Tamamlandı! İşe yarıyor!" diyorsun. Kavram kanıtınız bir başarıdır! Geriye kalan tek şey onu bir web uygulamasına paketlemek.

“Tamam siteyi oluşturalım” diyorsunuz.

Ve sonra gerçeği anlıyorsunuz: bir programlama dili seçmeniz gerekiyor; (modern) bir platform seçmeniz gerekiyor; bazı (modern) çerçeveler seçmeniz gerekir; depolama, veritabanları ve barındırma sağlayıcılarını yapılandırmanız (ve satın almanız) gerekir; bir yönetici arayüzüne ihtiyacınız var; bir izin sistemine ihtiyacınız var; bir içerik yöneticisine ihtiyacınız var.

Vermeniz gereken onlarca mimari karar var. Ve doğru olanları yapmak istiyorsunuz: hızlı gelişme, sürekli yineleme, maksimum verimlilik, hız, sağlamlık ve daha fazlasını sağlayan teknolojileri kullanmak istiyorsunuz. Yalın olmak istiyorsun, çevik olmak istiyorsun. Kısa ve uzun vadede başarılı olmanıza yardımcı olacak teknolojileri kullanmak istiyorsunuz. Ve onları seçmek her zaman kolay değildir.

"Bunaldım," diyorsunuz, bunalmış gibi hissediyorsunuz. Enerjiniz eskisi gibi değil. Parçaları bir araya getirmeye çalışıyorsun, ama bu çok fazla iş.

Kavram kanıtınız yavaş yavaş solar ve ölür.

Öneri

Bu şekilde tonlarca fikirden vazgeçtikten sonra bir çözüm tasarlamaya karar verdim. Ben buna 'Init' projesi (veya init.js) diyorum.

Bu fikrin özü, hepsini başlatmak için tek bir projeye sahip olmak, geliştiricinin veya teknik kurucunun tüm bu önemli kararları bir kerede vermesine izin vermek ve bu kararlara dayalı uygun bir başlangıç ​​şablonu almaktır. Kötüleyenlerin "Her soruna tek bir çözüm uygulanamaz" (nefret edenler nefret edecek) diyeceklerini biliyorum. Ve haklı olabilirler. Ancak yaklaşık bir çözüm oluşturmak için elimizden gelenin en iyisini yapabiliriz ve bence Init oldukça yakın.

Bu hedefe en iyi şekilde ulaşmak için, birkaç temel fikri aklımızda tutmalıyız. Init'i geliştirirken şunları düşündüm:

• Bileşenler

  Init'in temel amacı olan farklı projelerde yazılım bileşenlerini yeniden kullanmanıza izin verdiği için bileşenleştirme, herhangi bir sistemin temel özelliğidir. Ancak bileşenleştirme, aynı zamanda "neredeyse" aynı çözümle birkaç farklı soruna saldırmada en iyi müttefikimiz olacak bir yan ürün olan "değiştirilebilirlik" ile birlikte gelir.

• Geliştirme Kolaylığı

  Bazı problemler, bir yerlerde en iyi Brainf*ck ile yazılmış bir çözümü vardır. Ancak bu çözümü (Brainfuck'ta) uygulamak, bırakın okumayı bırakın, yazmak neredeyse imkansız olacaktır. Size zaman ve çok büyük bir çaba harcatacaktır. Genel olarak, geliştirmeyi sizin (veya daha sonra üzerinde çalışabilecek herhangi biri) için zorlaştırmayan, kolaylaştıran diller ve platformlar kullanmalısınız.

• Toplum

  Hangi platformu seçerseniz seçin, büyük bir topluluğa sahip olduğundan ve en yaygın ve olağandışı sorunlarda size yardımcı olabilecek bir topluluğa sahip olduğundan emin olun. Unutmayın: jQuery en hızlı, en temiz veya en zarif kitaplık olmayabilir - ancak topluluğu nedeniyle bir kazanandır.

Bu hedefleri göz önünde bulundurarak, Init'i oluştururken kendi kararlarımı nasıl verdiğimi size göstereceğim.

Özünde Init, 'tam yığın JavaScript' paradigmasından yararlanır (bazı insanlar buna veya bunun bir alt kümesine MEAN Yığını olarak atıfta bulunur). Init, böyle bir yığınla çalışarak, web uygulamaları geliştirmek için inanılmaz derecede esnek ve tam özellikli bir ortam yaratırken yalnızca tek bir dil kullanabilir. Kısacası Init, JavaScript'i yalnızca istemci ve sunucu geliştirme için değil, aynı zamanda oluşturma, test etme, şablon oluşturma ve daha fazlası için kullanmanıza olanak tanır.

Ama biraz yavaşlayalım ve kendimize şunu soralım: JavaScript kullanmak gerçekten iyi bir fikir mi?

Neden JavaScript'i Seçtim

1998'den beri web geliştiricisiyim. O zamanlar sunucu tarafı geliştirmemizin çoğu için Perl kullanıyorduk, ancak o zamandan beri bile istemci tarafında JavaScript'imiz vardı. Web sunucusu teknolojileri o zamandan beri çok değişti: PHP, AP, JSP, .NET, Ruby, Python gibi dalga dalga dil ve teknolojilerden geçtik, sadece birkaçını saymak gerekirse. Geliştiriciler, istemci ve sunucu ortamları için iki farklı dil kullanmanın işleri karmaşık hale getirdiğini fark etmeye başladılar. Tek bir dil altında birleştirmeye yönelik ilk girişimler, sunucuda istemci bileşenleri oluşturmaya ve bunları JavaScript'e derlemeye çalıştı. Bu beklendiği gibi çalışmadı ve bu projelerin çoğu başarısız oldu (örneğin: ASP.NET web formlarının yerini alan ASP MVC ve yakın gelecekte GWT'nin yerini muhtemelen Polimer alacak). Ancak özünde harika bir fikirdi: istemci ve sunucu üzerinde bileşenleri ve kaynakları yeniden kullanmamıza izin veren tek bir dil (bu anahtar kelime: kaynaklar ).

Cevap basitti: JavaScript'i sunucuya yerleştirin.

JavaScript aslında Netscape Enterprise Server'da JavaScript Sunucu Tarafı ile doğdu, ancak dil o sırada hazır değildi. Yıllarca süren deneme ve yanılmalardan sonra, yalnızca JavaScript'i sunucuya yerleştirmekle kalmayıp aynı zamanda engellemesiz programlama fikrini teşvik eden ve bir "fread" (G/Ç) yazma şeklimizi sonsuza dek değiştiren Node.js nihayet ortaya çıktı (buradan okuyun) daha fazlası için).

Ancak bu fikirler yeni değildi - peki neden Node.js ile bu kadar popüler oldular? Basit, bloke etmeyen programlama birkaç yolla elde edilebilir. Belki de en kolayı geri aramaları ve bir olay döngüsünü kullanmaktır. Çoğu dilde bu kolay bir iş değildir: 'geri aramalar' diğer bazı dillerde yaygın bir özellik olsa da, bir olay döngüsü değildir ve genellikle kendinizi harici kitaplıklarla boğuşurken bulursunuz (örneğin: Python, Tornado ile). Ancak JavaScript'te, olay döngüsünde olduğu gibi geri aramalar dilde yerleşiktir ve JavaScript'le uğraşan hemen hemen her programcı onlara aşinadır (veya olayın ne olduğunu tam olarak anlamasalar bile en azından bunları kullanmıştır). döngü). Birdenbire, Dünya'daki her başlangıç, geliştiricileri (yani kaynakları) hem istemci hem de sunucu tarafında yeniden kullanabilir ve “Python Guru Needed” iş ilanı sorununu çözebilir.

Şimdi, (JavaScript sayesinde) kullanımı inanılmaz derecede kolay bir programlama dili ile inanılmaz hızlı bir platforma sahibiz (engellemeyen programlama sayesinde). Ama yeterli mi? sürecek mi? JavaScript'in gelecekte önemli bir yere sahip olacağına eminim. Nedenini söyleyeyim:

• Fonksiyonel Programlama

  JavaScript, işlevsel paradigmayı kitlelere ulaştıran ilk programlama diliydi (elbette, Lisp önce geldi, ancak çoğu programcı hiçbir zaman Lisp kullanarak üretime hazır bir uygulama geliştirmedi). Javascript'in ana etkileri olan Lisp ve Self, yenilikçi fikirlerle doludur. Bu fikirler, yeni teknikleri, kalıpları ve paradigmaları keşfetmek için zihinlerimizi özgürleştirebilir. Ve hepsi JavaScript'e taşınır. Monad'lara, Kilise numaralarına ve hatta (daha pratik bir örnek için) Underscore.js'nin size satır ve kod satırları kazandırabilecek koleksiyon işlevlerine bir göz atın.

• Dinamik Nesneler ve Prototip devralma

  Sınıflar olmadan (ve sonsuz sınıf hiyerarşileri olmadan) Nesne Yönelimli Programlama, hızlı geliştirmeye (nesneler oluşturun, yöntemler ekleyin ve bunları kullanın) izin verir, ancak en önemlisi, programcının bunun yerine nesne örneklerini değiştirmesine izin vererek bakım görevleri sırasında yeniden düzenleme süresini azaltır. sınıfların. Bu hız ve esneklik, hızlı gelişimin önünü açmaktadır.

• JavaScript İnternet'tir

  JavaScript İnternet için tasarlandı, başından beri burada ve yok olmuyor. Onu yok etmeye yönelik tüm girişimler başarısız oldu: örneğin Java Uygulamalarının çöküşü, VBScript'in Microsoft'un TypeScript'i (JavaScript'i derleyen) ile değiştirmesi ve Flash'ın mobil pazarın ve HTML5'in elindeki ölümü. Milyonlarca web sayfasını bozmadan Javascript'i değiştirmek imkansızdır, bu nedenle ileriye dönük hedeflerimiz onu geliştirmek olmalıdır. Ve bu iş için ECMA'dan Teknik Komite 39'dan daha iyi kimse yok.

  Tamam, JavaScript'e alternatifler, CoffeeScript, TypeScript ve JavaScript'i derleyen milyonlarca dil gibi her gün doğar. Bu alternatifler geliştirme aşamaları için faydalı olabilir (kaynak haritaları aracılığıyla), ancak uzun vadede JavaScript'in yerini alamazlar iki nedenden dolayı: toplulukları asla daha büyük olmayacak ve en iyi özellikleri ECMA betiği (yani JavaScript) tarafından benimsenecektir. ). JavaScript bir montaj dili değildir: anlayabileceğiniz kaynak kodlu üst düzey bir programlama dilidir - bu yüzden onu anlamalısınız.

Uçtan Uca JavaScript: Node.js ve MongoDB

JavaScript kullanmanın nedenleri bunlardır. Şimdi Node.js ve MongoDB'yi kullanmak için JavaScript'i kullanacağım.

• Node.js

  Node.js, hızlı ve ölçeklenebilir ağ uygulamaları oluşturmaya yönelik bir platformdur; Node.js sitesinin söylediği aşağı yukarı budur. Ancak Node.js bundan daha fazlasıdır: G/Ç erişimi olan herhangi bir JavaScript uygulaması için tercih edilen çalışma zamanı ortamıdır. Ana sunucu uygulamanızı Node.js ile yazmayı planlamıyor olsanız bile, geliştirme sürecinizi iyileştirmek için Node.js üzerine kurulu araçları kullanabilirsiniz. Örneğin: Birim testi için Mocha.js, otomatikleştirilmiş derleme görevleri için Grunt.js ve hatta tam metin kodu düzenleme için Parantezler.

  Dolayısıyla, sunucu veya istemci için JavaScript uygulamaları yazacaksanız, bazı Node.js örneklerine bir göz atmalısınız, çünkü buna günlük olarak ihtiyacınız olacak ve kullanacaksınız. Bazı ilginç alternatifler var, ancak hiçbiri Node.js topluluğunun %10'unda bile değil.

• MongoDB

  MongoDB, sorgu dili olarak JavaScript'i kullanan ve uçtan uca JavaScript platformunu tamamlamama izin veren NoSQL belge tabanlı bir veritabanıdır. Ancak bu veritabanını seçmenin ana nedeni bu bile değil.

  MongoDB, nesnelerinizi esnek bir şekilde sürdürmenize ve böylece gereksinimlerdeki değişikliklere daha hızlı uyum sağlamanıza olanak tanıyan şemasız bir veritabanıdır. Ayrıca, yüksek düzeyde ölçeklenebilir ve harita küçültme tabanlı olması, onu büyük veri uygulamaları için uygun hale getirir. MongoDB o kadar esnektir ki, şemasız bir belge veritabanı, ilişkisel bir veri deposu (işlemlerden yoksun olmasına rağmen) veya hatta yanıtları önbelleğe almak için bir anahtar-değer deposu olarak kullanılabilir.

  

Express.js ile Sunucu Bileşenleştirme

Sunucu taraflı bileşenleştirme asla kolay değildir. Ancak Express.js (ve Connect.js) ile 'ara katman yazılımı' fikri ortaya çıktı. Bence, ara katman yazılımı, sunucudaki bileşenleri tanımlamanın en iyi yoludur. Bilinen bir modelle karşılaştırmak isterseniz, borulara ve filtrelere oldukça yakındır.

Temel fikir, bileşeninizin bir boru hattının parçası olmasıdır. Ardışık düzen bir isteği (girdi) işler ve bir yanıt (çıktı) oluşturur, ancak bileşeniniz yanıtın tamamından sorumlu değildir. Bunun yerine, yalnızca ihtiyaç duyduğu şeyi değiştirir ve ardından ardışık düzenin bir sonraki parçasına delege eder. İşlem hattının son parçasının işlenmesi bittiğinde, yanıt müşteriye geri gönderilir.

Bu 'boru hattının parçalarını' 'ara katman yazılımı' olarak adlandırıyoruz. Açıkçası, iki tür ara katman yazılımı oluşturabiliriz:

• Aracılar : İsteği ve yanıtı işleyen, ancak yanıtın kendisinden tam olarak sorumlu olmayanlar, bu nedenle bir sonraki ara katman yazılımına devrediyorlar.

• Finaller : Nihai yanıt üzerinde tüm sorumluluğu olanlar. İsteği ve yanıtı işler ve değiştirirler, ancak bir sonraki ara katman yazılımına yetki vermeleri gerekmez. Pratikte, mimari esnekliğe izin vermek için bir sonraki ara katman yazılımına yetki vermeniz önerilir (yani, daha sonra daha fazla ara katman yazılımı ekleme), bu ara katman yazılımı mevcut olmasa bile (bu durumda yanıt doğrudan istemciye gider).

Somut bir örnek olarak, sunucudaki bir 'kullanıcı yöneticisi' bileşenini düşünün. Ara katman yazılımı açısından, hem finallere hem de ara ürünlere sahip olurduk. Finallerimiz için kullanıcı oluşturma ve kullanıcıları listeleme gibi özelliklerimiz olurdu. Ancak bu eylemleri gerçekleştirmeden önce, kimlik doğrulama için ara öğelerimize ihtiyacımız var (kimliği doğrulanmamış isteklerin gelip kullanıcı oluşturmasını istemediğimizden). Bu kimlik doğrulama ara araçlarını oluşturduktan sonra, daha önce kimliği doğrulanmamış bir özelliği kimliği doğrulanmış bir özelliğe dönüştürmek için bunları istediğimiz herhangi bir yere takabiliriz.

Tek Sayfa Uygulamaları

Init projesi, tek sayfalık uygulamalar (SPA) oluşturmaya odaklanır. Çoğu web geliştiricisi, SPA'larda ellerini denemek için bir kereden fazla cazip olmuştur. Birkaç tane oluşturdum (çoğunlukla tescilli) ve bunların web uygulamalarının geleceği olduklarını güvenle söyleyebilirim. SPA'yı hiç mobil bağlantıdaki normal bir web uygulamasıyla karşılaştırdınız mı? Tepkideki fark, onlarca saniye mertebesindedir.

SPA'lar web'in geleceğidir - o halde neden ürününüzü eski bir biçimde oluşturasınız? Duyduğum yaygın bir argüman, insanların SEO konusunda endişeli olduğu. Ancak işleri doğru bir şekilde hallederseniz, bu bir sorun olmamalı: Google'ın kendisinin bunun nasıl yapılacağı konusunda çok iyi bir öğreticisi var ve burada da bazı iyi yorumlar var.

Backbone.js, Marionette.js ve Twitter Bootstrap ile İstemci Tarafı MV*

SPA'lar için MVC* çerçeveleri hakkında çok şey söylendi. Zor bir seçim ama ilk üçün Backbone.js, Ember.js ve Angular.js olduğunu söyleyebilirim.

Üçü de çok iyi değerlendiriliyor. Ama hangisi senin için en iyisi?

Ne yazık ki, Angular.js ile çok sınırlı deneyimim olduğunu itiraf etmeliyim, bu yüzden onu bu tartışmanın dışında bırakacağım (bununla ilgili daha fazla bilgi için Angular.js eğitimine bakın). Şimdi, Ember.js ve Backbone.js, aynı soruna saldırmanın iki farklı yolunu temsil ediyor.

Backbone.js minimaldir, basittir ve size basit bir SPA yaratmaya yetecek kadarını sunar. Ember.js ise SPA'lar oluşturmak için eksiksiz ve profesyonel bir çerçevedir. Daha fazla zil ve ıslık var, aynı zamanda daha büyük bir öğrenme eğrisi var.

Uygulamanızın boyutuna bağlı olarak, karar vermek, size büyük bir ipucu verecek olan özelliklerKullanılan/özelliklerKullanılabilir oranına bakmak kadar kolay olabilir.

Init durumunda, çoğu senaryoyu kapsamak istedim, bu yüzden bileşenleştirme için Backbone.Marionette.View ile kolay SPA oluşturma için Backbone.js'yi seçtim. Bu şekilde, her bileşen basit bir uygulamadır ve nihai uygulama istediğimiz kadar karmaşık olabilir.

Şekillendirme de bir zorluktur, ancak bizi kurtarmak için çerçevelere tekrar güvenebiliriz. CSS için, hem kullanıma hazır hem de özelleştirmesi kolay, eksiksiz bir stil seti sunan Twitter Bootstrap'tan daha iyisi yoktur.

Bootstrap, LESS dili kullanılarak oluşturulmuştur ve açık kaynaktır, böylece gerekirse değiştirebiliriz. Bootstrap sitesinde iyi belgelenmiş bir ton UX kontrolü ile birlikte gelir. Ayrıca, kendinizinkini yaratmanıza izin veren bir özelleştirme modeli var. Kesinlikle bu iş için adam.

En İyi Uygulamalar: Grunt.js, Mocha.js, Chai.js, RequireJS ve CoverJS

Son olarak, en iyi uygulamalarımızdan bazılarını tanımlamalı ve Init'in bunları uygulamanıza ve sürdürmenize nasıl yardımcı olabileceğine bakmalıyız. Çözümümüz, Node.js'nin kendisine dayanan çeşitli araçlara odaklanmıştır.

• Mocha.js ve Chai.js :

  Bu araçlar, birim testlerinizi organize etmek için altyapı ve bunları otomatik olarak çalıştırmak için bir koşucu sağlayarak TDD veya BDD uygulayarak geliştirme sürecinizi iyileştirmenize olanak tanır.

  JavaScript için binlerce birim test çerçevesi vardır. Peki neden Mocha.js kullanmalısınız? Kısa cevap: esnek ve eksiksiz.

  Uzun cevap: iki önemli özelliği (arayüzler, muhabirler) ve bir önemli eksikliği (iddialar) vardır. Açıklamama izin ver.

  • Arayüzler : belki TDD takımları ve birim testleri kavramlarına alışkınsınız veya belki de "açıklama" ve "olması gerekir" ile BDD davranış özellikleri fikirlerini tercih ediyorsunuz. Mocha.js, her iki yaklaşımı da kullanmanıza izin verir.

  • Muhabirler : Testinizi çalıştırmak, sonuçların raporlarını oluşturacaktır ve bu sonuçları çeşitli muhabirler kullanarak biçimlendirebilirsiniz. Örneğin, bir Sürekli Entegrasyon sunucusunu beslemeniz gerekiyorsa, bunu yapacak bir muhabir bulabilirsiniz.

  • İddia kitaplığının olmaması : Sorun olmaktan çok uzak olan Mocha.js, tercih ettiğiniz iddia kitaplığını kullanmanıza izin vererek size daha fazla esneklik sağlamak için tasarlanmıştır. Pek çok seçenek var ama burada Chai.js devreye giriyor.

  Chai.js, üç ana onaylama stilinden herhangi birini kullanmanıza izin veren esnek bir onaylama kitaplığıdır:

  • Assert : TDD eski okulundan klasik iddia stili. Örneğin:

     assert.equal(variable, ”value”);

  • Beklenti : En yaygın olarak BDD'de kullanılan zincirlenebilir iddia stili. Örneğin:

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

  • Gerekir : BDD'de de kullanılır, ancak Bekle'yi tercih ederim, çünkü 'it (“bir şey yapmalı..”)' davranış belirtimi ile tekrarlanan bir şey gibi geliyor. Örneğin:

     variable.should.equal(“value”);

  Chai.js, Mocha.js ile mükemmel bir şekilde birleşir. Sadece bu iki kütüphaneyi kullanarak testlerinizi TDD, BDD veya hayal edebileceğiniz herhangi bir stilde yazabilirsiniz.

• Grunt.js :

  Grunt.js, basit kopyala-yapıştır ve dosyaların birleştirilmesinden şablon ön derlemesine, stil dili (yani, SASS ve LESS) derlemesine, birim testi (mocha.js ile), linting ve kod küçültme (örneğin, UglifyJS veya Closure Compiler ile). Kendi otomatik görevinizi Grunt'a ekleyebilir veya yüzlerce eklentinin mevcut olduğu Grunt kayıt defterinde arama yapabilirsiniz (yine, arkalarında harika topluluklara sahip araçları kullanmak işe yarar). Grunt ayrıca dosyalarınızı izleyebilir ve değiştirildiğinde eylemleri tetikleyebilir.

• JS gerektirir :

  RequireJS, AMD ile modül yüklemenin başka bir yolu gibi görünebilir, ancak bundan çok daha fazlası olduğundan emin olabilirsiniz. Nedenini anlamak için öncelikle, her modülü kendi ad alanına sararak global ad alanını kirletmekten kaçınan modül ad alanı fikrinden (örn. demo.views.hello) bahsetmemiz gerekir. Sorun şu ki, bu modüller yeniden kullanılamaz: bir 'örnek'in ad alanını değiştirirseniz, tüm 'örneklerin' ad alanını değiştirirsiniz. Bunun aksine, RequireJS yeniden kullanılabilir modülleri en baştan tanımlamanıza izin verir. (Ayrıca, modüllerinizin global değişkenlere erişmesini önlemek için Dependency Injection'ı benimsemenize yardımcı olur.)

• CoverJS :

  Kod kapsamı, testinizi değerlendirmek için bir ölçümdür. Adından da anlaşılacağı gibi, kodunuzun ne kadarının mevcut test takımınız tarafından kapsandığını söyler. CoverJS, kodunuzdaki ifadeleri kullanarak (JSCoverage gibi kod satırları yerine) testlerinizin kod kapsamını ölçer ve kodunuzun araçlı bir sürümünü oluşturur. Ayrıca Sürekli Entegrasyon Sunucunuzu beslemek için raporlar oluşturabilir.

Özellikleri Değiştirmek için Dalları Kullanma

Init'i başlattığımda, kullanıcıların projelerinde isteyebilecekleri çeşitli özellikleri etkinleştirip devre dışı bırakmaları için bir yola ihtiyacım vardı. Bu işlevi uygulamak için git'in şube sistemine radikal bir yaklaşım benimsemeye karar verdim.

Özünde, her dal, bir kullanıcının dahil etmek isteyebileceği bir özelliği veya işlevi temsil eder. Sıfırdan bir projeye başlıyorsanız, ihtiyacınız olan minimum dalla başlayın ve ardından istediğiniz dallarla birleştirerek diğer teknolojileri ekleyin. Örneğin projenize Backbone.js ve Marionette.js ile başlamak istediğinizi varsayalım. Pekala, Backbone.js şubesinden başlayabilir ve onu Marionette şubesiyle birleştirebilir, eklemek istediğiniz her bir işlevsellik parçası için ilerleyebilirsiniz.

Şimdilik, işlevsellik eklemek için bu birleştirme fikri yalnızca teknoloji şablonları için kullanılabilir (örneğin, Omurga, Düğüm, Ekspres). Ancak gelecekte, arka uç (örn. MongoDB'den Postgres'e) ve istemci uygulamaları arasında geçiş yapabileceksiniz.

Init ile Bir Proje Başlatın ve Bugün Heroku'ya Dağıtın

Bir projeye başlamak için hiç bu kadar kolay bir yol olmamıştı. GitHub deposuna gidin, en son taahhütlere sahip şubeyi kontrol edin (şu anda kullanıcı yöneticisidir, ancak bu gelecekte değişebilir) ve ardından:

1. Projeniz için dizini oluşturun (veya mevcut bir dizini kullanın).
2. Deponuzu “git init” ile oluşturun (veya mevcut depoyu kullanın).

3. init ile bir uzaktan kumanda ekleyin

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

4. istediğin şubeyi al

    git pull init usermanager

5. Heroku işlem dosyasını alın

    git pull init heroku-webprocess

6. Heroku Toolbelt kuruluyken, bir Heroku uygulaması oluşturun

    heroku create

7. Ana şubenizi Heroku'ya itin

    git push heroku master

8. Uygulamanızı ziyaret edin, Heroku'da çalışır durumda!

Artık sadece birkaç satır kod ile öldürücü özelliğinizi geliştirmeye başlayabilirsiniz. Sadece bu da değil, olabildiğince otomatikleştirilmiş bir geliştirme paketinde en son ve en verimli teknolojilerle geliştirme yapıyor olacaksınız.

Umarım bir sonraki büyük fikrinizi başlatmak için Init'i kullanabilirsiniz. Yeni düzeltmeler ve özellikler için Init deposunu kontrol etmeyi unutmayın; geliştirmesi çok canlı ve geri bildiriminizi duymak için sabırsızlanıyorum.