Ruby 변수 관련 정리

변수 접두어

  • 루비는 C언어등과 다르게, 접두어가 변수의 종류를 구분 짓는다.
  • 아래는 변수를 구분 짓는 접두어를 의미한다.
  • 내 네이밍 규칙에 따르면 모든 변수를 상수로 만드는데, 루비의 접두어 룰로 인해 나도 네이밍 습관을 루비에선 따로 쓸 수 밖에 없었다.
기호 의미
$ 전역 변수
@ 인스턴스 변수 
@@ 클래스 멤버 변수
a-z_ 지역 변수
A-Z 상수

전역 변수

  • 루비에서 미리 정의해두고, 스크립트 작성에 도움이 되게 지원하는 변수들입니다.
  • 적절히 사용하시면 아주 유용합니다!
기호 의미
$! 마지막 에러 메시지
$@ 에러 위치
$_ 가장 최근에 gets로 읽은 문자열
$. 코드의 줄 번호
$& regexp로 마지막에 매칭된 문자열
$~ the last regexp match, as an array of subexpressions
$n n번째로 매칭된 문자열
$= case-insensitivity flag
$/ input record separator
$\ output record separator
$0 실행 프로그램 이름
$* 명령 행 인자들
$$ 프로세스 아이디
$? 최근 실행한 자식 프로세스의 종료 번호
ARGV[n] n 번째 명령 행 인자
$DEBUG 디버깅 메시지 -d를 키면 활성화
$stderr 표준에러
$stdin 표준입력
$stdout 표준출력
$: 스크립트가 로드한 모듈 이름들
ENV 시스템 환경 변수를 저장하고 있는 해쉬. 환경 변수 값을 변경할 수 있으며, 변경사항은 해당 프로세스 와 자식 프로세스에만 반영된다.

Ruby가 모듈을 찾는 장소.

Ruby에서 load나 require시에 참조하는 폴더

  • 쉘 현재 경로
  • RUBYLIB 환경 변수 경로

이 경로를 알고 싶을땐 아래와 같은 구문으로도 가능합니다.

% ruby -e 'puts $:'

이 경로가 아닌 다른 경로를 지정하기 위해서는, -I 경로 (대문자 I입니다)를 지정하거나, RUBYLIB 환경 변수에 추가해주시면됩니다.

예를 들어,

ruby Util/StartServers.rb filename

라는 구문이 있을때, -I 구문이 없다면 rb파일이 참조하고 있는 다른 파일들은 제대로 로드 되지 못합니다.

load 'XML_Util.rb'
load 'ShellExecute_Util.rb'
load 'ServerConstants.rb'

이 load 구문들에서 XML_Util.rb을 찾지 못해, 오류를 발생하는 것이죠.

그래서, 

ruby -I Util Util/StartServers.rb filename

이렇게 모듈 검색 경로를 설정해, 해당 모듈들의 위치를 지정함으로써, 해결 가능합니다.

단순한 문제지만, 구글링으로 원하는 답변을 찾다가, 프로그래밍 루비 (곡괭이책)에서 원하는 답변을 찾게되 올립니다. 저처럼 헷갈리신분 참고하세요~.

(서평) 조엘이 엄선한 소프트웨어 블로그 베스트 29선

조엘은 좋은 글을 쓰는 것만이 아니라, 좋은 글을 보는 눈도 역시나 탁월합니다.

조엘의 글은 IT 분야 글 읽는거 같지 않게 재밌게 잘 읽히는 경향이 있는데요, 조엘이 고른 블로그 베스트 29선 글들도 그런 글이 많습니다.

특히나 29. 여우캐릭터와 함께하는 빠르고 쉬운 루비 강좌는 꼭 읽어보시길 권합니다.

저도 이 책을 읽은게 2006년인데, 올해 되서야 제대로 루비를 쓰고 있는 정도지만, 루비에 대한 호감도를 올리고 쉽게 접근하기엔 아주 적절한 글이거든요.

경제학을 반드시 가볍게라도 익혀야 한다는 조엘씨의 지론답게, 간격 좁히기는 고객과 제품간의 이야기를 다룹니다.

제가 몇년전 그토록 많이 고뇌했던 좋은 프로그래머란 무엇인가는, 사실 좋은 제품을 만들어 고객에게 만족을 주는 소프트웨어를 만드는 것도 포함되는 의미입니다.

물론 이 챕터에서 말하고 있진 않지만, 같이 일하는 팀원들과의 관계와의 밸런스도 당연히 중요한 요인임은 물론입니다.

  1. 래리 소프트웨어 공학의 법칙 제2조: 테스터를 단순한 잣대로 평가하지 마십시오. 는 좋은 테스터와 프로그래머와의 상관관계에 대해서 아주 적나라하게 설명해준 챕터였습니다.

테스터와 버그 추적 시스템은 결코 찾아낸 버그의 갯수와, 버그의 레벨을 평가해선 안된다는 점을 논리적으로 잘 설명해준 글이라고 볼 수 있습니다.

사실 여러모로 크게 와닿았던 챕터는 바로 21. 팀 보상제도 인데요, 팀웍을 해치는 보상 시스템을 채용하고 있는 것이 사실입니다.

“아니 내가 저사람보다 못한게 뭐야?” 라는 얘기나, “저 사람은 평가자와 친해서 더 좋은 평가를 받은건가?” 같은 수위의 갈등까지는 아니더라도, 팀 내부 갈등의 주범이 되곤 하는 것이 바로 팀 보상 제도 내지는, 팀 평가제도라 볼 수 있는 것이지요.

팀 끼리 팀웍을 최대한 발휘해도, 좋은 제품을 만들까 말까인데 과연 이런 평가 시스템이 좋은 팀을 만드는 데에 긍정적일까요? 전 아니라고 봅니다. 언제나 저보다 뛰어난 팀원들과 같이 일하고 싶었던 저로썬, 이런 상대평가를 받게된다는걸 알고나니  제가 가진 생각을 유지하는 것이 썩 달갑지 않아졌습니다. 팀보다 개인을 생각하게 되더군요.

이러한 부분들을 잘 설명한 장애요인은 다음과 같습니다.

  1. 경쟁
  2. 불공평에 대한 인식
  3. 불가능에 대한 인식
  4. 부분 최적화
  5. 고유 동기 말살

대부분의 팀이 의욕 고취를 위해 취하는 보상제도가 이런 문제들을 낳고 있다니… 아이러니하죠? 이런 폐해를 막기 위해 이 글에서 제시한 가이드 라인은 다음 다섯 가지입니다.

  1. 승진 제도에 논쟁의 여지가 없게 하라.
  2. 성과급 제도의 의존도를 낮추라.
  3. 이익 분배와 경제 활동의 원동력을 연계 시켜라.
  4. 책임 범위가 아니라 영향 범위에 의한 보상제도를 확립 하라.
  5. 돈, 그 이상의 동기를 찾아내라.

예. 모두 그리 쉽지 않은 이야기입니다. 하지만, 이정도 노력없이 성과를 내고 있는 좋은팀을 지속적으로 유지 할 수 있을까요?

이렇듯, 조엘씨의 조엘 온 소프트웨어나, 조엘이 엄선한 소프트웨어 블로그 29선처럼 외국 개발자들도 우리네와 별반 다르지 않습니다. 그들도 어떠한 상황에 대해서 느끼는 감정이나, 고뇌는 비슷한거 같더군요.

이외에도 엄선된 글들이 전반적으로 다 좋은 내용을 담고 있습니다. 요즘들어 기술서적보다, 이런 내용의 글들이 읽고 싶어지던 시기에 다시금 꺼내봤는데 역시나 좋습니다.추천해요!

NDC2013 요약 정리

[홍종찬] 라이브 프로젝트에서 C++ 테스트 주도 개발하기 구체적인 행동 요령과 시행착오 공유.

  • 해맑은 웃음이 인상적. 긍정적인 분이신듯?
  • legacy 코드에 유닛 테스트를 적용하는 사례가 인상적이었다. 사실 라이브건 아니건 TDD로 100% 코드 커버리지는 없기에, 어디에나 적용되는 사례라고 봐도 무방해서 유익했다.
  • Q&A시간에 현재 프로젝트에 적용중이지 못하시다는 말에 나까지 아쉬웠다…;;
  • 코드 작성중 리팩토링 금지. 운전중 휴대 전화 사용과 유사하다는 말이 가장 인상적이었고, 공감 100배

[박범진] 게임 내 스토리 텔링의 중요성: 게임의 스토리란 과연 포르노의 줄거리에 불과한가?

  • 개인적으로 어디선가 많이 들어본듯한 스토리 텔링의 중요성 이야기.
  • 25분짜리 짧은 세션이었으나 가볍게 들을만한 좋은 주제가 아니었나 싶다.
  • 게임을 인터랙티브 무비 스럽게 접근했을 때의 가능성에 대해 적절한 비유로 잘 알려주셨음.

[안중원] 유연한 해외 서비스하기 - 해외 버전 관리 전략과 효율적인 커뮤니케이션

  • 커뮤니케이션에서는 이메일로 핵심만 누구에게 전하는지 요점만 간단히 (Keep it simple and short.) 작성하라는 내용이셨다. (혹은 이미지 첨부 등으로 쉽게 이해 할 수 있도록)
  • SVN 버전 관리 정책을 세종류로 분류 (단일, 브랜치 활용, 국가별 다른 버전) 장단점에 대해 논하셨다.
  • File Conflict, Tree Conflict를 명확히 정리해주신 것도 좋았음.

[배재현] 차세대 게임과 한국 온라인 게임의 미래 

  • 뭐… LOL이 압도적 1위인 국내 시장 내가 봐도 문제가 좀 있어보이고, 요새 온라인 게임 힘들고, 트렌드가 모바일로 가는 중이다 이런 얘기는 알겠는데… 무슨 얘기를 하시려는지 요점을 이해 못하겠음.
  • 좀 더 나은 서비스 (여러가지 면에서) 하자고 하시는거 같긴했으나… 아주 강력한 메시지는 없었던듯 ?
  • …으로 표현하신 사기 챕터는 나도 겪어본 적 있었던 바 아주 재밌게 들었다.
  • 재충전의 필요성… 모두 공감하지만 왠만한 규모의 회사에서도 대체인력은 커녕 조금만 여유로워도 감축이니 뭐니 얘기나오는 국내 상황에서 쉬운 얘긴 아니라고 본다.

[박종석] 테스트 꾸준히 잘하는 법 (매일 정시에 퇴근하는 그사람의 비밀)

  • Mock의 최소화는 절대 공감할 수 없었다. 테스트 마저 효율을 따져가며 해야 한다는 얘기신거 같은데, Mocking으로 인한 잘못된 원인 파악같은게 문제가 되긴 하겠지만, mock을 최소화하는 방식이 해결책이라는 의견은 공감할 수 없었다.
  • 또한 Mocking으로 인해 테스트가 깨지거나, 잘못된 코드가 테스트를 통과되는 상황이 있더라도, 없는것보다 나은 커버리지를 구축하기에 더더욱 공감 할 수 없었다.
  • Mocking으로 인한 고생은 시간을 날리는 것이 아니라, 기반 코드에 대한 이해, 테스트 커버리지가 낮은 상황 (Mocking을 실제 객체로 대체하려는 시도 또는, 기존 Mocking 상태에 대한 이해)에 대한 인지율을 높이기에 헛되지 않다고 생각한다.
  • 또 신뢰성 있는 모듈사용은 테스트 코드를 작성하지 않는다 하셨는데, 신뢰성 있는 코드라도 내가 사용하는 코드가 불안해서라도, 혹은 사용법을 잘못쓸까봐서라도 테스트 코드 작성하는 것이 옳다고 본다.
  • RPC 모듈 제작하시면서 버그가 하나 나왔다고 하셨는데, 우연으로 테스트 통과…. 이말이 뭔지 이해가 안갔음.
  • 테스트의 종류를 성공해야 하는 테스트, 실패해야만 되는 잘못된 환경 테스트, 성공해야 하는 임계치 테스트로 분류해서 테스트 하셨음에도 우연이라 할만한 케이스가 있을까? 커버리지가 그만큼이 부족했던건 아닐까?

[김진욱] DVCS와 코드 리뷰. 그리고 자동화를 통한 쾌속 개발.

  • Rein이 이분인거 오늘 처음암.
  • Git 를 기반으로 각종 도구들을 통합하며, 테스트를 자동화하고 리뷰를 강제하는 개발 프로세스에 대한 설명이셨음.
  • 현재 우리팀과는 몇가지가 다른데, 리뷰 후에만 커밋된다는 점이 부러웠음. (나 개인적으로는 이걸 원하나, 여러가지 이유로 인해 선 커밋 후 리뷰 체제)
  • VM을 띄워 클린한 상태에서 테스트가 돈다는 점이 인상적이었다.
  • 이외에 운용하시면서 느낀 점과, 세팅된 현황등에 대한 디테일한 정리가 인상적이었음. 물론 리눅스 기반이라 알려주신 도구들을 그대로 우리팀에 적용은 좀 어려울듯.
  • 현재보다 코드 커버리지를 높이는 여러가지 방안을 고민중이었는데, 역시나 리뷰인가…라는 생각이 듬. (+ 리뷰 강제)

[김이선] 사례를 통해 살펴보는 프로파일링과 최적화 (http://www.slideshare.net/veblush/ss-19957544)

  • 명실공히 이날의 최고의 세션으로 손꼽고 싶다.
  • 내가 프로파일링 & 최적화에 관심이 많은편이며, 디버깅도 좋아하는 편이다보니 더더욱 그랬을지도?
  • 관심은 많으나, 어떻게 하면 좀 더 잘 최적화 할 수 있을까, 좀 더 잘 측정할 수 있을까, 통찰력을 높일 수 있을까 등에 대해 고민하던 시기에 아주 적절한 내용이 많았다.
  • 마비노기2, 던파, 에버플래닛 등에서의 실제 사례를 설명해주셨는데, 내공과 통찰력에 감탄을 금치 못했다.
  • 철저히 측정 기반으로 접근하신 점과, 그 개선에 대한 판단력 등에 박수를 보낸다.
  • 현재 우리 팀에서 하고 있는 핫스팟 찾기, 기준치 (base-line) 초과 기준 프로파일링과 접근에선 유사했으나, 목표 코드를 찾고 해결책을 찾는 과정을 바로 옆에서 보진 못했지만 아마도 보자마자 머릿속을 스치는 최적화 가능하겠다는 경험과 통찰이 가능해서 해냈던 최적화들이라는 느낌은 나만 받은 것은 아닐거라 본다.
  • Amd CodeAnalyst, VerySleepy 등의 툴에 대해 알게 된 것도 유용한 수확. 써먹자 써먹자!!

[김재석] 마비노기 영웅전 개발 테크니컬 포스트-모템

  • 아마 기존에 마영전 세션들은 워낙에 많았어서 (자이언트 서버의 비밀이라던지) 어느정도 개발 비화 스러운 이야기를 많이하셨음.
  • 잘한점 못한점 등을 나누어서 설명해주셨고, 당시의 상황들에 대한 이야기들은 애환이라던지 여러가지 공감대를 형성시키는데에 적절했다.
  • 서버 기준에서 잘 안된점은 자이언트 서버의 비밀에서 알려져있어서 색다르지 않았으나, TD관점에서의 잘된점/잘못한점에 대한 회고는 여러가지 생각이 들게 됐다.
  • 자이언트 서버의 비밀 때도 든 생각이지만, 이렇게 잘한점/못한점을 얘기할 수 있는 용기있는 세션이라는 점만으로도 충분히 멋졌다. 박수를 보낸다.

옆에 같이 보는 분도 계시고해서, 올해는 꼬치꼬치 공격적 질문은 안했습니다. =_= 해가 갈수록 그런 본능이 계속 줄고 있기도하고….

기타 몇개 세션을 더 들었으나…. 내 상태가 메롱해서 멍해서 필기 못한 세션에 대한 정리는 패스하는걸로…~ 여하튼 발표해주신 분들 모두 모두 수고많으셨습니다. 저도 내년에는 꼭 좋은 주제 준비해 발표하고 싶네요.  하지만 7개 세션이 한번에 진행된 점은 좀 아쉬웠습니다. 예전처럼 3개 세션씩 4일에 해주셨으면 하는 바램으로… 간략한 요약 마무리 합니다. 

데이터베이스 마이그레이션 with rails

참고 문서

한글 번역 아주 잘 되어 있군요.

Redmine도 루비를 쓰는 만큼, 같은 개념이라고 하네요. 

모델 생성시

rails generate model Product name:string description:text

독립적인 마이그레이션 만들기

rails generate migration AddPartNumberToProducts

특정 버전으로 Migrate

rake db:migrate VERSION=20080906120000

Rollback

rake db:rollback

간략하게 요약하자면 위와 같습니다.

독립적인 마이그레이션을 만들고 나면, db\migration 폴더 안에 현재 시간의 이름으로 된 rb 파일이 생성됩니다. 이 곳에 정의되어있는 up 메소드는 버전을 올릴때, down 메소드는 버전을 내릴 때 불려지는 메소드입니다.

이 과정을 통해서, 컬럼의 추가/삭제라던지, 인덱스의 추가/삭제 등의 버전별 기능을 유지할 수 있습니다.