the Desirable Garfield

----------------------------------------------------------------------------------------------------------------

1. best-5 샘플 목록 :https://vuejsdevelopers.com/2018/04/23/vue-boilerplate-template-scaffold/

   1.1로그인화면 맘에든것:https://github.com/icebob/vue-express-mongo-boilerplate

2. top-10 샘플 목록 : https://vuejsexamples.com/tag/layout/

  2.1 비동기-그리드 샘플 : https://github.com/jbaysolutions/vue-grid-layout

3. vscode와 git 연동 유툽 : https://www.youtube.com/watch?v=kHM3xzkou_0

----------------------------------------------------------------------------------------------------------------

1번의 베스트 샘플 5개 중에, 로그인 샘플 화면과 로그인 이후 화면이 가장 맘에 들어서 이 부분에 대해 분석해보고, vue 프로젝트를 추후진행해보려고 한다.

* 아래 내용으로 IDE로 Import해서 확인한다.

1) 1.1 번의 코드를 전체다운로드 받는다. ( 해당 깃 링크의 download zip )

2) vscode 또는 visual stuidio community 버젼을 다운로드 받는다. ( 무료이므로 구글링해서 다운받으면 된다. )

   ( 내 경우에는 이전에 설치한 vs 2017 community 버젼이 있어서 15.8로 버젼업했다. )

3) 다운로드 받은 소스코드 zip파일을 압축해제한다.

4) vs를 실행시키고, 새프로젝트 생성하기를 하고, nodejs 기존 코드를 불러온다.

   - 기존코드 불러온 후, 실행파일은 ./server/dev로 지정해준다.

5) 압축해제한 폴더에서 'npm install' 실행해서 실행환경을 맞추어준다.

6) 'Hello world' 한다는 생각으로 run 또는 'npm run dev'를 실행한다.

7) 에러없이 되었다면, 'npm run build' 실행한다.

8) 에러없이 되었다면, 'npm start'를 실행한다.

*** 사실, 에러가 발생하는게 정상이다. 아래의 구경/분석하면서 에러 또는 설정값 잡는 법에 대해서 나열한다.

run dev는 현 개발모드 상태에서 실행하는 의미이고,

run build는 릴리즈 모드로 빌드(컴파일/난독화등)해서 릴리즈 가능한 형태로 만들어주고,

start를 통해 빌드된 상태로 실행한다.

이제 vue 프로젝트( mongo, ... 이것저것많음 )를 구경해보러 들어간다.

이 프로젝트는 몽고 디비를 쓰고 있고, open oauth 를 가져다 사용하고 있기 때문에, 

디비를 설치하지 않는다면, 가상db 또는 mockdata를 사용할 수 있게 해야 하는데 그게 더 귀찮아서 몽고/몽구즈를 설치한다.

oauth를 사용하지 않으려면 oauth 부분의 코드를 전부 주석처리하거나, 해당 oauth 루틴을 타지않게 호출부분을 바꿔주거나 주석처리해야한다.

http://developer.chrome.com/apps/app_codelab1_setup.html

그냥 git으로 기본 앱 받고나서

크롬에서 chrome://extensions/ 를 주소창에 입력하고.

개발자 모드 체크하고~ 확장 프로그램 로드해서 사용한다. 

끝~ ;; 허무~ ㅋㅋ

Git이라는거 좋네.

처음에는 '이게 왜필요하지'라는 생각으로 접근했다. 이 책을 읽어보니.. 왜 필요한 것인지 알았다.

Git, 분산 버젼 관리 시스템은 기존의 버젼 관리 시스템을 보완한거였다.

기존 버젼관리에서 중요부분을 수정하고나서 반영하려면, rock을 걸거나 공지한 후 모두가 커밋을 정지한상태에서 진행해야한다. 항상 모두가 동기화되어 진행하고 브랜치나 태그 따는데도 모두가 공유해야 한다. 안정적이든 불안정적이든간에.

물론, 지속적통합을 위해서 동기화되어 있는것이 맞다. 그러나 개발을 진행하다 보면, 약간의 비동기가 필요할때가 있다. 안정적 버젼을 제공해주기 위해 여러 브랜치테스팅이 필요한 경우도 있다. 이런 브랜치의 기능을 강화 시킨 솔루션이 '분산 버젼관리 시스템'이다. 

여기 분산버젼관리시스템의 핵심은 바로 '브랜치'다. 브랜치를 자유롭게 사용한다는 것이다. 때에 따라서 브랜치 정보를 수정할수도있고. 다른 부분에서 사용된 브랜치의 커밋정보도 끌어다 쓸 수가 있는 것이다. 이 부분은 기존 서버집중 버젼관리시스템에서는 약간 이해하기 어려운 부분이기도 했다. 독자도 이 부분의 개념을 이해하기 위해 3~4번 정도 번복해서 정독했었다.

Git의 기본은 로컬에서 Commit하여 로컬저장소에 보관하여, 안정적인 버젼을 서버로 Push하는 것이다.

여기에서 시작하여 각각의 버젼관리가 이루어진다. 태그는 수정불가는한 릴리즈 버젼을 지니고 있다.

태그를 수정하기 위해서는 새로운 브랜치를 생성하여 진행할 수 있다. 브랜치는 어느 버젼관리와 마찬가지로 여러갈래로 나뉘어지고, 다시 하나로 합쳐질 수 있다. 이 부분( 브랜치 및 합치기 ) 을 진행할 때, 로컬에서 자체적으로 수행하고, 공유가 필요한 부분만 서버에 전송( Push ) 한다.

이 책 부록에, 유용한 명령어 모음집이 맨 마지막에 붙어 있다. 어쩌면 설명없는 명령여 요약본으로 볼 수 있다.

독자도 나중에 필요할 것을 대비하여, 휴대가 편하도록 복사해 두었다.