2017년 12월 5일 화요일

Markdown과 Stackedit

차례


시작하며….

Markdown으로 글을 정리 하는건 다른 문서 편집 문법에 비해 편하다는 것을 앞선에서 이야기 드렸습니다.

그럼 이걸 어떻게 써야 할까요????

이걸 이용해서 Blogger에는 어떻게 올려야 할까요???

그 방법에 대해서 이야기 하도록 하겠습니다.

Stackedit

기본적으로 Blogger에서는 Markdown을 지원 하지 않습니다.

그러니까… 열심히 Markdown으로 입력을 했지만 Blogger에서는 형태를 잡을 때 다시 해야 한다는 거죠.;;;

제가 처음으로 Markdown을 사용해야 하고 싶다고 마음 먹었을 때 가장 먼저 한거는 Markdown을 Blogger에 적용하는 방법을 찾는 것이었어요.

이곳 저곳 돌다가 가장 효과적이고 사용이 편리한 것은 Stackedit 였습니다.

https://stackedit.io/

Viewer로써와 Blogger에 적용하는 방법 모두 최강입니다.

어떤 점이 최강인지 하나씩 볼게요.

도움말

https://stackedit.io/editor# 에 접속을 하게 되면 가장 처음에는 접속 하는 것이라면 “Hello!”라는 타이틀과 함께 사용자를 반겨 주지요.

아래의 그림이 일부의 모습입니다.

이 Hello의 글만 읽더 라도 Markdown을 사용하는 법에 대해 아주 간단하게 알 수 있게 되지요.^^

어제 제가 열심히 적은 내용들이 사실은 모두 필요 없었어요..;;;;

그래도 저를 위한 자료라고 생각해야죠.ㅎ

실시간 변환

위의 그림에서 보던 거 처럼 중간을 중심으로 왼쪽은 편집기이고 오른쪽은 뷰어예요.

사용할 텍스트 편집기가 없을 때는 직접 적으면 원하는 형태가 나오는지 확인을 할 수 있어요.

Import from disk

아시는 분은 아시겠지만 저는 편집기 중에 Vim을 선호합니다.

Vim으로 작성을 한 후에 내용을 복사하고 Stackedit에도 붙여넣기로 글을 전달할 수 있지요.

그런데 파일을 직접 Import를 한다면 현재 작성하는 파일이 아니라 예전에 작성했던 파일들도 쉽게 확인 할 수 있겠죠??

우측의 #을 클릭하면 Import from disk 버튼이 있어요.

아래 그림 처럼요~

클릭 후 원하는 파일을 선택 하거나 Drag를 해 주면 원본은 좌측에, 우측에는 Viewer 형태로 바로 나오게 되죠.

아직까지는 파일에 대한 Refresh가 되는건 아닌거 같아요.

뭐.. 나중에는 되지 않을까요??

그럼 Vim으로 바로 수정 한 후에 Stackedit로 Refresh를 하여 바로 확인이 가능 해질거 같아요.

쉬운 Publish

이 부분이 가장 마음에 드는 것 중에 하나였어요.

Blogger를 하려면 기본 적으로 Blogger에 가서 “글쓰기”를 눌러서 원하는 글을 적고 저장을 하게 되죠.

그런데 Stackedit의 좌측 상단의 # 표시를 누르고 Publish까지 눌러 보세요.

클릭을 하면 Blogger와 업로드 할 수 있는 Web 사이트들이 나와요.

Blogger를 클릭 하시면 입력이 필요한 화면이 나오죠.

원하는 URL이나 수정을 원하실 때는 PostID까지 입력을 하시고 OK를 누르시면 바로 업로드 혹은 업데이트가 되요.

그리고 원하는 Web 사이트에 동일한 내용으로 올릴 수도 있지요~

이거 대박 아닌가요?????

어디에서도 동일한 형태로 올려 주니까요!!!! ^^

하지만… 혹시 아세요??

단순하게 글만 올리면 Blogger에서의 라벨은 어떻게 올려야 할까요????????

매번 업로드를 하고 라벨은 수정을 해야 하는건가요??

만약에 그래야 했다면.. 저는 금방 포기 하고 말았을거예요.ㅠ

Stackedit는 그렇게 하지 않아도 되는 거겠죠?? ㅋㅋ

마치며….

오늘 다 적으려고 했는데….

생각보다 많이 길어 졌네요.

제가 늦게 퇴근해서 글 적는 시간이 적었어요.;;

Blogger에 올릴 때 타이틀과 라벨 부분은 내일 다시 완료 하도록 하겠습니다.

감사합니다.

2017년 12월 4일 월요일

Markdown의 기본

차례


시작하며….

한동안 정리를 하면서 단순 Text로 글을 정리 한다는게 매우 불편하다는 생각을 했어요.

나중에 다른 곳에 글을 올린다고 할 때 원본글은 있지만 글자의 크기나 이미지의 링크 등을 일단 txt로는 관리 하기 너무 어렵더라고요.

그러니 만약에 다른 곳에 글을 옮긴다고 하면 또 다시 해당 사이트에 맞게 구조의 편집을 다시 해야 하더라고요.

그런 생각을 하니 갑자기 귀찮다는 생각이 들더군요.

그래서 이것 저것 찾다가 괜찮은 택스트 편집 문법인 Markdown을 찾게 되었네요.

이 편집 문법이 Html 처럼 복잡 하지 않고 제가 사용할 정도까지는 딱!! 적당했어요.

Markdown의 장점

이제 Markdown을 사용한지는 별로 되지 않았지만 그래도 제가 생각하는 장점은 다음과 같아요.

  1. 짧은 명령어
  2. 많은 Viewer
  3. Github 연동

1. 짧은 명령어

우선 기본 문법이 많지 않고 사용하는 방법이 굉장히 쉬워요.

  • Test1
  • Test2
  • Test3

예를 들어 위 처럼 html에서는 list를 주려고 하더라도.

<li> Test1
<li> Test2
<li> Test3

으로 <li>을 반복적으로 적어줘야 하지만.. Markdown은 아래처럼만 적으면 되요.

* Test1
* Test2
* Test3

3글자를 더 입력하지 않는다는게 얼마나 편한 건지 모르겠어요.^^

2. 많은 Viewer

Markdown이라는거 자체가 단순 문서 편집 문법을 가져서 그런지 생각보다 Viewer가 많더라고요.

Chrome 같은 곳에서 확장 기능도 있고요.

그리고…

저는 그냥 Vim으로 보는 것도 나쁘지 않은거 같아요.^^

Markdown Syntax in Vim

위의 이미지는 지금 작성하는 글의 Syntax가 포함된 화면이예요.

편집기는 Vim이고요.

Syntax를 이용하여 Markdown의 문서를 조금은 이쁘게 볼 수 있어서 단순 Text 보다 좋은거 같더라고요.

3. Github 연동

사실 Markdown이라는 용어를 알게 된것도 Github를 하면서 였어요.

하던 일만 하니(저는 임베디드쪽에서 일을 하고 있어요~) 웹쪽이나 어플 쪽은 까막눈이죠.ㅎㅎ

그러다가 Github에 README.md를 작성해야 한다는데 “이게 뭔가요..” 했지요.;;

처음에는 무관심하게 지나쳤는데 최근에 블로그를 하면서 찾다 보니 이게 저한테 맞는다는 생각을 했어요.

그리고 Git도 같이 사용하려고 했는데 Markdown이 Github는 기본 제공이 되더라고요!!

즉, 제가 모든 문서를 Markdown으로 작성을 한다면 특별한 Viewer 없이도 양식대로 볼 수 있는거더라고요.

지금 하고자 하는 것들이 모두 맞아 떨어 지게 된거죠.^^


위의 장점들은 저의 개인적인 장점들이니 다른 분들은 다른 장점 혹은 단점을 가지고 계실수도 있어요~

Markdown의 문법

기본 문법

사실 지금도 고민이예요.

너무나 많은 곳에서 Markdown 문법을 알려주고 있는데..

나도 여기에 적어야 하나…

아니면 링크만 열결을 해야 하나..^^;;

일단 가장 기본적인 Markdown의 문법은 아래 사이트에서 확인을 하시면 될거 같아요~

마크다운의 사용법과 정보

그외 문법

위에 없는 문법 중에 자주 쓸거 처럼 보이는거 몇개만 더 알려 드리면 다음과 같아요.

Code 부분

    ```javascript
        userCustom.onReady = function() {
            /* PlantUML Prepare */
            previewContentsElt = document.getElementById('preview-contents');
            $.getScript('//cdn.rawgit.com/dankogai/js-deflate/master/rawdeflate.js', makeUml);
        };
    ```

위 처럼 입력을 하고 Viewer로 보면 아래 처럼 나와요.

    userCustom.onReady = function() {
        /* PlantUML Prepare */
        previewContentsElt = document.getElementById('preview-contents');
        $.getScript('//cdn.rawgit.com/dankogai/js-deflate/master/rawdeflate.js', makeUml);
    };

신기하지 않나요?? ^^

Table

  |       | 철수   | 영희   |
   ----- | ------ | ------ 
  | 국어  | 100    | 80     |
  | 영어  | 90     | 90     |
  | 수학  | 80     | 70     |

Table도 그릴 수 있어요.

위처럼 작성을 하게 되면 아래 처럼 그림을 그려주죠.

철수 영희
국어 100 80
영어 90 90
수학 80 70

저는 이런게 왜이렇게 신기하고 좋은지 모르겠네요.ㅎㅎ

아.. 그리고 위의 테이블은 Viewer 마다 조금씩 문법이 다를 수 있어요~

마치며….

오늘은 Markdown에 대해 이야기 해 보았어요.

아직 편한건 잘 모르겠지요?? ^^;;;

하지만 슬슬 왜 제가 이걸 사용하게 되었는지 또 설명을 드릴게요.

오늘도 감사합니다.

2017년 12월 3일 일요일

Git의 기본

차례


시작하며….

지금까지 사용했던 형상 관리 툴을 보면 ClearCase, Perforce, SVN 정도가 될 거 같아요.

Git은 회사에서 사용하지 않다 보니까 잘 사용하지 않게 되더라고요.

그런데 이번에 Vim과 Plantuml등을 정리하면서 정리 내용을 Blog에 올리고는 있지만 이 글들을 좀 더 버전 관리라는 것을 하고 싶었죠.

그러다가 겸사겸사 Git으로 버전 관리를 하자라는 결정을 내리고 배우기 시작 했지요.

그렇게 Git을 알아 가니 이게 재미있더라고요.

기존 형상 관리 툴과는 다른 점도 나름 끌리기도 하고요.^^

그렇게 알게 된 점들을 여기에 정리하려고 합니다.

하나라도 끝내면서 다음을 진행해야 하는데…

하고 싶은 것만 많은 건 아닌지…

그리고 Git은 금방 끝내겠습니다!!!!
(제가 아는게 전문가 수준은 아니예요.^^;;;)

Git과 다른 툴과의 용어 차이들

처음 Git을 보면서 가장 어려웠던 점은 용어 였어요.

다른 형상관리 툴에서 사용하던 명령어나 용어들과 다른 점이 많았지요.

아마 처음에 add 라는 명령어 때문에 고민에 빠졌던 거 같아요.

add더하기 잖아요???

그래서 처음에 저 명령어를 보았을 때 신규 파일을 추가 하는 거라고 생각했어요.

근데 아니더라고요….;;;

이건 금방 아래에 설명을 드릴게요.

checkout 도 뭐지라는 생각을 들게 했죠.

checkincheckout은 다른 툴에서는 수정을 하고 수정을 완료 됨을 나타내곤 했지요.

그런데 Git에서는 Branch를 변경하는 거였어요.

저런 용어 정리 때문에 처음에 “Git은 어려운거!!!” 라는 편견을 가지고 있었죠.

그러다가 이제 필요하기 시작하니 기초부터 차근차근 다시 배우기 시작한 거죠.

기초 부터 다시 하니 Git에 대한 편견도 많이 사라지고 오히려 Git이 멋져 보이더라고요.

지금 이 글도 Git에 올리면서 쓰고 있을 정도니까요..^^

그럼 Git이 무엇일까요????

Local?? Remote?? Repository??

용어 정리가 필요하겠죠??

우선 저의 정의나 설명이 정확하지 않을 수 있다는 것을 말씀드립니다.;; ㅎㅎ

필요한 것만 배운 상태라 기본 원리와는 많이 다를 수 있어요.^^;;


Git은 위의 그림처럼 크게 두 가지로 나눌 수 있는 거 같아요.

제가 보았을 때의 구분법은 다음과 같죠.

  • Local : 개인이 작업 하는 공간
  • Remote : Backup을 위해 자료가 저장되는 공간


각각을 설명 드리기 전에 바로 Local에 있는 내용도 설명해 드릴게요.


위 처럼 Local과 Remote의 역할을 정의 하다 보니 처음에는 Remote의 이해 되지 않았어요.

타 버전관리 툴을 보게 되면 보통 서버들이 버전들에 대한 정보를 모두 가지고 있어요.

버전에 대한 소스 파일들이나 다른 메타데이터들을요.

그런데 Git에서는 Remote라는 건 단순 백업 서버라고 하니 이때부터 맨붕에 빠져 있게 되었죠.

그럼 그런 버전 정보들은 어디에 보관되어 있을까요?

답을 바로 이야기 드리면 Local 영역의 Repository에 저장된 거죠.

그러니 History나 버전별 소스들이나 모두 Local에 있다는 거죠.

즉… 네트워크로 연결할 수 없는 비행기 안이나 산골 지방에서도 Git으로 버전 관리를 할 수 있는 거죠.

이건 정말 큰 장점 중에 하나 아닐까요????

git의 기본 명령어

상태에 대해 간단히 보았으니 기본적인 명령어를 적어 보도록 하겠습니다.


위와 같이 Local에서의 상태의 이동 명령어를 간략하게 적어 보았습니다.

하나씩 설명을 해 드릴게요.

1. git init

우선 git은 모두 설치되어 있고 터미널에서 사용할 수 있다고 가정하고 진행하겠습니다.

만약에 Git으로 프로젝트를 관리 하고 싶다면 우선 해당 프로젝트의 디렉토리로 이동을 해요.

cd $ProjectDirectory
git init

그리고 init 명령어로 해당 디렉토리는 Git이 관리 한다고 생각하면 돼요.

2. 파일 추가와 상태 확인(git status)

파일을 하나 추가해 보죠.

echo TEST > A.txt

그럼 A.txt가 Working Directory라는 영역에 있는 거라고 생각하면 돼요.

지금 파일을 생성했는데 현재 상태가 궁금하겠죠?

그럼 상태를 한번 볼게요.

git status라는 명령어를 입력하면 되요.

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    A.txt

nothing added to commit but untracked files present (use "git add" to track)

위처럼 나오지요?

간단한 영어니까 읽어 보면…

Untracked files가 있는데 그 파일 이름이 A.txt 라네요.

지금 저 파일이 Working Directory 상태라고 생각하면 돼요.

3. git add A.txt

Working Directory 상태에서는 말 그대로 작업을 하는 상태예요.

지금 이 상태를 이제 거의 완료 했다고 가정한다면 이제 버전 관리를 해야겠지요???

그럼 Repository 쪽으로 이동해야 하는데 중간 단계인 Staging Area로 먼저 이동을 해 두어야 해요.

git add 파일명

위 명령어를 적게 되면 Staging Area로 이동하게 돼요.

다시 상태를 볼까요???

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached ..." to unstage)

    new file:   A.txt

변경 사항이 있는데 그건 앞으로 commit을 해야 할 거라네요.

그 파일은 A.txt라고 적혀 있고요.

이제 남은 건 Commit 하는 것만 남았네요.^^

4. git commit -m ‘메시지’

모든 수정이 완료된 상태이니 이제 Repository로 이동시키고 버전 관리를 할 수 있도록 하면 되겠지요?

git commit

위 명령어를 치면 Staging Area에 있는 모든 파일이 Repository로 이동하게 되는데…

메시지를 입력하기 위해 Vim이 자동으로 실행 돼요.

메시지를 입력하고 Vim을 종료하면 되는데 귀찮을 수 있으니 옵션인 -m을 입력 하면 Vim 실행 없이 바로 메시지가 입력 돼요.

git commit -m '메시지'

위와 같이 입력 하면 되지요.

5. 상태 확인

Working Directory에도 없고 현재 버전 관리가 어떻게 되고 있는지 확인을 해 봐요.

status는 간단하죠??

$ git status
On branch master
nothing to commit, working tree clean

위 처럼 이제는 Commit 할 것도 없고 Working Tree도 깨끗하다고 하네요.

Working Tree는 Working Directory를 이야기 하는 거예요.

그럼 버전 관리의 확인은 어떻게 될까요??

log라는 명령어를 입력하면 돼요.

$ git log
commit d03e82eadca57c205366eee6375a4c19e0e297a7 (HEAD -> master)
Author: 사용자이름 <사용자이메일주소>
Date:   Commit한 시간

    Add A.txt

위처럼 나올 거예요.

그러니까 Author의 정보를 가진 사람이 Date 시간에 무슨 일을 했는데…

그때 입력한 메시지는 “Add A.txt”네요.

마치며….

가장 기본적인 Git에 대해 나열했네요.

  • git init
  • git status
  • git add 파일명
  • git commit -m ‘메시지’
  • git log


하지만 저 명령어 들만이라도 익숙해진다면 어디를 가더라도 Git을 할 수 있다고 해도 될 거 같습니다.

확장 기능들이 더 많지만 가장 기본부터 차근차근 하자고요.^^