0. 시작하며

 

VIM은 역사와 전통의 훌륭한 도구다.

지금 VIM을 쓰는 사람들은 앞으로도 계속 VIM을 사용할 것이다. 1970년대 이후 많은 사람들이 그래온 것처럼.

* VI (브이아이, 1976~)와 VIM (빔, 1991~)은 사실상 같은 도구다. 굳이 구별할 필요 없다.

 

VIM은 어디서나 쓸 수 있다.

VIM이 없는 OS는 없다. 만약 VIM조차 없는 환경이라면 다른 어떤 도구도 사용할 수 없을 것이다. 그만큼 VIM은 요구사항이 낮다 (콘솔 입출력만 가능하면 된다). 최악의 환경에서도 VIM은 실행된다.

 

그리고 VIM은 익숙해지면 편하다.

이건 양날의 검인데, 최소한의 학습 장벽을 넘지 않으면 전혀 쓸 수 없다. VIM을 켜고 끄지 못해 당황했던 기억이 누구에게나 있을 것이다. VIM은 마우스가 없던 시절에 만들어진 도구다. 그리고 두손의 움직임을 최소화하는 것이 VIM의 철학이다. 그래서 일단 학습 장벽을 넘어 사용법이 손에 익숙해지면 다른 어떤 도구보다 적은 동작으로 많은 것을 할 수 있다 (다른 어떤 도구보다 생산성이 높다).

 

VIM 최초의 학습 장벽은 이 글로 넘자. 좋은 글을 멋지게 번역했다.

[번역] Vim 정복하기: 4주 계획

원글은 How To Learn Vim: A Four Week Plan

윗 글을 읽고, 일주일만 꾸준히 vimtutor를 수련해서, VIM에서

1) h,j,k,l 키 만으로 이동할 줄 알고,

2) 원하는 문자열을 찾고 바꿀 줄 안다면

최초의 문턱을 아주 훌륭하게 넘은 셈이다. 이 정도만 알아도 VIM의 생산성을 체감할 것이다.

 

이 글은

1) VIM에서 윈도를 분할하고 쓰는 법,

2) VIM에서 비주얼블록을 선택하고 쓰는 법,

3) VIM 플러그인을 검색하고 쓰는 법을 소개하려고 한다.

 

1. VIM 윈도

 

VIM은 가로/세로로 윈도를 나누어 쓸 수 있다. CTRL-w 가 윈도 기능을 부르는 핵심 키다.

* 윈도 세로 분할 - CTRL-w, v

* 윈도 가로 분할 - CTRL-w, s

* 윈도 이동 (다음 윈도로) - CTRL-w, w

* 윈도 이동 (h,j,k,l 방향으로) - CTRL-w, 방향키 [h | j | k | l]

* 윈도 닫기 - (명령줄에서) :q

 

VIM 윈도 기능 예시를 동영상으로 한땀한땀 캡쳐했다. 시나리오는 다음과 같다.

VIM 열기 -> CTRL-w, v 키입력으로 윈도 세로 나누기

-> :e FILENAME 명령으로 나뉘어진 윈도에서 새 파일 열기

-> CTRL-w, s 키입력으로 윈도 가로 나누기

-> :e FILENAME 명령으로 나뉘어진 윈도에서 새 파일 열기

-> CTRL-w, w 키입력으로 윈도 이동하기 (6번 반복)

-> CTRL-w, l 키입력으로 오른쪽 윈도로 이동하기

-> CTRL-w, h 키입력으로 왼쪽 윈도로 이동하기

-> CTRL-w, j 키입력으로 아래쪽 윈도로 이동하기

-> CTRL-w, k 윈도로 위쪽 윈도로 이동하기

-> :q 명령으로 윈도 닫기 (모든 윈도를 닫을 때까지 반복)

 

2. 비주얼 블록

 

비주얼 블록은 간단하지만 무척 유용한 기능이다. V (대문자 v) 가 Visual Block을 부르는 핵심키다.

* 라인 단위 블록 선택 - V (대문자 v) + 방향키 [j | k]

* 블록 해제 - ESC

 

블록을 선택한 상태에서 해당 블록만을 대상으로 문자열을 검색/치환할 수 있다.

예를 들어 (블록 밖에 있는 "abc"는 그대로 두고) 블록 안에 있는 "abc"를 "def"로 검색/치환하려면 블록을 선택한 상태에서 다음과 같이 입력한다.

(명령줄에서) :s/abc/def/g

 

블록을 선택한 상태에서 해당 블록을 대상으로 일괄 작업을 실행할 수 있다.

예를 들어 해당 블록 앞에 "//" 문자열을 삽입해서 블록을 c/c++ 주석문으로 변환하려면 다음과 같이 입력한다.

(명령줄에서) :norm i//

 

그러면 norm 뒤에 나열된 키 입력이 블록 안의 각 라인에 일괄 적용 된다. 이렇게 변환된 주석문을 다시 일반문으로 변환하려면 (각 라인 첫머리의 "//" 문자열을 제거하려면, 다시 블록을 정의하고 다음과 같이 입력한다.

(명령줄에서) :norm xx

 

역시나 비주얼 블록 기능 예시를 한땀한땀 캡쳐했다. 시나리오는 다음과 같다.

VIM 열기 -> 비주얼 블록 선택/해제하기 (3회 반복)

-> :s/a/b/g 명령으로 문자열 바꾸기

-> norm i// 명령으로 라인 첫머리에 "// " 문자열 넣기

-> u 키입력으로 작업취소하기 (2회 반복)

-> :q 명령으로 VIM 닫기

 

3. VIM 플러그인

 

새로운 개발 머신을 갖게 되면 자기만의 VIM 사용 환경을 새로 설정해야 한다. 이때 사용하는 것이 ~/.vimrc 설정 파일이다. 필자의 ~/.vimrc 파일을 샘플로 링크에 걸어 둔다. 참조가 되면 좋겠다. 여기서 특기할만한 것은 VIM 플러그인 매니저 Vundle 이다. Vundle  이외에 다른 플러그인 매니저들도 많다. 어떤 것을 쓸지는 취향의 문제다. 필자는 처음 만난 플러그인 매니저가 Vundle이어서 Vundle을 쓴다.

 

VimAwesome (https://vimawesome.com/)이라는 훌륭한 VIM 플러그인 검색 사이트가 있다. 이 사이트를 이용하면 원하는 VIM 플러그인을 찾을 수 있고 해당 플러그인의 설치/설정/사용 방법을 알 수 있다. VimAwesome 사이트는 (Vundle 포함) 모든 VIM 플러그인 매니저들을 위한 알맞은 설정 방법을 안내해준다.

 

VIM 만세!

 

Posted by ingeeC
,

VIM의 Netrw 디렉토리 화면에서 PWD 설정 키 변경 (c --> cd)

 

VIM 버전을 올렸더니 (version 8.2), netrw 디렉토리 화면에서 현재 디렉토리를 지정하는 명령이 바뀌었다.

 

현상

netrw 디렉토리 화면에서 'c' 키를 누르면, 기대했던 것처럼 현재 디렉토리(PWD)가 변경되지 않고 Cannot make changes, 'modifiable' is off 라는 에러 메시지가 표시된다 (엄밀하게 말하면 'c' 키를 누르고나서 다른 키를 누를 때 에러가 발생).

" ============================================================================
" Netrw Directory Listing                                        (netrw v168)
"   /tmp
"   Sorted by      name
"   Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~
"   Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:special
" ==============================================================================
../
./
.ICE-unix/
.Test-unix/
.X11-unix/
.XIM-unix/
.font-unix/
go-build130920707/
go-build151298825/
go-build497434673/
go-build528811745/
go-build792304239/
go-build882984587/
hsperfdata_root/
systemd-private-4187beacd3f54ff8a36d04d8588cf77e-ntpd.service-xnhf54/
tmux-1801/
telegraf_command_time.touch
~
~
~
~
~
~
~
~
E21: Cannot make changes, 'modifiable' is off                                               8,1           All

 

 

원인 및 조치

VIM Netrw 화면에서 "현재 디렉토리 (PWD)" 바꾸는 명령어가 c 키에서 c,d 키로 바뀌었다 (c 키와 d 키를 순서대로 입력). PWD를 변경하기 위해 c 키 대신 cd 키를 사용하면 된다.

 

Reference

정말 이렇게 저렇게 구글링하다 포기하려던 참에 VIM 의 netrw-quickhelp 문서에서 원인을 발견함 (Netrw 화면에서 <F1> 키를 누르면 나오는 도움말 문서).

netrw-c : This map's name has been changed from "c" to cd (see netrw-cd).

 

(먼지 팁, 끝)

Posted by ingeeC
,

2019.10.19. 개발 계획을 정리함
2019.12.23. 개발을 마치고 소감을 추가/정리함

0. 배경

  • 간단한 Admin 포탈을 개발해야 하는 상황을 맞이함
  • 이에 웹 프론트엔드 개발에 사용할 기술스택을 조사, 그 선택 과정과 결과를 공유함
  • 선택 과정에서 https://bestofjs.org 의 자료가 유용했음

1. 웹 프론트엔드 프레임워크

  • React.js vs. Vue.js 를 고민
  • React.js
    • 페이스북이 개발
    • Virtual DOM 개념을 활용한 빠른 화면 처리 (Virtual DOM 개념의 원조)
    • MIT 라이선스 (페이스북 독자 라이선스 모델이었으나 커뮤니티의 요구로 변경됨)
  • Vue.js
    • 커뮤니티가 개발
    • Virtual DOM 개념을 활용한 빠른 화면 처리 (Virtual DOM 개념 따라쟁이)
    • MIT 라이선스 (상용 사용이 가능한 무료/오픈소스 라이선스)
  • 결론: Vue 선택
    • React.js가 잘 팔린다는 말에 고민했으나 Vue.js 학습 난이도가 낮다는 말에 Vue.js로 결정

Virtual DOM?
브라우저 안에서 DOM-tree 조작 (HTML 요소의 추가/삭제/변경)이 일어나면
이후 Render-tree를 만들고 이를 화면에 출력하는 프로세스가 진행됨.
이는 처리비용이 큰 프로세스여서 DOM-tree 조작을 줄일수록 화면 처리 성능이 개선됨.
Virtual DOM은 별도의 메모리 공간에서 DOM-tree 조작 작업을 수행한 다음
최종 결과만 실제 DOM-tree에 복사해서 브라우저 화면을 갱신하는 방식 (그래서 화면 갱신을 최소화 하는 방식).

==> 2019.12.23. 회고
Vue.js 선택에 후회 없었다. 처음 생각처럼 학습 장벽이 극히 낮아서 쉽게 배워 쓸 수 있었다. Vue.js의 SFC (Single File Component) 개념은 아주 멋졌다. 다음 프로젝트가 있다면 주저없이 Vue.js를 계속 쓸 것 같다.

 

 

2. UI 컴포넌트 라이브러리

UI 컴포넌트 라이브러리?
디자인된 UI 구성요소들(버튼, 콤보박스, 리스트박스 등의 화면 구성요소들)의 모음

  • Bootstrap vs. Vuetify 를 고민
  • Bootstrap
    • 트위터가 개발한 역사와 전통의 UI 컴포넌트 라이브러리
    • 반응형 웹디자인 (모바일 화면과 데스크탑 화면을 적절히 지원)
  • Vuetify
    • 커뮤니티가 개발
    • 구글이 제안한 '머티리얼라이즈 디자인' 제공 (플랫 스타일 디자인)
  • 결론: Vuetify 선택
    • Vue 프로젝트와 궁합이 더 좋을 것 같다고 생각

==> 2019.12.23. 회고
Vuetify 선택에도 후회 없었다. Bootstrap의 Grid System을 거의 그대로 지원한다. 그래서 반응형 UI (Responsive UI)를 만들기 좋았다. 라이브러리의 개념체계가 직관적이어서 Bootstrap보다 사용법이 쉽다고 느꼈다. 특히 문서가 정갈하고 좋았다.

 

 

3. 모듈 번들러

모듈 번들러?
브라우저와 서버 사이의 통신비용을 낮추고 처리속도를 높이기 위해,
브라우저 안에서 실행될 여러개의 JS 파일들을 한개의 파일로 묶어주는 도구

  • Webpack vs. Browserify 를 고민
  • Webpack
    • JS 파일 뿐 아니라 HTML, CSS, 이미지 파일들도 번들링 가능
  • Browserify
    • JS 파일만 번들링
  • 결론: Webpack 선택 (별로 고민할 거리가 없었음)

==> 2019.12.23. 회고
이건 vue cli가 만들어주는 틀을 그냥 따랐던 것이 잘했던 것 같다. 내가 무엇을 선택해서 쓴다는 느낌이 들지 않았다. 모든 것이 자연스러웠다.

 

 

4. 테스트 프레임워크

  • Mocha vs. Jasmine 을 고민
  • 결론: Mocha 결정 (별로 고민할 거리가 없었음)

==> 2019.12.23. 회고
UI를 위한 유닛 테스트를 작성하지 않았다. 이번 개발 범위가 워낙 단촐해서 테스트 코드를 만드는 것이 오버헤드라고 판단했다. 하지만 이 프로젝트가 살아남는다면 반드시 해야 할 일이라고 생각한다 (다음을 기약).

 

 

(이상)

Posted by ingeeC
,

golang 1.13 릴리즈를 통해 "go 모듈 (이후 go mod)" 지원이 강화됨

  • 몇 주 전 (2019-09-03) golang v1.13 이 릴리즈 됨. 이 버전의 가장 큰 특징은 go mod 지원이 강화된 것 (이제 옵셔널 피쳐가 아니라 디폴트 피쳐).
  • go mod 관련 릴리즈 히스토리
    • v1.11 (2018-08-24)
      • go mod 지원 시작 (옵셔널 피쳐로 추가)
      • $GO111MODULE (임시) 환경 변수값에 따라 go mod 지원 방식 결정 (on, off, auto)
    • v1.12 (2019-02-25)
    • v1.13 (2019-09-03)
      • go mod 지원 강화 (go mod 방식이 디폴트 피쳐가 됨)
      • 구글이 운영하는 go module mirror와 go checksum DB를 사용 (디폴트)
  • golang의 강점은 "하위 호환성 보장"
    • 2012년 golang 1.0 출시 이래 지켜져 온 약속
    • go mod 기능도 하위 호환성을 고려함
      • 예전 $GOPATH/src 디렉토리 체계도 지원
      • 예전 vendor 디렉토리 체계도 지원

golang 모듈이란?

  • golang의 모듈이란 버전이 붙은 패키지들의 묶음을 말함 (패키지는 소스코드 파일들의 묶음).
  • go mod 체계의 구성 요소
    • go.mod 파일
      • 의존하는 모듈과 버전을 명시하는 파일
    • go.sum 파일
      • 모듈의 파일이 바뀌지 않았음을 확인하기 위해 저장하는 첵썸 파일
      • go 명령이 go.mod 에 정의된 모듈을 다운로드할 때 각 모듈의 첵썸값을 go.sum 파일에 자동 기록
      • 이를 첵썸 디비(아래 설명)와 대조, 모듈 내용의 변경 여부를 확인
    • module mirror
      • 모듈을 다운로드 하는 서버
      • 모듈의 소스레포가 죽었을 경우 (또는 폐기되었을 경우) 대비 (그런 경우에도 모듈 다운로드 보장)
      • go 명령이 디폴트 참조하는 미러 서버를 구글이 운영 (proxy.golang.org)
      • 관련 명령 : go get, go build, ...
    • check sum DB
      • 모듈이 위/변조 되지 않았는지 확인하는 서버
      • go 명령이 디폴트 참조하는 첵썸 디비를 구글이 운영 (sum.golang.org)
      • 관련 명령 : go get, gosumcheck, ...
    • go.mod 파일과 go.sum 파일은 소스관리 대상

go mod 를 사용하면 무엇이 좋은가?

  • $GOPATH/src 디렉토리 바깥에 프로젝트 디렉토리를 만들 수 있음
  • vendor 디렉토리를 사용하지 않아도 됨
  • reproducible build (언제,어디서나,누구라도 항상 동일한 build 결과를 보장함)

go mod 철학

  • reproducible build
    • 검증된 빌드 / 반복 가능한 빌드
    • go.mod 파일과 module mirror 서비스를 이용하여 처리
  • immutable dependency
    • semantic versioning (SemVer : https://semver.org/spec/v2.0.0.html)
      • 모듈의 버전은 v0.0.0 포맷 버전 체계로 한다 (강제사항)
      • 첫 글자 v 필수
      • 버전 숫자 3개 필수 (major ver, minor ver, patch ver)
    • semantic import versioning
      • major 버전에 따라 import path 를 달리 가져간다 (ex. import "my/thing/v2/sub/pkg)
      • v0, v1은 import path 에 버전을 포함하지 않는다 (기존 import path 그대로)
    • go.sum 파일과 check sum DB 서비스를 이용하여 처리
  • minimal version selection
    • go.mod 에 참조 모듈을 서술할 때 minimum ver 만 명시한다
      • (node.js 의 npm 같은) 다른 패키지 관리자처럼 go.mod 에 incompatibility 를 서술하지 않는다
    • go.mod를 해석하여 참조 모듈을 선택할 때, minimum version 을 선택하는 방식이
      • 모듈 업그레이드로 인한 빌드 실패 발생 확률을 낮춘다 (reproducible/repeatable build 보장)
      • 모듈 업그레이드로 인해 빌드 실패 발생시, golang 커뮤니티가 해결 시간을 더 확보할 수 있다
    • go 명령어를 이용하여 처리 (go get, go build, go test, ...)

go mod 사용 방법

  • 기존 프로젝트를 go mod 체계로 이전하는 방법
    • (golang 업그레이드를 위해) 기존 go 설치물 제거
      sudo rm -rf /usr/local/go/
    • go v1.13 설치
      curl -O https://dl.google.com/go/go1.13.linux-amd64.tar.gz
      sudo tar -C /usr/local -xzf go1.13.linux-amd64.tar.gz
    • 프로젝트 루트에서 go mod 초기화
      cd PROJECT_ROOT
      go mod init
    • go.mod 파일, go.sum 파일 확인
    • build & test 성공 확인
      go build
      go test

추가로 알면 좋은 것들

  • go.mod 샘플

    module "my/thing"
    
    require (
      "google.golang.org/appengine" v1.0.0
      "github.com/google/go-github" v0.0.0-20180116225909-922ceac0585d
    )
  • go.mod 파일을 구성하는 명령 목록

    • module, require, exclude, replace 명령 사용 가능 (4개뿐)
      module "my/thing"
      require "other/thing" v1.0.2
      require "new/thing" v2.3.4
      exclude "old/thing" v1.2.3
      replace "bad/thing" v1.4.5 => "good/thing" v1.4.5
  • go.mod 파일은 직접 작성/수정할 필요 없음

    • go 명령을 통해 자동 작성/수정됨
      go mod init
      # .git, Gopkg.toml, Gopkg.lock 등을 참조하여 go.mod 파일 생성
      
      go get, go build
      # go.mod 파일 업데이트
      # 소스코드에서 import 한 파일 목록을 찾아 
      #  1. go.mod 파일에 추가
      #  2. GOPATH/pkg/mod 디렉토리에 버전별로 설치
      #  3. 프로젝트 루트에 go.sum 파일 생성
      
      go tidy
      # go.mod 파일과 소스코드를 비교/검증하여, go.mod 파일 목록을 (다시한번 단단히) 정리
      
      go mod verify
      # 로컬에 설치된 모듈의 해시 값과 go.sum 파일을 비교하여 검증

ref

다음 2개의 자료를 순서대로 보는 것을 추천함.

(이상)

Posted by ingeeC
,

GOPATH와 module 관련 소식

Golang 의존성 관리 규칙이 바뀔 참이라고 한다. 2019년 8월 golang 1.13과 함께 공식 릴리즈 된다고 하니 그때까지는 지켜보는게 좋겠다.

An intro to dep: How to manage your Golang project dependencies

https://medium.freecodecamp.org/an-intro-to-dep-how-to-manage-your-golang-project-dependencies-7b07d84e7ba5
2018-11-26
  • Golang 툴체인에 의존성 관리 기능이 내장됨
  • dep 도구는 Golang의 공식 의존성 관리 도구가 아님

Go Modules in 2019

https://blog.golang.org/modules2019
2018-12-19
  • 패키지 의존성 관리에 관한 커뮤니티 차원의 토론이 있었음. 향후 패키지 의존성 관리를 위해 module 개념을 도입할 것임. module 개념이 GOPATH 사용을 대치할 것임.
  • module 지원 계획
    • go 1.11 (2018년 8월 출시) ~ module 개념 시험 도입 (go.mod 파일 이용)
    • go 1.12 (2019년 2월 출시) ~ module 개념 지원 강화 (go run, go get 명령과 연계)
    • go 1.13 (2019년 8월 예정) ~ module 개념 디폴트 적용

결론

지금은 GOPATH 환경변수만 쓰고, module 개념은 8월가서 공부하기로 함.


Posted by ingeeC
,

VIM-GO, Golang 개발환경 꾸미기


회사 업무 때문에 Golang을 쓰고 있다. 코딩 스타일과 디렉토리 구조를 강제하는 점이 불만이지만, 그에 대한 반대급부로 편리함을 제공해준다. Golang은 개성이 중요한 예술가적 마인드의 개발자를 위한 도구가 아니라 문제해결이 중요한 실용가적 마인드의 개발자를 위한 도구인 것 같다.

Golang이 강제하는 코딩 스타일과 디렉토리 구조를 받아들인다면, 주요 OS마다 제공되는 표준 툴의 편리함과 일관됨을 누릴 수 있다. Golang을 설치하고 vim-go를 설치하면 다른 번잡한 툴이 필요 없다.

Golang 툴 설치

https://golang.org/doc/install 페이지가 안내하는 대로 따라하면 어렵지 않게 설치할 수 있다. GOROOT 환경변수와 GOPATH 환경변수 설정이 중요하다. GOROOT는 Golang 툴이 설치된 root 디렉토리 (예를 들어 /usr/local/go)이고, GOPATH는 Golang 프로젝트 관리를 위해 사용할 home 디렉토리 (예를 들어 /home/some-usr/go)이다. GOPATH 디렉토리 아래에는 툴에 의해 bin, pkg, src 디렉토리가 강제로 생성되고 관리된다. 개발자는 $GOPATH/src/ 디렉토리 아래에 프로젝트 디렉토리를 만들어야 한다 (안 내켜도 받아들이는게 편하다).

Vim-go 설치

  1. Vundle (VIM 플러그인 매니저) 설치
    .vimrc 설정파일을 GitHub에 올렸다. 해당 파일에 Vundle 플러그인 매니저의 설치방법도 메모해뒀다.
    https://gist.github.com/ingee/0554f2a8ae8c018d0f8b0c0c2c322767
  2. vim-go (Golang VIM 플러그인) 설치
    VIM 에디터에는 Vundle 말고도 다양한 플러그인 매니저가 존재한다. 어느 플러그인 매니저를 사용하든 상관 없다. VimAwesome 페이지(https://vimawesome.com/)를 방문하면 수많은 VIM 플러그인들의 목록과 설치방법을 확인할 수 있다. Golang 프로젝트 개발을 위해서는 vim-go 플러그인을 설치해야 한다. 바로 위 .vimrc 파일에는 Vundle 플러그인 매니저를 이용해서 vim-go 를 활용하는 설정이 이미 존재한다. .vimrc 를 수정한 다음, vim 을 실행시키고 커맨드 모드에서 :PluginInstall 을 실행시키면 vim-go 가 설치된다. vim-go 가 설치된 상태에서 :GoInstallBinaries 를 실행시키면 필요한 Golang 바이너리들이 설치된다 (바이너리 업데이트는 :GoUpdateBinaries). 여기까지 오면 준비 끝이다.
  3. Go 소스 탐색
    • hello.go 새로 편집
      vim hello.go를 입력하면 vim-go가 기본 뼈대를 자동으로 만들어 준다.
      package main
      
      import "fmt"
      
      func main() {
        fmt.Println("vim-go")
      }
      
    • <ctrl> ] 입력으로 소스코드 추적
      커서를 Println 구문 위에 놓고 <ctrl>+] 키를 입력하면 fmt.Println() 함수 구현부로 이동한다.
      // Println formats using the default formats for its operands and writes to standard output.
      // Spaces are always added between operands and a newline is appended.
      // It returns the number of bytes written and any write error encountered.
      func Println(a ...interface{}) (n int, err error) {
        return Fprintln(os.Stdout, a...)
      }
      
    • <ctrl> o 입력으로 소스코드 복귀
      다시 <ctrl>+o 키를 입력하면 직전 편집 위치로 복귀한다. <ctrl>+] 키와 함께 쓰면 편하다.
      package main
      
      import "fmt"
      
      func main() {
        fmt.Println("vim-go")
      }
      
끝!


Posted by ingeeC
,

Private vs. Public,
Permissioned vs. Permissionless 블록체인


멋지고 선명한 정의를 발견하여 메모함.

private vs. public 블록체인

  • Who can read from the Blockchain?
  • 제한된 사람들만 블록체인을 조회할 수 있으면 프라이빗 블록체인
  • 누구나 블록체인을 조회할 수 있으면 퍼블릭 블록체인

permissioned vs. permissionless 블록체인

  • Who can write to the Blockchain?
  • 허가된 사람들만 블록체인 합의에 참여할 수 있으면 퍼미션드 블록체인
  • 누구나 블록체인 합의에 참여할 수 있으면 퍼미션리스 블록체인

Posted by ingeeC
,

Permissioned Blockchain 합의 알고리즘의 종류


Permissioned Lottery based Consensus

  • 리더를 추첨, 리더가 블록을 생성
  • 사례: PoET (Proof of Elapsed Time), PoW
  • 장점: node 개수가 대규모일 때 적합
  • 단점: fork가 일어날 수 있음, 따라서 finality 확정까지 긴 시간 소요


Permissioned Voting based Consensus

  • 투표에 의한 합의
  • 사례: RBFT (Redundant BFT), PBFT (Practical BFT)
  • 장점: 빠른 finality 확정
  • 단점: node 수가 늘어날수록 합의 시간이 길어짐, 즉 scalability와 speed 사이의 trade-off 존재



합의 알고리즘 관련 용어

  • Safety : 같은 TXs를 처리하면 모든 node가 같은 결과를 내야 한다 (같은 블록체인을 만들어야 한다)
  • Liveness : 살아있는 node는 시간이 흐르면 결국 모든 TXs를 수신해야 한다


Ref.


Posted by ingeeC
,

개요

블록체인 ID 관련 막연한 궁금증이 있었음.

  Q: 블록체인 위에 ID 정보를 저장해도 좋은가 (그러면 모든 개인 정보가 공개될텐데)?

조사를 통해 얻은 답은 다음과 같음.

  A: public 데이터(on-chain data)와 private 데이터(off-chain data)를 구분해서 관리한다.


ID 관련 개념 3가지

- claim: identity 정보. ex) "내 이름은 OO이고, 생일은 OO이다."

- proof: claim의 진위 증빙. ex) 실세계에서는 여권, ...

- attestation: 제3자에 의한 claim 진위 증빙. ex) 대학교의 학위증명, 회사의 재직증명, ...


Sovrin 사례 연구

배경 (문제인식)

  • 온라인 세계의 ID/PSWD 체계가 서비스별로 Silo 되어 있음
  • ID 데이터가 많은 Silo에 복제되어 있음 (유출 위험 증가)
  • 블록체인이 Self-Sovereign ID 실현의 돌파구가 됨 (Center Authority의 도움 없이 ID와 Key 생성)

비전: Identity for All (사람/조직/사물을 위한 ID)

  • ID 데이터가 유출되지 않는 방식 (Security)
  • ID owner가 ID 데이터를 누가/왜 사용하는지 통제할 수 있는 방식 (Control)
  • ID 사용이 특정 서비스 사업자에 구속되지 않는 방식 (Portability)

개발팀

  • Sovrin 재단 (비영리 재단)
  • 오픈소스 프로젝트 (Contributor 20명 안쪽)

Sovrin의 ID 데이터 운영 방식

  1. public claim 데이터
    . on-ledger 데이터 (Sovrin Ledger에 기록/공개)
    . 개인 식별이 가능한 데이터는 저장하지 않음
  2. prviate claim 데이터
    . off-ledger 데이터
      - Identity Graph: 이름, 주소 등의 개인 정보
      - Relationship Graph: 주소록, SNS 등의 네트워크 정보
      - Reputation Graph: ID owner에 대한 평판 정보
      - Data Graph: 사진, 파일 등 기타 정보
    . 사용자 SW (Sovrin Client)에 원본 데이터 저장/관리
    . 사업자 SW (Sovrin Agent)에 사본 데이터 저장/관리 (private container)

Sovrin 소프트웨어 구성

  1. Sovrin Ledger (블록체인)
    • Plenum 합의 알고리즘 (PBFT의 변형) 사용
    • public permissioned ledger (누구나 이용할 수 있지만, 권한이 부여된 관리자들만 운영에 참여)
  2. Sovrin Agent (사업자 SW, 메일 서버에 해당)
    • Sovrin Ledger의 Client로 동작
    • Sovrin Client (사용자 SW)에게 안정적인 p2p end-point 제공
    • ID owner의 private claim을 저장 (하지만, 데이터에 대한 통제권은 ID owner에게 있음)
  3. Sovrin Client (사업자 SW, 메일 클라이언트에 해당)
    • 사용자 기기(PC/Mobile) 위에서 동작 (한 사용자가 여러개의 Client 운용 가능)
    • ID owner의 keychain 저장
    • ID owner의 private claim 데이터 저장
    • Sovrin Agent의 도움으로 여러개 Client들의 data sync 수행

Ref.

(이상)


Posted by ingeeC
,

개요


Sidechain 기술이 해결하려는 문제

  • 비트코인의 기술적 한계 (느린 처리 속도, 스마트컨트랙트 미지원 등) 해소 필요
  • 하지만 문제 해소를 위해 별도의 블록체인을 새로 만들 경우, 다음과 같은 문제가 있음
    • 작업/노력의 중복 문제 : 비트코인과 비슷한 코드를 중복 작성/관리해야 함
    • 코인의 유동성 확보 문제 : 신규 블록체인의 참여자 부족으로 인해 신규 코인의 가치가 안정되지 않음

Sidechain의 문제 해결 방식: Pegged Sidechain을 제안

  • 비트코인과 asset 교환이 가능한 블록체인 (pegged sidechain)을 제안함 (관련 기술 규격을 백서에 제시함)
  • 효과
    • 비트코인과 연동함으로써 충분한 코인 유동성을 확보할 수 있음
    • 사이드체인의 기술적/경제적 결함이 해당 사이드체인 내부로 격리/제한됨 (혁신적 시도가 가능)

관련 용어

  • two-way peg : Sidechain들 사이에서 고정/유동 비율에 따라 코인을 교환하는 메커니즘
  • pegged sidechain : asset을 (two-way peg 메카니즘에 따라) 교환할 수 있는 블록체인


관련 솔루션

Posted by ingeeC
,