github 블로그 만들고 꾸미기

8 분 소요

intro

  • 처음에는 그냥 github에서 기본적으로 제공하는 blog를 이용했습니다(repository setting에서 repository 이름을 frhyme.github.io로 바꾸고 theme을 골라주면 됩니다). 기본 theme에 midnight이 있는데 이것만으로도 충분히 이쁘긴 합니다. 그냥 single page로 보여주는데는 깔끔하고 좋아요.
    • 그냥 repository 에 index.md 파일을 만들면 index.md 파일을 jekyll이 html로 만들어서 url로 접속했을 때 보여줍니다.
  • 그런데, 공부하면서 다른 사람들 블로그를 들어가보니, 이런저런 기능들이 추가되어 있더라구요.
    • 예를 들어 disqus를 이용해서 코멘트를 달수 있도록 한다거나,
    • 날짜별로 세팅해서 “최근 포스트”만 보이게 하거나,
    • tag 등으로 정리해서 보여준다거나. 등등
  • 아무래도 시간이 지나서 콘텐츠가 더 많이 쌓이면 변경하는 것이 어려울 것 같아서 더 쌓이기 전에 좀 더 공부해보는 게 좋을 것 같다는 생각이 들었습니다.

theme을 어떻게 변경하나요?

  • 마음에 드는 theme의 git repository를 선정했으면, 그 git 으로 부터 fork 하여 개인 리퍼지토리로 가져옵니다(이 다음 branch를 해야 되더라구요. master에서 그대로 하면 안되는 것 같습니다 이유는 몰라여 헤헤)
  • 해당 repository의 이름을 ‘id.github.io’로 선정을 합니다
  • 그 다음 _posts에 마크다운 파일들을 올립니다. 그럼 끗.
    • _posts에 올라온 마크다운 파일들은 파일 내부 제일 위에 아래와 같은 “front matter”가 있어야 합니다. 없으면 인식을 못합니다.
    • 또한 yyyy-mm-dd-title.md 형식을 유지해서 넣어주셔야 합니다. 이렇게 넣어주지 않으면 인식을 못해요.
  • _config.yml 파일에서 설정을 바꿔줍니다.
    • title, description, google analytic, disqus 등등등

잠깐, yml이 뭔가요?

  • ‘YAML (YAML Ain’t Markup Language) is a human-readable data serialization language.’.
  • xml, json 과 유사한, 데이터 표현 형태라고 생각하면 된다. 다만 여기서 중요한 부분은 data serialization language라는 부분인데, 한국 말로는 데이터 직렬화라고 번역할 수 있다. 이 부분은 웹서핑을 하다가 적절한 설명 부분을 찾아서 제일 마지막에 첨부하였다.

front matter??

  • 음, 따로 찾아보지는 않았지만, 이건 해당 문서에 대한 정보를 전달하는, 일종의 header 개념으로 이해된다.
    • 레이아웃은 어떤걸 사용하는지 _layout에 일종의 템플릿 파일이 이미 존재해야 함.
    • 타이틀, 데이트, 카테고리, 태그들은 어떤 것이 들어가 있는지
    • 생각해보니까 네비게이션 바를 따로 만들어서 매번 업데이트하는 것보다는 front matter 형식으로 태그나 카테고리를 넘기는 형식이 훨씬 깔끔한 것 같다.
    • 특히, 카테고리와 태그는 아주 유용할 것 같음. 다만, 글이 아주 많아지면, 해당 태그별로 따로 볼 수 있는 방식으로 할 수도 있으려나?
---
layout: post
title: Blogging Like a Hacker
date: 2018-04-21
category: test
tags: test python etc
---

theme을 골라봅시다

  • github.io 는 보통 jekyll을 기반으로 만들어집니다. hexo 등도 있다고 하지만, 아직은 jekyll이 더 범용적이라서 좋은 것 같아요.

잠깐, jekyll이 뭔가요?

  • jekyll은 마크다운 파일을 소스로 하고 특정한 테마를 적용하여(아마도 css 느낌) 정적으로 웹사이트를 생성해주는 툴이다.
    • static: 사용자가 웹페이지에 접근할 때, 이미 만들어져있던 html 파일을 보여주는 것(속도는 빠를 수 있으나, 유저에게 한정적인 정보만을 제공할 수 있음)
    • dynamic: 사용자가 웹페이지에 접근할 때, 새롭게 html 파일을 만들어서 보여주는 것(따라서 사용자에게 적합하도록 페이지를 만들 수 있음, 속도는 저하됨)

jekyll theme을 골라봅시다

  • 이래저래 찾아보면, 결국 jekyll을 이용해서 페이지를 만든다는건 좋은 theme을 고르는 문제로 치환됩니다. 물론 조금 더 깔끔하게 만들기 위해서는 customizing이 필요합니다만. jekyllthemes 에 들어가면 다양한 jekyll 테마가 있습니다.
  • 물론 반드시 저 테마만 써야하는 것은 아닙니다. 저 테마는 일종의 템플릿이고, 사용자들이 템플릿으로부터 자신에게 맞도록 커스토마이징을 합니다. 지킬 테마와 지킬 테마를 이용해 만든 블로그를 모두 찾아보고 자신의 마음에 드는 블로그가 있다면 해당 블로그를 그대로 fork 해서 _posts/에 있는 포스트만 변경해도 되긴 합니다. 라이센스 문제를 꼭 확인하시구요.

  • 제가 원한 요구사항은 대략 다음과 같이 정리됩니다.
    • 눈이 피곤하니까 배경색이 어두운 색일 것
    • 글에 코멘트를 다는 기능이 추가될 것
    • 글을 tag나 카테고리 형태로 정리할 수 있을 것
  • 이것저것 찾아봤고 그 중에서 마음에 드는 테마는 대충 다음과 같았습니다.
    • jekyll-solana
    • materialbliss, 이거 약간 취향저격. 깔끔하고, 색감좋고, 개발자느낌
    • DevJournal, 코드를 아주 선명하게 보여주고, 깔끔함. 다만, 글을 카테고리로 나누어서 보여지게 할 수 있는지 잘 모르겠음.
    • long-haul, 이 테마가 좀 괜찮을것 같기도 한데, 백그라운드가 흰색인게 좀 아쉽다. 네비게이션 바 세팅이나, 비교적 수정하기 쉬운 편.
    • console, 이것도 깔끔하고 좋음. 다만 이는 유지보수가 어려운 편.
  • 다만, 위의 테마들이 처음 봤을 때는 혹하지만, github 리포지토리에 들어가보면 fork 수가 생각보다 굉장히 적은 것을 알 수 있습니다. 이는 해당 테마를 적용하는데 불편한 점들이 있다는 이야기죠. 예를 들어 도큐멘테이션이 부족하다거나 등등등. 그래서 그냥 가장 유명한 jekyll을 고르는게 제일 좋습니다.

  • 블로그에 비교적 자세하게 설명이 되어 있습니다. 특히, _config.yml 변경하는 부분에 대해서 자세하게 설명되어 있어서 해당 블로그를 추가했습니다. 테마는 이거에요.

just do it

  • 가급적이면 git 리퍼지토리를 본인 컴퓨터로 가져와서 작업한 다음 jekyll serve로 로컬에서 올리면서 작업하는 것이 좋습니다. 웹으로 확안히사면 아무래도 좀 느려요(작업 후에 반드시 git push)
    • port에 문제가 있을 경우 이 링크로
  • 다음을 수행해봅시다.
    • 과거 글들에 front matter 와 파일명 변경하여 _posts/ 에 업로드.
    • category, tag 또한 추가함.
    • _config.yml 파일 변경
      • author, blog data update 등등
    • 상위 메뉴 추가
      • “frhyme.github.io/_data/navigation.yml”를 보면 다음 내용들이 있다. 첫 페이지 상단에 걸릴 링크들을 말하고 있으며 원하는 링크들을 작성한 다음,
main:
    - title: "Archive"
    url: /archive/
    - title: "Tag"
    url: /tags/
    - title: "Category"
    url: /categories/
  • "frhyme.github.io/\_pages/"에 개별 파일들을 만들어준다. 여기서 front matter는 다음과 같은데, permalink는 일종의 절대경로다, 이것을 앞서 navigation.yml 에서의 url과 같이 세팅해줘야 한다. 이건 나도 헷갈려서 링크를 첨부합니다. 직접 다 하는 것보다는 남의 만든 page 파일을 가져오는게 낫습니다. 이미 잘 제공이 되기도 하고.
---
layout: archive
permalink: /tags/
title: "Posts by Tag"
author_profile: true
---
  • 색깔들 커스토마이징, 아래 파일에서 해당 요소의 특성들을 변경해주면 됩니다.
    • _sass/minimal-mistakes/_custom.scss
  • 이미지 업로드
    • 그냥 \_posts 내에 img 폴더를 만들고 접근하면 될것 같았는데 이게 생각대로 되지 않음.
    • 지킬(Jekyll) 포스팅에 이미지 첨부하는 방법 총체적 정리 이 자료를 보면 내용이 좀 더 있는데, 그냥 간단하게 “frhyme.github.io/asset/image/” 에 새로운 폴더를 만들고 모든 이미지를 업로드해둠
    • 마크다운 파일에서는 "asset/image/markdown_img/file_name.png" 로 경로 접근
  • 아무튼 이렇게 하면 대충 완료가 됩니다.

검색엔진에서 검색 가능하도록 변경

  • 보통 이를 search engine optimization이라고 한다. 구글은 구글에서 만든 봇이 링크되어 있는 사이트들을 돌아다니면서 사이트 주소를 가져오고 이를 구글 내부에서 일종의 맵 혹은 네트워크 형태로 만들어 관리하는 것으로 알고 있다. 흔히들 아는 page rank 알고리즘처럼 어떤 사이트가 중요한 사이트인가, 를 거대한 네트워크를 활용해서 처리하는 것.
  • 따라서 구글에서 검색이 가능하도록 하려면 이러한 봇들이 내 사이트 정보를 마음대로 가져갈 수 있도록 해줘야 한다. 이를 위해서 루트 디렉토리에 robots.txt를 만들고 여기에 일종의 지침을 업로드하는 것이 필요하다. 또한 폴더 내에 있는 sitemap.xml 도 업데이트하는 것이 필요하다. 물론, 하나하나 해줄 필요없이 어느 정도는 구글 애널리틱스와 연결되어 잇는 서치 콘솔과 연결하면 끝나기는 한다. 아래 내용을 참고 하였다.

세부적인 조정

  • 기본 테마를 그대로 사용하고 있지만, 미적인 것에 예민한 사람의 경우는(미적으로 예민하다고 했지 미적으로 센스가 있다고하지는 않았다ㅠㅠ) 글씨 크기나 색감을 바꾸고 싶은 생각을 하게 되는데, 이를 위해서는 _sass 폴더 내부에 있는 .sass를 변경해주는 것이 필요하다. 본인의 블로그 페이지 소스를 읽어서 특정한 소스의 값을 확인하고 이를 저 폴더 내부에서 찾아서 어디서 정의되어 있는지를 파악하고 변경하면 된다.
    • 물론 하나의 요소에 대해서 하나만 있는 것은 아닙니다. _base를 기본으로 하고, 이것저것이 서로 관계를 맺고 있는데, 이건 그냥 알아서 잘 하시는게 좋아요 하하핫.

새로운 테마를 만들자

  • 그런데, 특히 색감 측면에서 이를 하나하나 바꾸자면 너무 고통이고, 우리가 지금 다른 사람이 만든 스킨을 변경한 것처럼, 새로운 스킨을 내가 만들면 되지 않을까? 하는 생각이 들었다. 그래서 내가 좋아하는 _dark.scss 파일을 복사하고 다른 스킨에서 마음에 들었던 색감을 가져와서 조정하였다.
    • 해당 스킨 파일을 읽어보면 이 파일 내에서 색에 대한 변수를 선언할 수 있는 것을 알 수 있다. 여기서 색에 대한 변수를 선언하고, _config.yml 파일에서 스킨을 적용하면, 다른 파일들에서도 해당 색 변수를 사용할 수 있다.

차후 해야할 것들

  • jekyll 추가 공부: 현재 프레임웤에 대해 개념이 안 잡혀 있고 그냥 마구잡이로 되니까 쓴다에 가까움
  • tag 깔끔하게 정리
  • 본문에서 글의 폰트 사이즈가 다름
  • 좀 더 깔끔하게 보이려고 한 치수를 줄였는데, 맨 처음 부분만 줄여지고 이후는 원래 사이즈로 나옴. 변경 필요.
  • page css 부분에서 sectionpage_content인 부분내에 아래 부분을 삽입해줌
ul li {
  font-size: 0.9em;
}
  • 하이퍼링크 hover 시 색 변경되는 것, 하이퍼링크 색을 주황색으로 바꾸자.
  • 메뉴 부분에 문제가 있어서, 현재 tag, archieve, category 등이 표시되지 않음.

  • **중요한 것은 _custom.scss이며, 덮어씌운다고 생각하면 된다. css 파일들을 잘 모르면서 여기저기서 뜯어고치면 문제가 생기므로, 그냥 편하게 해당 파일에 모두 덮어씌운다고 생각하고 저기서만 정의를 해도 대부분 적용이 된다.

마무리

data serialization

  • 요약
    • 오브젝트는 보통 주소값으로 관리 및 저장되고, 오브젝트를 구성하는 primitive value 들만이 통신이 가능함. 따라서 통신을 위해서는 object를 primitive value들로 쪼개서 통시하는 것이 필요함.
    • 이 주소값의 실체를 다 끌어와서 Primitive 한 값 형식 데이터로 전부 변조하는 작업을 바로 직렬화(Serialization)라 합니다.
  • 아래 글은 모두 아래 링크에서 가져온 내용이다. link

  • Java 든 C# 이든 C++ 이던 간에 데이터의 메모리 구조는 크게 다음 2가지로 나뉩니다.
  • 값 형식 데이터: integer, float(single), charactor(또는 char 의 집합인 string) 등
  • 오브젝트(레퍼런스) 형식 데이터: 메모리 번지(주소, Address)값 –> 주소값을 최종적으로 따라가면 값 형식 데이터를 참조 하게 됨.
    • (C/C++) 또는 언어 차원에서 이 과정을 생략해줌
    • (C#, JAVA) –> 클래스의 인스턴스는 해당 프로세스의 메모리 상에서만 유효한 번지 주소를 갖는 오브젝트(레퍼런스) 데이터.
  • 이 중에 ‘저장/전송 가능한 데이터’ 는 당연하게도 값 형식 데이터만 전송 가능합니다. 오브젝트(레퍼런스) 형태의 참조 데이터(메모리 번지 주소 데이터)는 상식적으로도 파일 저장이나 네트워크 전송이 불가능합니다.
  • 일례로 32비트 시스템에서 Class A 의 인스턴스를 만들었고, 그 참조/주소값이 0x00121212 이었습니다. 그리고 이 참조/주소값 자체도 강제로 파일에 포함 시켜 저장하였습니다. 하지만 다음에 프로그램(서비스)를 다시 Start 시키고 이전에 저장했던 파일에서 0x00121212 참조/주소를 다시 읽어와도 클래스 A 의 인스턴스는 부활 할 수 없으며 이해할 수 도 없는 쓰레기 값일 뿐입니다. 네트워크 전송도 마찬가지로 받는 상대방 입장에서는 전달자가 사용한 참조/주소값 자체는 무의미 합니다. 서로 물리적으로 사용중인 메모리 공간(OS의 가상메모리 포함)은 일치하지 않기 때문입니다.

  • 비트와 바이트와 메모리, 언어 등의 관점에서 이야기를 해보니 이렇습니다. 조금 더 이해를 돕고자 JAVA 언어의 관점에서 설명해 보겠습니다.
  • 자바는 내부적으로 오브젝트(또는 Reference) 형식의 데이터를 많이 사용합니다. 그리고 오브젝트의 주소 메모리 번지 값 접근/편집을 일반적인 JAVA 코딩에 쓰지 않습니다(언어 차원에서 내부적으로 해결 해 줌)
  • JAVA 의 클래스 설계에는 오브젝트 안에 오브젝트가 또 들어있을 수 있습니다. (인스턴스 포함 관계) 그것은 오브젝트 안에 내부적으로 다른 오브젝트를 참조할 수 있는 주소값이 담긴 것을 의미합니다.
  • 이 주소값의 실체를 다 끌어와서 Primitive 한 값 형식 데이터로 전부 변조하는 작업을 바로 직렬화(Serialization)라 합니다.
    • XML, JSON 등의 데이터 구조를 떠올리면 이해가 빠를것입니다.
    • C/C++ 을 해보셨다면 좀 더 이해가 빠를 것입니다. (포인터 데이터를 모두 실제 값의 묶음 형식으로 전달, NPOD 데이터를 POD 데이터로 전달, 그리고 한방에 memcpy!)
  • 그리고 직렬화 된 데이터 형식은 언어에 따라 텍스트로 된 데이터 또는 바이너리 등의 모양을 띄게 됩니다. (어차피 텍스트든 바이너리든 결국 둘 다 Primitive 한 값들의 집합임)
  • 결국 직렬화가 된 데이터는 최종적으로 오브젝트 타입이 없습니다. 모든것이 Primitive 한 값 형식의 데이터 묶음이며, 이것은 파일 저장이나 네트워크 전송시 파싱 할 수 있는 유의미한 데이터가 되는 것입니다. (데이터 중복을 줄이기 위한 테이블화가 일어나는지는 확인 필요. 어차피 이 부분은 언어마다, 규약마다 다를 것)
  • 그리고 또하나 특징은 현존하는 컴퓨터 머신들의 메모리 설계상 큰 데이터 덩어리를 순차적으로 읽어 오는 것이 가장 빠르기 때문에 직렬화 된 데이터는 RDBMS 구조랑은 완전 다르게, 일직선의 연속적인 값들의 집합인 형태를 띄게 됩니다. (대게 그렇습니다. 이것도 언어/규약 마다 다를 수 있습니다)
  • 그래서 이렇게 전송/저장 가능한 데이터를 만드는 행위에 ‘직렬화(Serialization)’ 라는 이름이 붙게 되었습니다.
  • 정리하면 직렬화는 보통 파일 저장이나, 패킷 전송시에 ‘파싱할 수 있는 데이터를 만들기 위해’ 사용됩니다.
  • 로 프로세스 간에 데이터 전송에도 직렬화된 데이터가 사용 되는 이유는 대부분의 OS 가 현재 가상메모리를 운영 중이며 대부분의 OS 의 프로세스 구현은 서로 다른 가상메모리주소공간(Virtual Address Space, VAS) 를 갖기 때문에 역시 마찬가지로 오브젝트 타입의 참조값(결국 주소값)데이터 인스턴스를 직접 줄 수 없어서 직렬화된 데이터로의 교환을 주로 사용합니다.

댓글남기기