Init.js: 전체 스택 JavaScript의 이유와 방법 가이드

이야기

자, 당신과 당신의 공동 창립자는 비즈니스에 대한 훌륭한 아이디어를 가지고 있습니다. 맞습니까?

당신은 당신의 마음에 기능을 추가했습니다.

자주 잠재 고객에게 의견을 물어보면 모두 좋아합니다.

좋아요, 그래서 사람들은 그것을 원합니다. 벌어야 할 돈도 있습니다. 그리고 그들이 그것을 가질 수 없는 유일한 이유는 당신이 그것을 아직 구현하지 않았기 때문입니다.

그래서 마침내 어느 날 앉아서 "하자!"라고 말합니다. 곧, 당신은 앱의 비즈니스 로직을 구현하는 방법, 제품을 발전시킬 킬러 기능을 알아내려고 노력하고 있습니다. 당신은 그것을 하는 방법에 대한 아이디어가 있고 당신이 할 수 있다는 것을 압니다.

"완료! 효과가있다!" 당신은 말한다. 개념 증명이 성공했습니다! 남은 것은 웹 앱으로 패키징하는 것뿐입니다.

"자, 사이트를 만들어 봅시다."라고 말합니다.

그리고 나서 진실을 깨닫게 됩니다. 프로그래밍 언어를 선택해야 합니다. (현대) 플랫폼을 선택해야 합니다. 일부 (현대) 프레임워크를 선택해야 합니다. 스토리지, 데이터베이스 및 호스팅 제공업체를 구성(및 구매)해야 합니다. 관리자 인터페이스가 필요합니다. 권한 시스템이 필요합니다. 콘텐츠 관리자가 필요합니다.

수십만 개의 아키텍처 결정을 내려야 합니다. 그리고 올바른 것을 만들고 싶어 합니다. 빠른 개발, 지속적인 반복, 최대 효율성, 속도, 견고성 등을 가능하게 하는 기술을 사용하기를 원합니다. 당신은 날씬하고 싶어, 당신은 민첩하고 싶어. 장단기적으로 성공하는 데 도움이 되는 기술을 사용하려고 합니다. 그리고 그것들을 선택하기가 항상 쉬운 것은 아닙니다.

압도당했다고 느끼면서 "나는 압도당했습니다."라고 말합니다. 당신의 에너지는 예전과 같지 않습니다. 당신은 일을 함께 조각하려고 노력하지만 너무 많은 작업입니다.

개념 증명은 서서히 시들어 가고 죽습니다.

제안

이런 식으로 수많은 아이디어를 포기한 후 솔루션을 설계하기로 결정했습니다. 저는 그것을 'Init' 프로젝트(또는 init.js)라고 부릅니다.

아이디어의 핵심은 모든 것을 시작하는 단일 프로젝트를 갖고 개발자 또는 기술 설립자가 이러한 모든 필수 결정을 한 번에 내리고 이러한 결정을 기반으로 적절한 시작 템플릿을 받을 수 있도록 하는 것입니다. 나는 비방하는 사람들이 "하나의 솔루션이 모든 문제에 적용될 수는 없다"고 말하는 것을 압니다(싫어하는 사람들은 싫어할 것입니다). 그리고 그들이 옳을 수도 있습니다. 그러나 우리는 대략적인 솔루션을 만들기 위해 최선을 다할 수 있으며 Init가 매우 가깝다고 생각합니다.

이 목표를 가장 잘 달성하려면 몇 가지 핵심 아이디어를 염두에 두어야 합니다. Init를 개발할 때 다음을 고려했습니다.

• 구성품

  구성 요소화는 Init의 주요 목표인 다양한 프로젝트에서 소프트웨어 구성 요소를 재사용할 수 있도록 하므로 모든 시스템의 핵심 특성입니다. 그러나 구성 요소화에는 부산물인 "대체 가능성"도 수반되며, 이는 "거의" 동일한 솔루션으로 여러 가지 다른 문제를 공격하는 데 가장 좋은 동맹이 될 것입니다.

• 개발 용이성

  어떤 문제, 어딘가에 Brainf*ck로 가장 잘 작성된 솔루션이 있습니다. 그러나 (Brainfuck에서) 그 솔루션을 구현하는 것은 읽기는 고사하고 쓰기가 거의 불가능할 것입니다. 시간과 엄청난 노력이 필요합니다. 일반적으로 개발을 더 쉽게 만드는 언어와 플랫폼을 사용해야 합니다. 사용자(또는 나중에 작업할 수 있는 사람)가 더 어려워서는 안 됩니다.

• 지역 사회

  어떤 플랫폼을 선택하든 큰 커뮤니티가 있고 가장 일반적이고 흔하지 않은 문제를 해결할 수 있는 커뮤니티가 있는지 확인하십시오. 기억하십시오: jQuery는 가장 빠르거나 가장 깨끗하거나 가장 우아한 라이브러리는 아니지만 커뮤니티 덕분에 승자가 됩니다.

이러한 목표를 염두에 두고 다음에는 내가 Init를 만들 때 스스로 결정한 방법을 보여 드리겠습니다.

기본적으로 Init는 '전체 스택 JavaScript' 패러다임을 활용합니다(일부 사람들은 이를 MEAN 스택이라고 하거나 하위 집합이라고 함). 이러한 스택으로 작업함으로써 Init는 웹 앱 개발을 위한 매우 유연하고 완전한 기능을 갖춘 환경을 만드는 동시에 단일 언어만 사용할 수 있습니다. 간단히 말해서 Init를 사용하면 클라이언트 및 서버 개발뿐만 아니라 빌드, 테스트, 템플릿 등을 위해 JavaScript를 사용할 수 있습니다.

그러나 잠시 속도를 늦추고 자문해 보겠습니다. JavaScript를 사용하는 것이 정말 좋은 생각입니까?

내가 자바스크립트를 선택한 이유

저는 1998년부터 웹 개발자였습니다. 그 당시에는 대부분의 서버 측 개발에 Perl을 사용했지만 그 이후로도 클라이언트 측에는 JavaScript가 있었습니다. 웹 서버 기술은 그 이후로 엄청나게 변화했습니다. 우리는 몇 가지 예를 들면 PHP, AP, JSP, .NET, Ruby, Python과 같은 언어와 기술의 물결을 거듭했습니다. 개발자들은 클라이언트와 서버 환경에 대해 두 가지 다른 언어를 사용하는 것이 복잡하다는 것을 깨닫기 시작했습니다. 단일 언어로 통합하려는 초기 시도는 서버에 클라이언트 구성 요소를 만들고 JavaScript로 컴파일하려고 했습니다. 이것은 예상대로 작동하지 않았고 대부분의 프로젝트가 실패했습니다(예: ASP.NET 웹 양식을 대체하는 ASP MVC, 가까운 장래에 Polymer로 대체될 GWT). 그러나 본질적으로 좋은 아이디어였습니다. 클라이언트와 서버의 단일 언어로 구성 요소와 리소스를 재사용할 수 있었습니다(키워드: resources ).

대답은 간단했습니다. JavaScript를 서버에 두십시오.

JavaScript는 Netscape Enterprise Server의 JavaScript Server Side와 함께 실제로 탄생했지만 그 당시에는 언어가 준비되지 않았습니다. 수년간의 시행착오 끝에 마침내 Node.js가 등장하여 서버에 JavaScript를 탑재했을 뿐만 아니라 비차단 프로그래밍에 대한 아이디어를 장려하여 "fread"(I/O) 작성 방식을 영원히 변경했습니다(여기 읽기 이상).

그러나 이러한 아이디어는 새로운 것이 아니었습니다. 그렇다면 Node.js에서 왜 그렇게 인기를 끌게 되었습니까? 간단한 비차단 프로그래밍은 여러 가지 방법으로 달성할 수 있습니다. 아마도 가장 쉬운 방법은 콜백과 이벤트 루프를 사용하는 것입니다. 대부분의 언어에서 이는 쉬운 일이 아닙니다. 일부 다른 언어에서는 '콜백'이 일반적인 기능이지만 이벤트 루프는 그렇지 않으며 외부 라이브러리(예: Python, Tornado 포함)와 씨름하는 경우가 많습니다. 그러나 JavaScript에서는 이벤트 루프와 마찬가지로 콜백이 언어에 내장되어 있으며 JavaScript를 사용해 본 거의 모든 프로그래머는 이에 익숙합니다. 루프는). 갑자기 지구상의 모든 스타트업이 클라이언트 측과 서버 측 모두에서 개발자(즉, 리소스)를 재사용하여 "Python Guru Needed" 구인 문제를 해결할 수 있습니다.

이제 우리는 (자바스크립트 덕분에) 엄청나게 사용하기 쉬운 프로그래밍 언어로 엄청나게 빠른 플랫폼(비차단 프로그래밍 덕분에)을 갖게 되었습니다. 하지만 충분합니까? 지속되나요? 나는 JavaScript가 미래에 중요한 위치를 차지할 것이라고 확신합니다. 이유를 알려드리겠습니다.

• 함수형 프로그래밍

  JavaScript는 기능적 패러다임을 대중에게 제공한 최초의 프로그래밍 언어였습니다(물론 Lisp가 먼저 왔지만 대부분의 프로그래머는 Lisp를 사용하여 프로덕션에 즉시 사용할 수 있는 애플리케이션을 구축한 적이 없습니다). Javascript의 주요 영향인 Lisp and Self는 혁신적인 아이디어로 가득 차 있습니다. 그러한 아이디어는 새로운 기술, 패턴 및 패러다임을 탐구하는 데 우리의 마음을 자유롭게 할 수 있습니다. 그리고 그것들은 모두 JavaScript로 이어집니다. 모나드, 교회 번호, 또는 코드 줄과 줄을 절약할 수 있는 Underscore.js의 컬렉션 함수(보다 실용적인 예)를 살펴보세요.

• 동적 개체 및 프로토타입 상속

  클래스가 없는 객체 지향 프로그래밍(클래스의 끝없는 계층 구조 없음)은 빠른 개발(객체 생성, 메서드 추가 및 사용)을 허용하지만 가장 중요한 것은 프로그래머가 대신 객체의 인스턴스를 수정할 수 있도록 하여 유지 관리 작업 중 리팩토링 시간을 줄입니다. 수업의. 이러한 속도와 유연성은 빠른 개발을 위한 길을 열어줍니다.

• 자바스크립트는 인터넷이다

  JavaScript는 인터넷을 위해 설계되었으며 처음부터 존재했으며 사라지지 않을 것입니다. 이를 파괴하려는 모든 시도는 실패했습니다. 예를 들어, Java Applets의 몰락, VBScript가 Microsoft의 TypeScript(JavaScript로 컴파일됨)로 대체, Flash가 모바일 시장과 HTML5의 손에 몰락한 경우를 보십시오. 수백만 개의 웹 페이지를 손상시키지 않고 Javascript를 대체하는 것은 불가능하므로 앞으로의 목표는 이를 개선하는 것입니다. 그리고 ECMA의 Technical Committee 39보다 더 나은 사람은 없습니다.

  좋아, JavaScript의 대안은 CoffeeScript, TypeScript 및 JavaScript로 컴파일되는 수백만 개의 언어와 같이 매일 탄생합니다. 이러한 대안은 개발 단계(소스 맵을 통해)에 유용할 수 있지만 두 가지 이유로 장기적으로 JavaScript를 대체하지 못할 것입니다. 커뮤니티가 더 커질 수 없고 최고의 기능이 ECMA 스크립트(예: JavaScript ). JavaScript는 어셈블리 언어가 아닙니다. 이해할 수 있는 소스 코드가 있는 고급 프로그래밍 언어이므로 이해해야 합니다.

종단 간 JavaScript: Node.js 및 MongoDB

이것이 JavaScript를 사용하는 이유입니다. 이제 Node.js와 MongoDB를 사용하는 이유로 JavaScript를 사용하겠습니다.

• 노드.js

  Node.js는 빠르고 확장 가능한 네트워크 애플리케이션을 구축하기 위한 플랫폼입니다. Node.js 사이트에서 말하는 것과 거의 같습니다. 그러나 Node.js는 그 이상입니다. I/O 액세스 권한이 있는 모든 JavaScript 애플리케이션에 선호되는 런타임 환경입니다. Node.js로 메인 서버 애플리케이션을 작성할 계획이 없더라도 Node.js 위에 구축된 도구를 사용하여 개발 프로세스를 개선할 수 있습니다. 예: 단위 테스트를 위한 Mocha.js, 자동화된 빌드 작업을 위한 Grunt.js, 전체 텍스트 코드 편집을 위한 Brackets.

  따라서 서버 또는 클라이언트용 JavaScript 응용 프로그램을 작성하려는 경우 매일 필요하고 사용하기 때문에 몇 가지 Node.js 예제를 살펴봐야 합니다. 몇 가지 흥미로운 대안이 있지만 그 중 어느 것도 Node.js 커뮤니티의 10%에도 미치지 못합니다.

• 몽고DB

  MongoDB는 JavaScript를 쿼리 언어로 사용하는 NoSQL 문서 기반 데이터베이스로, 이를 통해 종단 간 JavaScript 플랫폼을 완성할 수 있습니다. 그러나 그것이 이 데이터베이스를 선택하는 주된 이유는 아닙니다.

  MongoDB는 유연한 방식으로 개체를 유지하고 요구 사항의 변화에 ​​더 빨리 적응할 수 있도록 하는 스키마가 없는 데이터베이스입니다. 또한 확장성이 뛰어나고 맵 축소 기반이므로 빅 데이터 애플리케이션에 적합합니다. MongoDB는 매우 유연하여 스키마가 없는 문서 데이터베이스, 관계형 데이터 저장소(트랜잭션은 없지만) 또는 캐싱 응답을 위한 키-값 저장소로도 사용할 수 있습니다.

Express.js를 사용한 서버 구성 요소화

서버 측 구성 요소화는 결코 쉬운 일이 아닙니다. 그러나 Express.js(및 Connect.js)에서 '미들웨어'라는 아이디어가 나왔습니다. 제 생각에는 미들웨어가 서버에서 구성 요소를 정의하는 가장 좋은 방법입니다. 알려진 패턴과 비교하려는 경우 파이프 및 필터에 매우 가깝습니다.

기본 아이디어는 구성 요소가 파이프라인의 일부라는 것입니다. 파이프라인은 요청(입력)을 처리하고 응답(출력)을 생성하지만 구성 요소가 전체 응답을 책임지는 것은 아닙니다. 대신 필요한 것만 수정하고 파이프라인의 다음 부분에 위임합니다. 파이프라인의 마지막 부분이 처리를 마치면 응답이 클라이언트로 다시 전송됩니다.

이러한 '파이프라인 조각'을 '미들웨어'라고 합니다. 분명히 두 가지 종류의 미들웨어를 만들 수 있습니다.

• Intermediate : 요청과 응답을 처리하지만 응답 자체에 대한 책임을 지는 것이 아니라 다음 미들웨어에 위임하는 것.

• 결선 : 최종 응답에 대한 전적인 책임을 지는 자. 그들은 요청과 응답을 처리하고 수정하지만 다음 미들웨어에 위임할 필요가 없습니다. 실제로는 그 미들웨어가 존재하지 않는 경우에도(이 경우 응답이 클라이언트로 바로 전달됨) 아키텍처 유연성을 허용하기 위해 어쨌든 다음 미들웨어에 위임하는 것이 좋습니다(즉, 나중에 더 많은 미들웨어 추가).

구체적인 예로 서버의 '사용자 관리자' 구성 요소를 고려하십시오. 미들웨어의 관점에서, 우리는 최종 및 중급을 둘 다 가지고 있습니다. 결승전에는 사용자 생성 및 사용자 나열과 같은 기능이 있습니다. 그러나 이러한 작업을 수행하기 전에 인증을 위한 중간체가 필요합니다(인증되지 않은 요청이 들어오고 사용자를 생성하는 것을 원하지 않기 때문에). 이러한 인증 중간체를 만든 후에는 이전에 인증되지 않은 기능을 인증된 기능으로 전환하려는 모든 위치에 연결할 수 있습니다.

단일 페이지 애플리케이션

Init 프로젝트는 단일 페이지 애플리케이션(SPA) 생성에 중점을 둡니다. 대부분의 웹 개발자는 SPA에 손을 대고 싶은 유혹을 한 번 이상 받았습니다. 저는 몇 가지(대부분 독점)를 구축했으며 이것이 단순히 웹 애플리케이션의 미래라고 자신 있게 말할 수 있습니다. 모바일 연결에서 SPA를 일반 웹 앱과 비교한 적이 있습니까? 응답성의 차이는 수십 초 정도입니다.

SPA는 웹의 미래입니다. 그렇다면 레거시 형식으로 제품을 구축하는 이유는 무엇입니까? 내가 듣는 일반적인 주장은 사람들이 SEO에 대해 걱정한다는 것입니다. 그러나 일을 올바르게 처리하면 문제가 되지 않습니다. Google 자체에 그렇게 하는 방법에 대한 매우 좋은 자습서가 있으며 여기에도 좋은 설명이 있습니다.

Backbone.js, Marionette.js 및 Twitter 부트스트랩이 포함된 클라이언트 측 MV*

SPA용 MVC* 프레임워크에 대해 많이 언급되었습니다. 어려운 선택이지만 상위 3개는 Backbone.js, Ember.js, Angular.js라고 말하고 싶습니다.

셋 다 아주 좋은 평가를 받고 있습니다. 그러나 어느 것이 당신에게 가장 좋습니까?

불행히도 Angular.js에 대한 경험이 매우 제한적이라는 점을 인정해야 하므로 이 토론에서 생략하겠습니다(이에 대한 자세한 내용은 Angular.js 자습서 참조). 이제 Ember.js와 Backbone.js는 동일한 문제를 공격하는 두 가지 다른 방법을 나타냅니다.

Backbone.js는 최소한의 단순성을 제공하며 간단한 SPA를 생성하기에 충분합니다. 반면 Ember.js는 SPA를 만들기 위한 완전하고 전문적인 프레임워크입니다. 더 많은 종소리와 휘파람을 가지고 있지만 더 큰 학습 곡선도 있습니다.

애플리케이션의 크기에 따라 결정은 featuresUsed/featuresAvailable 비율을 보는 것만큼 쉬울 수 있으며, 이는 큰 힌트를 줄 것입니다.

Init의 경우 대부분의 시나리오를 다루고 싶었기 때문에 쉬운 SPA 생성을 위해 Backbone.js를 선택하고 구성 요소화를 위한 Backbone.Marionette.View를 선택했습니다. 이런 식으로 모든 구성 요소는 간단한 응용 프로그램이고 최종 응용 프로그램은 원하는 만큼 복잡할 수 있습니다.

스타일링도 도전이지만 우리를 구제해줄 프레임워크에 다시 의지할 수 있습니다. CSS의 경우, 바로 사용할 수 있고 사용자 정의하기 쉬운 완전한 스타일 세트를 제공하는 Twitter Bootstrap보다 더 좋은 것은 없습니다.

부트스트랩은 LESS 언어를 사용하여 생성되었으며 오픈 소스이므로 필요한 경우 수정할 수 있습니다. Bootstrap 사이트에 잘 설명되어 있는 수많은 UX 컨트롤과 함께 제공됩니다. 또한 자신만의 모델을 만들 수 있는 사용자 지정 모델이 있습니다. 그것은 확실히 일을위한 사람입니다.

모범 사례: Grunt.js, Mocha.js, Chai.js, RequireJS 및 CoverJS

마지막으로 몇 가지 모범 사례를 정의하고 Init이 이를 구현 및 유지 관리하는 데 어떻게 도움이 되는지 살펴봐야 합니다. 우리의 솔루션은 Node.js 자체를 기반으로 하는 여러 도구에 중점을 두고 있습니다.

• Mocha.js 및 Chai.js :

  이러한 도구를 사용하면 TDD 또는 BDD를 적용하여 개발 프로세스를 개선하고 단위 테스트를 구성하는 인프라와 자동으로 실행하는 러너를 제공할 수 있습니다.

  JavaScript에는 수천 개의 단위 테스트 프레임워크가 있습니다. 그렇다면 Mocha.js를 사용하는 이유는 무엇입니까? 짧은 대답: 유연하고 완벽합니다.

  긴 대답은 두 가지 중요한 기능(인터페이스, 기자)과 한 가지 중요한 부재(어설션)가 있습니다. 설명하겠습니다.

  • Interfaces : 아마도 당신은 스위트와 단위 테스트의 TDD 개념에 익숙하거나 “describe”와 “it should”와 함께 행동 명세의 BDD 아이디어를 선호할 것입니다. Mocha.js를 사용하면 두 가지 접근 방식을 모두 사용할 수 있습니다.

  • 리포터 : 테스트를 실행하면 결과 보고서가 생성되며 다양한 리포터를 사용하여 이러한 결과의 형식을 지정할 수 있습니다. 예를 들어, 지속적 통합 서버에 공급해야 하는 경우 이를 수행할 리포터를 찾을 수 있습니다.

  • 어설션 라이브러리의 부족 : 문제가 되지는 않지만 Mocha.js는 선택한 어설션 라이브러리를 사용할 수 있도록 설계되어 더 많은 유연성을 제공합니다. 많은 옵션이 있지만 여기에서 Chai.js가 작동합니다.

  Chai.js는 다음 세 가지 주요 주장 스타일 중 하나를 사용할 수 있는 유연한 주장 라이브러리입니다.

  • Assert : TDD 올드 스쿨의 고전적인 주장 스타일입니다. 예:

     assert.equal(variable, ”value”);

  • 예상 : 연결 가능한 주장 스타일로 BDD에서 가장 일반적으로 사용됩니다. 예:

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

  • Should : BDD에서도 사용되지만, Should는 행동 명세 'it("should do something..")'과 함께 반복적으로 들리기 때문에 Expect를 선호합니다. 예:

     variable.should.equal(“value”);

  Chai.js는 Mocha.js와 완벽하게 결합됩니다. 이 두 라이브러리만 사용하여 TDD, BDD 또는 상상할 수 있는 모든 스타일로 테스트를 작성할 수 있습니다.

• 그런트.js :

  Grunt.js를 사용하면 간단한 복사-붙여넣기 및 파일 연결에서 템플릿 사전 컴파일, 스타일 언어(즉, SASS 및 LESS) 컴파일, 단위 테스트(mocha.js 사용), 린팅 및 린팅에 이르기까지 빌드 작업을 자동화할 수 있습니다. 코드 축소(예: UglifyJS 또는 Closure Compiler 사용). Grunt에 자동화된 작업을 추가하거나 수백, 수백 개의 플러그인을 사용할 수 있는 Grunt 레지스트리를 검색할 수 있습니다(역시 훌륭한 커뮤니티가 있는 도구를 사용하면 효과가 나타납니다). Grunt는 또한 파일을 모니터링하고 파일이 수정될 때 작업을 트리거할 수 있습니다.

• RequireJS :

  RequireJS는 AMD로 모듈을 로드하는 또 다른 방법처럼 들릴 수 있지만, 그 이상임을 보장할 수 있습니다. 그 이유를 이해하려면 먼저 모듈 네임스페이스(예: demo.views.hello)에 대해 언급해야 합니다. 이 아이디어는 각 모듈을 자체 네임스페이스로 래핑하여 전역 네임스페이스를 오염시키는 것을 방지합니다. 문제는 이러한 모듈을 재사용할 수 없다는 것입니다. 한 '인스턴스'의 네임스페이스를 수정하면 모든 '인스턴스'의 네임스페이스를 수정하는 것입니다. 이와 대조적으로 RequireJS를 사용하면 처음부터 재사용 가능한 모듈을 정의할 수 있습니다. (또한 모듈이 전역 변수에 액세스하는 것을 방지하기 위해 종속성 주입을 수용하는 데 도움이 됩니다.)

• 커버JS :

  코드 커버리지는 테스트를 평가하기 위한 지표입니다. 이름에서 알 수 있듯이 현재 테스트 스위트에서 얼마나 많은 코드를 다루고 있는지 알려줍니다. CoverJS는 코드에서 명령문(JSCoverage와 같은 코드 줄 대신)을 계측하고 코드의 계측된 버전을 생성하여 테스트의 코드 적용 범위를 측정합니다. 또한 지속적 통합 서버에 공급할 보고서를 생성할 수도 있습니다.

분기를 사용하여 기능 전환

Init을 시작할 때 사용자가 프로젝트에서 원하는 다양한 기능을 활성화 및 비활성화할 수 있는 방법이 필요했습니다. 이 기능을 구현하기 위해 git의 분기 시스템에 급진적인 접근 방식을 취하기로 결정했습니다.

본질적으로 각 분기는 사용자가 포함할 수 있는 기능을 나타냅니다. 처음부터 프로젝트를 시작하는 경우 필요한 최소한의 분기에서 시작한 다음 원하는 분기와 병합하여 다른 기술을 추가하십시오. 예를 들어 Backbone.js 및 Marionette.js로 프로젝트를 시작한다고 가정해 보겠습니다. 글쎄, 당신은 Backbone.js 브랜치에서 시작해서 그것을 마리오네트 브랜치와 병합할 수 있고, 추가하고 싶은 모든 기능에 대해 계속할 수 있습니다.

현재로서는 기능을 추가하기 위해 병합하는 이 아이디어는 기술 템플릿(예: Backbone, Node, Express)에만 사용할 수 있습니다. 그러나 미래에는 백엔드(예: MongoDB에서 Postgres로)와 클라이언트 구현 간에 전환할 수 있습니다.

지금 Init로 프로젝트를 시작하고 Heroku에 배포하십시오.

프로젝트를 시작하는 이보다 더 쉬운 방법은 없었습니다. GitHub 리포지토리로 이동하여 최신 커밋이 있는 분기를 확인한 다음(지금은 usermanager이지만 나중에 변경될 수 있음) 다음을 수행합니다.

1. 프로젝트의 디렉터리를 생성합니다(또는 기존 디렉터리 사용).
2. "git init"를 사용하여 저장소를 만듭니다(또는 기존 저장소 사용).

3. init로 리모컨 추가

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

4. 원하는 지점 가져오기

    git pull init usermanager

5. Heroku 프로세스 파일 가져오기

    git pull init heroku-webprocess

6. Heroku Toolbelt가 설치된 상태에서 Heroku 앱을 만듭니다.

    heroku create

7. 마스터 브랜치를 Heroku로 푸시

    git push heroku master

8. Heroku에서 실행 중인 앱을 방문하세요!

이제 몇 줄의 코드로 킬러 기능 개발을 시작할 수 있습니다. 뿐만 아니라 최대한 자동화된 개발 제품군에서 가장 효율적인 최신 기술을 사용하여 개발하게 됩니다.

Init를 사용하여 다음 큰 아이디어를 시작할 수 있기를 바랍니다. 새로운 수정 사항과 기능에 대해 Init 저장소를 확인하는 것을 잊지 마십시오. 개발이 거의 진행 중이며 귀하의 피드백을 기다립니다.