ruby의 참고 문서들은 대체 어떻게 정리되고 있는 것일까….

쓰다쓰다 짜증이 나서 좀 여러모로 함숨이 나온다. ㅠㅠ

한국에서는 진짜 루비 쓰는 케이스 별로 없는 듯 하다. 레일즈를 장고 만큼 쓴다고 듣기는 했는데 그냥 주먹구구식으로 대충 찾아서 내놓은 것 외에는 아무리 봐도 사람들끼리 모여서 자료를 정리하고 하는 모습은 별로 안보이는 듯 하다.

뭐, 근데 이건 어디나 마찬가지겠지만… 몇몇 커뮤니티들이 활성화 되어있는 곳 아니면 아무래도 그럴 확률이 확실히 늘 것이다.

그나마 여러모로 커뮤니티 형식으로 활성화 잘 되어서 여러모로 자료 정리가 잘 되어있는 곳이라고는 오픈스텍이랑 파이썬 정도일듯.

MS 제품군은 MS가 알아서 잘 해주는 형식이 좀 강하니 제대로 좀 잘하는 분들이 노하우 정도 하나 둘 공유하고 하는 편이니 패스하고, 자바쪽은 이미 답이 없고….(알아서 잘 쓰는 게 자바 아닌가? C 처럼 짜서 써도 오~ 하고 박수치는 동네가 뭘… 요즘은 그런 거 없긴 하겠지만…ㅡㅅㅡ (그만큼 자바 실력자가 하늘과 땅을 미친듯이 갈라댄다. 그리고 대부분은 그런 거 필요없는 사람들이 많고..))

레일즈 쓰시는 분들이 여러모로 정보 공유는 하는 거 같지만, 실제로 루비의 경우에는 책마다 써놓은 내용도 다르고, 튜토리얼 관련 자료들도 이런 것 정도는 다뤄도 될거같은데? 싶은 것들도 안다루고 그냥 넘어가는 곳도 많다. 단순한 수준의 소캣 프로그래밍도 안다루는 튜토리얼과 책도 넘칠 정도니… 뭐, 다 다루면 옛날에 파이썬2.x 초반때 책들 기본 막 500쪽 600쪽 단위로 무지하게 두껍게 나오고 했던 것처럼 되겠지만… (아는 동생이 그걸 참 잘도 들고다녔다..)

레일즈랑은 별개로 자료 좀 정리해야 할 것들이 보이긴 한다만…..

혼자서 정리하긴 힘들겠지. ㅠㅠ

p.s. 일 안하고도 월급 나오면서 내 멋대로 해도 되는 생활이라면 금방 정리할 수 있겠지만 말이다…ㅠㅠ (그런 건 불가능하잖아?)

Docker Hub의 이미지로 도커를 사용해보기 – 1

도커에서 필요로 하는 이미지는 직접 만들어서 쓸 수도 있지만, Docker Hub에 이미 만들어진 것을 가져다가 쓸 수도 있다. 일단 기본적으로 사용하는 명령어들을 익히기 위해서 Docker Hub에서 제공되는 이미지를 이용하여 직접 실행하는 것을 정리해 보려고 한다. 도커를 이용하는 데 있어서 가장 기본적인 명령어들이니 그냥 있는 이미지를 가지고 이용하는 방법으로 작성해 보도록 하겠다.

사실 그냥 Docker Hub에 대해서는 별 거 없다. github를 처음 사용할 때와 비슷한 화면을 볼 수 있을 것이다.

스크린샷 2017-07-06 오후 11.06.01.png

그런데, 실제로 보면 이미 유명한 환경에 대해서는 이미 이미지를 별도로 배포하고 있다. 유명한 리눅스의 배포판, 오픈소스 프로젝트 등의 이미지, 그것도 가장 기본적인 이미지는 Docker Hub에서 제공을 하고 있다.

스크린샷 2017-07-06 오후 11.06.51.png

특히, 이미지와 관련된 모든 명령어는 기본적으로 Docker Hub와 연동이 되어있다. 이제 이 연동되어 있는 내용을 확인하고, 실제로 사용하도록 한다.

search

search 명령어로 이미지를 검색할 수 있다.

스크린샷_2017-07-27_14-53-44

여러 목록들이 쭉 나올 것이다. 우분투의 기본 공식 이미지부터 시작해서 다른 사람들이 자기 원하는대로 이용할 수 있는 판까지 다양하게 존재한다. 이 목록들은 docker hub에도 그대로 나타난다.

pull

pull 명령으로 이미지를 직접 받아오도록 한다. docker를 설치하면 기본적으로 이미지를 받아오는 곳은 docker hub에서 받아오도록 되어있다.

스크린샷_2017-07-27_14-54-35스크린샷_2017-07-27_14-54-45

받아오는 동안에 여러모로 받아오는데, 바로 컨테이너의 버전에 맞춰서 별도로 받아온 다음에 하나의 컨테이너로 구성해서 이용할 수 있게 해주는 것이다. 업데이트가 많이 되는 이미지들일수록 여러 버전들을 쫙 받아서 가장 최신으로 합쳐주는 작업을 할 것이다.

images

도커에 있는 모든 이미지들을 보려고 할 때 사용하는 명령어이다. 우분투 이미지가 받아졌는지 확인해보자.

스크린샷_2017-07-27_14-56-06.png

제대로 받아져있다.

글이 좀 길어져서 직접 실행하는 run 관련된 부분과 그 후의 내용은 2편에서 작성하겠다.

ruby…

내가 이걸 다룰까란 생각을 해본 적이 없었다. 이미 한국에서는 스크립트 언어와 웹 하는 사람들은 거의 자바 & 파이썬의 조합으로 통일되었다. 실제로 대학에서도 애들이 동아리나 어디 딴 곳 가서 배워와도 이 조합으로만 배워온다.

근데 쓸 일이 없다고 생각하는 것이 사실 여기저기에서 많이 쓰이고 있다는 걸 알게 되었을 때의 놀라움은 참…ㅇㅅㅇ;;;

루비는 진짜 간단한 언어다. 파이썬만큼 간단하다. 일본에서 만들어진 언어라서 일본 안에서는 엄청 쓰이지만 그 외의 국가에서는 “Programming Ruby”라는 책이랑 “실용주의 프로그래머”의 저자가 쓴 일명 곡갱이책(표지에 곡갱이 그려졌다.) 덕분에 전세계로 퍼지기 시작한 언어다. (루비가 뭔지 제대로 알려주는 명서다.) 그러다가 루비 온 레일즈가 등장하여 서구권에서는 빠른 웹 개발에서 미친듯이 쓰였다. 초기 프로젝트 스타트할 때 구현을 빨리 하기 위해서 레일즈를 이용하는 케이스가 많다. 그러다가 서비스가 커지면 이제 좀 제대로 구축할 수 있는 환경으로 옮겨가는 그런 식이다. (트위터가 대표적이다. 근데 아직 트위터 API 서버 중에는 레일즈 API가 남아있는 흔적이 있다. 아직 몇 곳에서는 쓰이는듯.)

뭐, 나도 졸업논문용 웹 서비스 빨리 개발하려고 딱 하루 루비랑 레일즈 공부하고 쓰고 있다. (그정도로 쉽다.)

의외로 사람들이 모르는 것이… 맥에서 쓰는 homebrew도 루비로 만들어졌다. 게다가 뭐 좀 해보겠다고 만져본 사람들은 RPG 쯔끄루로 뭐 이것저것 건드려본 사람도 있겠지만, 그거 언어가 루비다. 게다가 Github도….!

뭐, 이렇게 알게 모르게 쓰이고 있는 것이 현실이다. 게다가 몸에 좀 익은 언어라…

글을 남기고 싶다. (이녀석은 뭐 이리 남기고 싶어하는 게 많아..)

112 – make란?

오랜만에 다시 C 글을 작성합니다. 오랫동안 기다렸다면 죄송합니다. 졸업논문 쓰다가 머리가 너무 안돌아서 다시 잡고 하는군요. ㅠㅠ 그럼 시작합니다. ㅇㅂㅇ/

make 파일은 어플리케이션의 구성 방법을 make에 알려주는 텍스트 파일로, 다음과 같이 대상, 의존성, 명령으로 이루어진 규칙이 나열된 형식을 지닌다.

대상(target): 대상에 의존되는 파일 1 [대상에 의존되는 파일 2] [대상에 의존되는 파일 3] …
명령(command)

컴파일 할 파일은 적어도 하나는 있어야 하기 때문에 의존되어 컴파일 될 파일에 대해서는 하나는 꼭 적어주게 된다. 그리고 나서 명령을 한다. 이렇게만 보면 잘 모른다. 그러니 일단 하나하나 살펴보자.

  • 대상

대상(target)은 make가 궁극적으로 생성하는 것이다. 일반적으로 오브젝트 파일이나 실행 파일이 된다. 아래에 단순한 수준으로 예제를 하나 만들어보았다.

test: test.c
gcc test.c -o test

우리가 항상 뭐 하나 둘 만들어보고 돌려볼 때 쓰던 코드다. test라는 대상을 만들꺼라서 test를 직접 작성하였다.

그러나, 실제로 개발하다 보면 저기에 오는 것이 오브젝트 파일이나 실행 파일이 오는 것은 아니다. 특정 레이블이 오기도 한다. 레이블이 오는 경우에는 이런 경우다.

clean:
rm test.o

이렇게 만들면 make clean 이라고 명령하면 오브젝트 파일인 test.o를 삭제하는 clean이 실행된다. 이건 레이블을 설명할 때 좀 더 설명하도록 하겠다만 일단은 레이블이 올 수도 있다는 것을 알아두자.

  • 의존성

의존성(dependency)은 대상과 대상을 생성하는 데 필요한 소스 파일의 관계로, make 파일에서는 대상과 대상을 생성하는 데 필요한 파일 목록을 클론(:)으로 구분하여 작성을 하여 준다. 이것도 예제를 보면 쉽게 이해할 수 있다.

test: test1.o test2.o test3.o
test1.o: test1.c a.h
test2.o: test2.c a.h b.h
test3.o: test3.c b.h c.h

첫 줄에는 test라는 대상을 생성하는 데 test1.o, test2.o, test3.o 세 파일이 필요한 것을 알 수 있다. 그리고 두번째 줄에서 test1.o를 생성하는데 test1.c, a.h가 필요하고, 세번째 줄에서 test2.o를 생성하는 데 test2.c a.h b.h가, test3.o를 생성하는 데 test3.c b.h c.h가 필요하다는 것도 알 수 있다. 그리고 이 4줄의 코드가 전부 의존되는 파일들이 이어져 있다는 것을 알 수 있다. 이게 바로 의존성이다. 한 개 이상의 파일들이 서로를 필요로 하고, 그에 맞게 연결되어 있는 것이다. 이 경우에는 의존 관계 트리 형태로 최종 test를 만드는 데 필요한 헤더와 소스코드 파일이 트리 구조로 이어져있을 수 있다.

  • 명령

명령(command)에 정의된 명령은 대부분 컴파일러 호출이고, 대상이 의존하는 파일 중 변경된 파일이 있거나 대상이 존재하지 않을 때 실행된다. 명령에는 일반적으로 쉘에서 쓸 수 있는 모든 명령어를 사용할 수 있으며, bash의 기반이 되는 bash 쉘 스크립트도 지원한다. (이거 땜에 솔직히 쉘 프로그래밍을 공부하는 거라고 보면 된다.)

그리고 명령을 사용할 때는 다음과 같이 반드시 탭 문자로 시작해야 한다. make가 명령어인지 아닌지를 구분하는 것이 바로 탭 문자이기 때문이다. 또한 탭 문자 크기만큼 스페이스바로 미는 사람들(특히 초심자들)이 있는데, 그렇게 하면 안된다. 필자는 블로그 글을 쓰기 편하게 하려고 탭 대신에 스페이스로 밀어서 글을 작성하였다. 그러나 실제로는 그렇게 안짠다.

test: test1.o test2.o test3.o
[    탭    ]gcc -o test test1.o test2.o test3.o

이제 이걸 간단한 예시로 알아보려고 한다. 예시에 작성한 내용이 좀 많아서 그렇지 앞에서 설명한 내용대로 움직이는 지 확인하는 예시이다.

우선 test1.c test2.c test3.c 파일을 각각 만들어준다.

20171109_02302820171109_02310820171109_023120

위와 같이 소스코드를 작성한 후, 참조하는 헤더를 touch로 만들어준다. 참고로 stdio.h 헤더 일부러 include 안했다. 나중에 보자. 그리고 터치로 파일 만들어서 내용이 비어 있어도 컴파일 하는 데 있어서 상관은 없다. 파일이 없으면 파일 없는 에러를 내지만, 사용자 헤더 내용이 없는 건 오류가 되지 않는다.

20171109_023141

이제 Makefile을 작성한다. vi Makefile 이라고 해서 아래와 같이 작성을 한다. 참고로 짝수줄 앞에 빨간 영역이 바로 탭 영역으로 구분을 한 곳이다.

20171109_023331

작성 후, make를 입력하면 명령들이 실행되는 것을 볼 수 있다. 아래와 같이 나오면 정상이다. stdio.h 헤더가 없어서 경고를 출력한 것이다. 파일 자체는 두번째 화면과 같이 다 만들어졌다.

20171109_02341920171109_023457

여기서 중요한 것이 있다. 바로 Makefile의 실행 순서이다. 분명히 작성할 때에는 test를 맨 먼저 적었을 텐데, 정작 실행은 test1.o, test2.o test3.o 순서로 실행이 진행되었다.

즉, make가 Makefile에서 설정된 순서대로 실행이 되는 것이 아니라는 것이다. 바로 의존되는 관계 트리에서 가장 아래에 있는 의존성을 먼저 실행하게 된다. 가장 하위 대상에 속한 명령이 실행되고, 그 다음으로 해서 탐색 루트르 따라 올라가서 마지막에 제일 높은 의존을 가진 test가 실행된 것이다.

아까도 이야기를 잠깐 적었지만, 파일이 없는 것은 중요한 오류다. 그렇기 때문에 의존성이 있는 파일의 경우에는 의존성을 체크하여 의존 파일이 만들어져 있는지, 새로 만들어야 하는지를 탐색하면서 순서를 정리하여 빌드해 주는 것이다. 상당히 중요한 내용이고 Makefile이 엄청 커지게 되면 이게 제대로 구분이 가지 않는 경우도 많이 생긴다. 따라서 의존도 체크하는 것은 상당히 중요한 일이다.

또한 make 명령의 경우에는 각각의 타겟을 단독으로 실행할 수 있다. 우선 아래처럼 최종 완성본인 test를 지워보고 나서 make test를 통해 test만 실행해 보았다. 그러면 test는 오브젝트 파일 셋이 그냥 그대로 있으니 바로 컴파일해서 파일을 만들어내면 되는 것이다.

20171109_023617

파일이 수정된 경우에 대해서도 알아보자. 우선 b.h 파일에 아까 작성하지 않았던 stdio.h를 선언해주자.

20171109_023650

이 다음에 make를 진행하게 되면 b.h 파일이 의존성 파일 목록에 있는 작업들이 다시 실행될 것이다. test1의 경우에는 연관이 없기 때문에 빌드가 되지 않았다.

20171109_023702

이번에는 a.h 파일을 수정하였다.

20171109_023740

마찬가지로 a.h와 의존되는 파일이 다시 컴파일되었다. 헤더가 완전히 다 들어갔으니 경고도 날라오지 않는다.

20171109_023754

참고로 이미 다 컴파일 되어 있는 상태에서 다시 make로 컴파일을 하게 되면 ‘up to date”라는 문장을 보게 된다. 이미 다 업데이트 되었으니 안해도 된다는 것이다.

이제 레이블을 Makefile에 추가해 보겠다. clean이라는 레이블로, 다시 새로 빌드할 때마다 일일이 찾아서 지울 수 없으니 Makefile에 작성하였다.

20171109_023829

저 명령이 정확한 것인지 쉘에 직접 입력하여 확인하였다. 오브젝트 파일과 최종 결과물인 test가 지워졌다. 그리고 이걸 다시 make로 생성 후, make clean으로 clean 레이블을 실행하였다. 그러니 삭제 코드가 그대로 실행되는 것을 볼 수 있다.

20171109_023900

이것이 바로 make의 기본적인 사용법과 기본적인 내용이었다. 이 외에도 여러모로 알아둬야 하는 추가적인 내용 및 옵션들에 대해서도 정리를 하겠지만, 일단 이전 실습때 작성했던 C 파일들 중에 골라서 별도의 폴더를 만들고, 해당 파일과 Makefile을 만들면서 연습해 봐도 좋다.

오랜만에 작성하니 은근 힘들다…ㅠㅠ (논문 안쓰고 이거 써서 그럼..ㅠㅠ)

코드에 감정…? …흐유…

코드 미친듯이 갈리고 갈리는 개 개발이다. 이전에 짰던 코드들, 나중에 저그 생겨서 갈리고, 기능 바뀌면서 바뀌고, 코드 리뷰 통해서도 바뀌는 게 코드다.

근데 가끔, 아니 잦은 확률로 자기 코드 지적당하면 욕하는 사람들이 꼭 있다. 잦은 확률이라는 건 상당히 많이 있다는 거다. 좀 제대로 된 환경에서 일하는 개발자분들은 믿기지 않겠지만 사실이다.

코드는 어떤 목적을 구현하기 위해 만든 것이다 보니 여러모로 지적을 당하고 수정도 해야 한다. 그렇게 만들어진 것들에 대해서도 나 이외에 프로젝트를 같이 하는 동료들 또한 이걸 보고 내용에 대한 피드백도 해준다. 그렇게 또 코드는 바뀌게 된다.

이런 과정에서 개발자는 자신의 표현 방법, 알고리즘 등에 대해서 여로모로 배우게 된다. 좀 더 나은 코딩을 하기 위해서 지속적으로 업데이트 되는 것이다.

근데 이런 코드를 보이면서 감정이 상하거나 한다..?

초보일 때는 그럴 수 있다. 내가 머리 막 굴려가면서 미친듯이 짠 코드다. 이걸 누가 와서 이러니 저러니 하니 당장은 적응이 안되는 거다. 이건 뭐 배워가는 과정에서 나오는 거다 보니 차츰 없어진다.

그럼 회사에서 일하는 개발자가 이러는 경우…? 뭐 여러모로 있다…

해당 개발자가 인간관계가 이상하게 틀어지는 경우다. 뭐 좀 지적당하면 시비 걸리는 걸로 해석하고 그에 따라 욕하는 개발자들이다. 이런 개발자들은 뭘 해도 안고쳐진다. (이미 인간관계도 그런 상황이다.)

그리고 코드 개발이 갈리면 지기 실적이 갈리는 특유의 상황에 놓였을 때가 있는데… 이런 회사가 있냐고 묻는다면 있다고 하겠다. 어떤 거냐? “코드 = 생산물” 이라는 일차원적 마인드를 가지고 일하는 회사들이다. 공장에서 찍어내는 것처럼 코드도 그냥 찍어내는 거고, 잘못 만들어졌으면 전부 그냥 불량품 취급하는 사장이나 상사 밑에서 졸라게 갈리고 갈려나가서 제대로 된 생산물 있기 전까지는 실적 하나 없는 개발자 취급 당하다보니 자기 코드가 평가받고 하는 거 자체에 대해서 반발이 먼저 나오는 그런 케이스이다. 이런 식으로 까이게 되면 이 사람이 어떤 개발 파트에 따라서는 더 잘하는 개발을 할 수 있을지 없을지도 따지지도 못하고, 그냥 그대로 까이고 까이는 현상만 발생하기 때문에 그냥 무능한 개발자로 찍히는 거다. 이 사람이 하면 문제 있을 것이니 뭐니 하면서 까고 그러면서 좋은 개발자 없다고 까고 개발자 모집한다고 해서 면접보면 뭣도 모르는 이상한 소리 떠들다가 이러니 저러니 그러고… (그리고 개발자 임금 까는 데 제일 편한 방법이기도 하다.) 현실은 슬프게도 엄청나게 많은 중소기업 회사들이 그런 경우가 많이 있고, 이런 환경의 사람들이 과장, 차장을 달고 다닌다고 생각해보면… 답 없는 회사들 진짜들 많다는 게 이런 거구나란 생각 든다.

이런 환경을 “Issue review”라고 한다. (흔히 쓰이는 말은 아니다. 문제 리뷰라던가 다른 형식의 말도 많은데, 대부분이 버즈워드다 보니 그냥 지금 글 쓸때 생각나는 표현적인 단어를 좀 쓰겠다.) 해당되는 문제에 대해서만 리뷰를 하고, 이걸 수정해서 완성해야지만 되는 상황이다. 그래서 해당되는 이슈가 끝나면 그냥 방치해도 되는 그런 상황이 지속되는 그런 환경으로 들어간다.

그에 비해, 우리가 배울 때 하도 많이 들었던 “Code review”라는 건 안쓰는 거냐? 쓴다. 근데 쓰는 회사가 정말 극소수다. 한국에선 바라지도 말라고 할 수준으로… 네이버가 잘 되어있다고는 하는데, 네이버 코드리뷰도 아직은 부족한 수준이라고 평가된다고 한다. 근데 난 네이버의 내부를 자세히 모르니 까는 이야기가 나와도 그냥 그러려니 중이다.

코드 리뷰라는 거 자체를 경험해본 적 없는 사람이 쓴 이상한 논리의 트윗과 그걸 제대로 반박해준 트윗이 있어서… 나도 이상한 논리를 좀 까보고 싶었다. 그래도 안바뀌겠지만… (애당초 바뀔 환경이 아니다.)