Golang 다형성 메모

Dev 2021. 3. 14. 17:25

컴파일되는 JavaScript

개인적으로는 golang(고랭, 고언어)을 컴파일되는 JavaScript라고 생각한다.
golang에는 드러나지 않는 곳에서 많은 것을 처리하는 golang 런타임(JavaScript 인터프리터에서 파생된 무엇?)이 숨어있다. 그리고 golang 컴파일러는 golang 런타임을 뜯어서 큰 힘 들이지 않고 쉽게 만든 것 같다 (이건 칭찬이다). golang은 아름다움보다는 실용성을 추구한 언어다. 그게 golang의 매력이다.

 

같은듯 다른 '객체 (Object)'

c++ 같은 OOP 언어에서 객체는 변수와 메소드의 덩어리다. 그리고 type이다. c++로 객체지향 프로그래밍을 한다는 것은 달리 말하면 type을 정의하는 일이다.
반면, JavaScript에서 객체는 key-value 테이블이다. 그리고 instance다. JS Object를 딱히 type이라고 부르기 어려운 것이 JavaScript에서는 JS Object 아닌 것이 없기 때문이다. int도 JS Object이고, string도 JS Object이고, 심지어 function도 JS Object다.

 

다형성을 책임지는 interface 타입

golang은 type을 철저하게 체크한다. 하지만 JavaScript보다 조금 더 엄격한 정도다.
golang 코드의 interface 타입은 컴파일 시점에 결정되지 않는다. 실행 시점에 golang 런타임이 interface 타입을 체크한다 (즉, interface 타입 변수가 interface로서 갖춰야할 method 들을 구비하고 있는지 체크한다).

 

"Essential Go" 책의 설명을 참조하자.
https://essential-go.programming-books.io/reflection-c7fea6b176b74c54ab35f2d8fdd56f13

 

Reflection

Reflection

essential-go.programming-books.io

Go는 정적 타입 랭귀지다. 대부분의 경우 변수의 타입은 컴파일 시점에 알 수 있다. 하지만 interface 타입은 예외다. interface 타입 뒤에 있는 값이 실제 무슨 타입인지 컴파일 시점에는 알 수 없다.

 

요약하면 다음과 같다.

  • interface 타입으로 어떤 method가 필요한지 규격을 정의할 수 있다.

    type writer interface {
      write()
    }
  • struct 타입으로 필요한 method를 구현할 수 있다.

    type koreanWriter struct{}
    func (k koreanWriter) write() {  
      fmt.Println("안녕하세요")  
    }
    
    type englishWriter struct{}
    func (e englishWriter) write() {  
      fmt.Println("Hello")  
    }
  • 어떤 struct가 어떤 interface 규격을 만족시키는지 언어적으로는 명시하지 않는다 (명시할 수 없다). golang 런타임이 실행 시점에 체크한다.

    func main() {  
      kw := koreanWriter{}  
      var iw writer = kw  
        // koreanWriter 구조체와 writer 인터페이스와의 관계가  
        // 언어적으로 명시되어 있지 않지만  
        // golang 컴파일러가 컴파일 시점에 체크,판단
      iw.write()  
        // koreanWriter 구조체와 writer 인터페이스와의 관계가  
        // 언어적으로 명시되어 있지 않지만  
        // golang 런타임이 실행 시점에 체크,실행
    }

 

샘플코드 - interface 타입을 이용한 다형성 구현

상이한 타입의 변수들을 단일한 interface로 일관성있게 다루는 것이 다형성의 매력이다.

package main

import (  
  "fmt"  
)

type writer interface {  
  write()  
}

type koreanWriter struct{}

func (k koreanWriter) write() {  
  fmt.Println("안녕하세요")  
}

type englishWriter struct{}

func (e englishWriter) write() {  
  fmt.Println("Hello")  
}

func main() {  
  wa := []writer{kw, ew}  
  for _, iw := range wa {  
    iw.write()  
    //  
    // 상이한 타입의 변수들을 단일한 interface로  
    // 일관성있게 다루는 것이 다형성의 매력 
    //  
  }  
}

Posted by ingee
TAG Golang

댓글을 달아 주세요

웹 프론트엔드 TDD?

Dev 2020. 10. 15. 05:22

어찌어찌 프로젝트가 살아남았고 간단한 Admin 포털을 또 만들 기회가 있었다.

지난번에 이어 이번에도 개발 소감을 요약해본다 (2020.10.15. 기준).

 

개발환경: win10 좋다
- OS: win10 + wsl + windows terminal
- tool: vim, tmux, nodejs, vue-cli
- framework/lib: vue, vue-router, vuetify, vuex, axios
- runtime: firefox + vue dev-tools

 

프론트엔드 프레임워크: Vue 좋다

- 컴포넌트
  . 통상 웹UI 컴포넌트 하나를 구현하려면 html, css, js 3개 파일이 필요
  . Vue는 UI 컴포넌트 하나를 하나의 파일로 정의 (SFC: Single File Component)
  . 개발/관리 측면에서 좋았음
- 급격하지 않은 변화
  . 개발 진행중에 Vuetify 문서가 버전업됨
  . 하지만 변화 폭이 크지 않아서 쉽게 적응할 수 있었음
  . Vue 프레임워크 자체도 곧 3.0으로 버전업될 예정. 하지만 Vue 2.0과 크게 다르지 않을 예정
  . "변화 폭이 크지 않고, 변화 방향이 합리적"인 것이 프레임워크의 중요한 장점이라 생각함

 

디버깅툴: Firefox + Vue Dev-tools 좋다

- Vue dev-tools의 vuex 히스토리 기능이 큰 도움 됨
  어플리케이션의 상태 정보를 확인해서 해결되는 문제가 (생각보다) 많았음
- vuex의 mutation은 존재 의미를 불신하던 기능 (필요 없다 생각했음)
  Vue dev-tools 활용만으로도 vuex mutation의 가치를 느낌

 

프론트엔드 TDD: 정말 유용한가?

- 백엔드 tool을 개발하면서 TDD의 유용성을 체감함
- 그래서 프론트엔드 개발에도 TDD를 적용하는 것이 도리일 것이라고 생각,
  이번 작업에서 프론트엔드 TDD를 시도해봄
- 구현 코드보다 테스트 코드를 먼저 작성하면서 개발 요구사항을 정리해봄
  생각을 정리한다는 측면에서 나름 의미는 있었지만,
- 프론트엔드 테스트 코드는 구현 코드와 밀결합될 수 밖에 없음을 느낌
  그리고 프론트엔드의 문제점은 테스트 코드보다 눈과 손으로 먼저 체크하게 됨을 느낌
- 테스트 코드를 작성하는 번거로움 대비 실익을 느낄 수 없었음
- 단기간(3달) 동안 거의 혼자 하는 개발이어서 그랬을지도 모름. 베스트프랙틱스에 대한 조언을 구함

 

(이상)

 

 


2021-04-25.

HTML 태그의 data- 속성을 이용해서 실제 구현 코드와 테스트 코드의 의존성을 분리할 수 있다는 조언을 들었다.

예를 들어 화면에 표시되는 메시지 문자열을 검증하는 테스트 코드를 만들 경우, 특별한 data- 속성 (예를 들어 data-test-id="message")을 가진 HTML 요소를 찾아 그 문자열을 검증하면 된다. 이렇게 하면 개발자가 해당 문자열을 표현하기 위해 어떤 HTML 태그를 쓰는지, 어떤 id를 쓰는지 같은 세세한 구현 디테일과 분리된 테스트 코드를 작성할 수 있다. 그러면 차후 HTML 구조가 바뀌거나 엘리먼트 id가 바뀌어도 테스트 코드는 변경 없이 유지할 수 있다.

 

 

Posted by ingee

댓글을 달아 주세요

  1. ckj300 2020.11.17 17:33  댓글주소  수정/삭제  댓글쓰기

    도움되는 내용 정말 잘 배우고 갑니다

  2. 2020.12.14 18:44  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  3. cheolhow 2020.12.22 12:24  댓글주소  수정/삭제  댓글쓰기

    mozilla hacks 페이지 잘 봤습니다 :)

    TDD는 여러 개발자들이 함께 지속적인 서비스를 하는 앱을 개발할 때 유용한거 같습니다.

    백엔드도 나름의 UI(JSON등의 API의 결과들)들이 있긴 하지만 읽거나 확인하는데 친화적이진 않아서 테스트 코드에 효용성이 더 높아보이기도 하네요.

    또한 각각의 로직들이 서로에게 영향을 미칠 수도 있기에 (DB와 맞닿아 있기도 하고) 기존에 개발된 부분들에 대한 정상 동작을 확신하고 넘어가야 개발이 쉬울거 같기도 하네요.

    반면 프론트엔드에서는 UI가 굉장히 사용자 친화적이기도 하고, 웹에서는 여전히 stateless한 동작을 하게 구현이 되는 경우가 많다 보니 각각이 독립적으로 동작하기에 눈에 보이는 부분들만 확인해도 대부분에 문제가 잡히는거 같습니다.

    Vue나 React같은 경우도 워낙에 devtool이 훌륭해서 component나 상태들(store), route의 변화, 심지어 특정 이벤트나 메서드들의 실행까지도 확인할 수 있기에 즉각적인 디버깅이 쉬운거 같습니다.

    프론트엔드에서 큰규모의 복잡한 상태관리를 하는 웹앱의 형태라면 TDD가 유용할거 같지만 흔하지 않은거 같습니다.

    • ingee 2020.12.23 13:24 신고  댓글주소  수정/삭제

      귀한 의견 감사합니다.

      제 경우, 프론트엔드 테스트 코드를 작성할 때 구현코드와 밀결합되는 점이 힘들었습니다. "화면에 버튼이 있고 그걸 누르면 뭔가 표시된다" 정도가 아니라 "화면에 some-button-id 버튼이 있고 그걸 누르면 some-list-id 컨트롤에 some-string 이 표시된다" 정도의, 그것보다 상세한 테스트 코드를 준비해야 했습니다. 그래서 구현을 두번하는 느낌이었고, 구현 코드를 수정하면 테스트 코드도 함께 수정해야 했습니다.

      제가 프론트엔드 TDD 베스트프랙틱스를 몰라서 겪은 고통일거라 생각합니다. 경험이 더 쌓여서 프론트엔드 TDD 에 대한 생각이 달라지면 다시 포스팅을 올리겠습니다.
      ^^

시작하며

터미널 작업자에게 TMUX는 축복 같은 도구다. TMUX를 쓰면 터미널 작업의 효율성이 극적으로 높아진다.

  1. 우선 어떤 작업이 오래 걸릴 경우 그 작업이 끝날 때까지 멍하니 기다릴 필요가 없다. 즉시 다른 Window나 Pane을 열고 다른 작업을 시작할 수 있다.
  2. 또 어떤 작업을 하다 사정이 생겨 터미널 접속을 끊어야 할 경우 기존 작업이 중단되는 것을 걱정하지 않아도 된다. 터미널을 끊어도 하던 작업이 중단되지 않는다 (다시 말해 Session이 유지된다). 다음에 다시 접속해서 하던 작업을 이어 할 수 있다.

 

설치방법

설치 방법도 쉽다. 리눅스 사용자라면 표준 패키지 매니저를 이용해서 설치하면 된다.

  • (우분투라면) sudo apt-get install tmux
  • (CentOS라면) sudo yum install tmux

 

사용방법

CTRL-b 키가 TMUX의 기능을 부르는 핵심 키다.

 

0. TMUX 실행

$ tmux

 

1. Window 만들기, 이동하기

  • window 만들기 (create window) : CTRL-b, c
  • window 이동하기 (next window) : CTRL-b, n

 

2. Pane 나누기, 이동하기

  • 가로 pane 나누기: CTRL-b, "
  • 세로 pane 나누기: CTRL-b, %
  • pane 이동하기: CTRL-b, 화살표

 

3. 세션 끊기, 이어하기

  • 세션 끊기 (detach) : CTRL-b, d
  • 세션 이어하기 (attach) : tmux a

 

터미널 접속만 가능한 소박한 환경에서도 TMUX와 VIM만 있으면 충분히 많은 일을 할 수 있다.

터미널 만세!

 

Posted by ingee
TAG tmux

댓글을 달아 주세요

  1. corea_fun 2020.11.24 01:00  댓글주소  수정/삭제  댓글쓰기

    유용한 내용 되게 잘 배우고 가용~

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 ingee
TAG Vim

댓글을 달아 주세요

몇 주 전 리눅스 재단에서 주관하는 CHFA 시험에 간신히 합격함 (턱걸이). 간단한 후기를 공유함.

  • Empty Desk를 요구 -- 장소에 대한 검사가 까다로움. 시험 보기 전에 응시자가 있는 공간을 노트북 카메라로 비춰줄 것을 요구. 책상에 아무 것도 없어야함. 노트북을 빙빙 돌려 가며 공간을 체크하는 데, 약 15분 이상 소요. 약간 기분이 상할 정도.
  • 여권 지참 -- 노트북 카메라로 신분증을 검사. 여권이 좋음. 운전 면허증을 보여줬더니 그건 안된다고.
  • 시험 형태 -- 실제 서버에 ssh 접속해서 HLF Admin 과제를 수행하는 방식 (14문제. 커트라인은 62%).
  • 준비 조언 -- HLF 튜토리얼 중 "Building Your First Network", "Adding an Org to a Channel"을 숙지해야 함. 아울러 Fabric CA User's Guide도 숙지 필요.
  • 오픈북 -- 시험 중 Fabric Document 사이트와 Fabric CA User's Guide 사이트는 열람과 카피&페이스트를 허용. 그외 다른 사이트와 파일은 참조 불가.

자세한 자료는 Linux Foundation Certification 사이트를 참조. HLF 사용법을 점검/요약하기에 좋은 방법이라고 생각함.

Posted by ingee

댓글을 달아 주세요

  1. 2020.08.19 16:32  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다