intro
둥지를 바꾸는 것은 참 힘든 일이다.
가장 열심히 블로깅을 할 때는 구글의 텍스트 큐브가 있었던 시절이었다.
일상의 모든것을 기록하고 openId도 한창 유행할때라rkaehdaos.textcube.com
으로 나를 표현하곤 했었다.
구글에서 텍스트큐브 설치를 멈추고 나서 사실 많은 방황을 했다.
(구글에서 제공하던 텍스트큐브와 rss리더인 구글리더
모두 나에게 정말 유용햇었는데)
개인적으로 설치형이 사실 제일 좋긴한데..
워드프레스를 개인서버와 nas서버에서 유지할 때가 있었는데
가장 큰 문제가 있었다.
바로 내가 걸핏하면 고스트로 밀고 포맷하는 버릇이 있다는 것이다.
백업도 안하고 몇번 날려먹기를 반복한 후 포기했다.
네이버 블로그는 한창 운동할때 2004~6년때
열심히 운동정보를 올릴때 사람들이 꽤 모여들었었는데
역시 포기했다.
일단 너무 자유롭지 못했다. 외부 링크도 안좋았고(지금보다 더)
그래서 바꾼것이 티스토리.
컴퓨터 오버클럭에 한창 빠져있을떄 이것저것 정리하곤 했는데.
역시 이것도 포기하게 된것이… 개발자에게 좋은 블로그가 아닌 것이다.
마크다운과 코드정리가 쉬어야하는데..
바로 직전까지 사용하던것이 GitBook.Gitbook_Editor
라는 클라이언트 프로그램이 존재하긴 하는데
이미지를 하나라도 넣었을 경우 커서를 움직이는 동안
중간저장 및 리프레시 될때 첫이미지로 커서가 이동하는 증상이 있는데
이게 정말 사람을 미치고 팔짝 뛰게 만든다. 사실상 자기가 편한 에디터로
마크다운 파일을 작성하는 것이 정신건강에 좋다.
GitBook에 처음에 관심이 있었던 것은 epub 출판 때문이었다.
e-ink단말기를 즐겨 사용하는 나에게 있어서 GitBook은 최상의 파트너였다.
일단 GitBook의 베이스가 git저장소이기에 관리가 완벽하다.
또한 마크다운을 완전히 사용할 수 있어서 있는 장점이 있다.
SSG가 마크다운 파일을 html으로 빌드를 한다면
GitBook은 마크다운 파일을 epub,mobi, pdf등의 출판물로
빌드를 한다고 볼 수 있다.
개발 글과 정보가 하나의 묶음이 될때 e북파일로 출판. 공유하여
동료들과 후배들에게 전달하기에도 좋았다.
GitBook은 말그대로 원래 목적이 문서빌드가 타겟이기에
정보 정리 및 공유의 목적으론 개인적인 레벨에서는 완벽하며
사실상 본인 지식정리와 다이어리등 정보 저장및 응용의 측면에서만
바라봤을때 이곳이 최고 가 아닐까 싶다.
문제는 내가 바라는게 더 있었다는 것이다.
이부분은 사실 엄청 길게 말하고 싶은데 요약하면
“소통”과 “커스터마이징”이 필요했던 것..
그래서 SSG 블로그쪽을 생각하게 되었다.
어차피 SSG도 마크다운이니까 SSG로 쭉 쓰다가 만약 퍼블리싱이 필요하면
마크다운 다 모아서 GitBook에 넣어서 문서 빌드하는게 제일 나을 듯 싶다.
요새 개발자들은 보통 깃허브페이지에 지킬(Jekyll)등의 정적 사이트 생성기를
이용하여 관리를 하고 있었다. 찾아보다가 hexo를 발견하게 되었다.
보니 사실 낯설기도 하고 불편할 것 같지만 마크다운 공부도 할 겸 트라이를 하게 되서
결국 성공은 하였다. (그러니 이렇게 여러분이 글을 보고 있겠지)
그런데..이거 모바일에서 어떻게 써야할지 애매하다.
모바일에서 어떻게 글을 쓰지?
내가 아직 잘 모르는 부분이 있을지도.
설치
설치 환경은 일단 nodejs와 Git이 필요하다.
나의 경우엔 위에서 말했다시피 멀 깔리는 것을 지독히 싫어해서
도커를 알게 된 이후로는 무조건 도커를 이용한다.
따라서 이미 사용하는 시스템에서 우분투 도커 컨테이너를 추가했다.
그냥 apt-get에서 설치하여도 되는데 우분투에서 최신 버전을 깔기 위해선 curl을 위한 저장소가 필요하다 (즉 docker pull ubuntu 한 경우엔 curl도 설치가 필요하다)
1 | curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - |
docker ubuntu에서 이미 root 유저를 사용하는 경우엔 sudo -E를 빼고 쓴다.
node.js와 git 설치가 끝나면 npm을 사용해서 설치할 수 있다.
1 | npm install -g hexo-cli |
설치가 참 간편하다
초기화 및 시작
블로그 파일을 저장할 폴더를 만든다.
1 | hexo init blog |
이렇게 하면 maven이나 gradle init한 것처럼 초기화 및 초기 폴더구조가 생성된다.
잘되었는지 확인해보자. hexo는 빌드하기전에 간단히 로컬서버를 띄워서 확인이 가능하다.
1 | hexo server |
메세지를 보면 localhost:4000에 접속하라고 한다. 확인해보면 hello라는 샘플 포스트가
떠있음을 알 수 있다. (docker컨테이너 작업시엔 당연히 4000포트 매핑빼줘야지)
글쓰기
새글을 쓰기 위해선 post를 작성해야한다.(이건 나중에 다시 정리)
1 | hexo new post '[post name]' |
그러면 블로그폴더(현재 blog) 밑의source/_post
밑에새로운 포스트 마크다운 파일이 생성되었다고 나온다.
이를 수정하면 포스트 내용을 추가 수정할 수 있다.
추가 수정후 위에서 했덧것 처럼 ‘hexo sever’로 확인해보는 게 좋다.
빌드
hexo는 말그대로 정적사이트 생성기이다. 즉 빌드가 필요하다.
빌드를 하면 현재 마크다운 파일 내용과 사용자가 세팅한 css 및 템플릿을 가지고
html파일등을 생성하는 빌드작업을 한다.
1 | hexo generate // 약자를 사용해서 hexo g 로 해도 동일하다. |
이렇게 하면 public이라는 빌드 폴더가 만들어지며 여기에 빌드된 html등의 파일들이
들어 있게 된다.
배포하기
위에서 만든 public 폴더만 웹서버에서 보면 블로그 형태의 완전한 html을
볼 수 있다. 웹서버가 아닌 깃허브페이지나 heroku, aws등에도 배포가 가능하나 깃허브 페이지가 가장 손쉽다.
_config.yaml
이라는 설정 파일이 있다. 여기에서 제목이나 url등을 지정할 수 있는데 git으로 배포하기 위해서는 deploy부분을 설정 해주어야한다.
1 | hexo deploy //hexo d도 동작이 같다. |
나의 경우엔 deployer not found: git이라는 에러가 났었는데 이것은
hexo-deployer-git이 필요해서 그러하다.
1 | npm install hexo-deployer-git --save |
윈도우에서 테스트 할때
내 bazel빌드의 git과 충돌이 나서 먹통이 되는 일도 발생했었다.
(그러니 뭔가를 할때는 docker로 다 독립적으로 해놔야한다. 그래야 맘이 편하다.)