2014년 12월 21일 일요일

OS X 에서 Postgresql 설치하는 두가지 방법

오전 7:49 Posted by jonnung No comments

개발할때는 내 로컬환경에 데이터베이스를 사용하고 싶어서 Postgresql을 설치해 보았다.
방법은 찾아보면 여러가지가 있겠지만 맥 사용자라면 대부분 Homebrew로 패키지들을 설치하니까 일단은 Homebrew로 Postgresql을 설치했다.
그런데 지금은? 지웠다. ㅋㅋㅋ (이유가 뭘까?)

일단 내가 진행한 Homebrew 설치 과정을 간단하게 정리하자면 아래와 같다.
# Homebrew 업데이트
$ brew update

# Postgresql 설치
$ brew install postgresql

# 데이터베이스 생성(솔직히 이거 왜 하는지 모르겠다.)
$ initdb /usr/local/var/postgres -E utf8

# 서버 띄우기
$ pg_ctl -D /usr/local/var/postgres start

# postgresql 서버 내리기
pg_ctl -D /usr/local/var/postgres stop -s -m fast

특별히 중간에 잘 안되던 부분도 없었고 순조로웠다. 문제(?)는 아래 구문을 적용 하면서부터 였는데 사실 모르고 일단 했다가 본격적으로 삽질을 시작하게 되었다.
$ cp /usr/local/Cellar/postgresql/9.4.0/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
$ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

저 뒤로부터 계속 postgresql이 종료되지 않는 것이다.(stop) 직접 pid를 kill 해봐도 새로운 프로세스가 계속 생성 되었다. '_')a
그뒤로 계속 조사를 해보니 launchctl이 리눅스 crontab처럼 스케줄 작업 프로그램이고 이녀석이 자꾸 postgresql을 실행하는 것 같았다. 
그리고나서 가만히 생각해보니 launchctl에 등록된 상태로 항상 postgresql이 실행되고 있는 것도 낭비고, 그렇다고 빼자니 매번 pg_ctl로 시작했다가 종료하는 과정도 불편한 것 같았다.

그런데 또 한가지 방법인 Postgresql.app을 설치 해보니 고민거리가 말끔히 해결 되었다.
Postgresql.app을 다운 받아서 그대로 Application에 넣고 실행하면 앱 자체에 포함되어 있는 postgresql이 실행되고, 터미널에서 psql을 입력하면 바로 접속할 수도 있었다.
할일을 모두 마치면 그저 앱을 종료하면 되는 것이다.

2014년 12월 18일 목요일

Python으로 좀비 프로세스 만들어보기

오후 4:40 Posted by jonnung No comments
원래는 좀비/고아 프로세스만 찾아서 kill 하는 것만 하려고 했으나, 조사를 좀 해보니까 좀비프로세스가 시스템 자원을 그렇게 대놓고 차지하는 것은 아니더라..
프로세스 제어블록을 차지하는 것이기 때문에 엄청나게 폭발적으로 생기는 좀비가 아니고서야 큰 영향은 없다고 싶었다. 

좀비 프로세스가 생기는 원인은 부모 프로세스가 자식 프로세스의 종료 코드를 받지 않고, 무한히 대기하는 상태이다. 한마디로 자식이 좀비가 되도 부모는 종료된 상황이 아닌 것이라는 말이지!
(고아 프로세스는 자식이 끝나지도 않았는데 부모가 끝나버려서 자식이 고아가 된 경우를 말함)

아무튼 확인을 해보기 위해서 좀비프로세스 발생시키는 스크립트를 하나 만들어 보았다.

subprocess 모듈의 Popen() 함수로 자식 프로세스를 하나 띄우고, 자식 프로세스가 끝나는걸 기다리지 않고 부모가 계속 무한루프를 돌도록 했다.

이 상태에서 "ps aux | grep ' Z' | grep -v grep" 를 실행해보면  상태값이 'Z'인 프로세스를 하나 발견할 수 있는데 이게 좀비 프로세스이다. 

부모를 죽이면 이 좀비프로세스도 사라진다. 

2014년 12월 5일 금요일

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기 - 도서 리뷰

오후 10:51 Posted by jonnung No comments
<코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기, 제프 앳 우드 지음, 2012.11, 위키북스>


 코딩 호러의 두번째 시리즈이다. 지난 번에 '코딩 호러의 이펙티브 프로그래밍'을 너무 재밌게 읽어서 바로 이어서 읽어보았다.
 이 책도 코딩 호러에 실린 재밌는 글들을 모아 놓은 것인데 1편보다 훨씬 흥미로운 이야기들이 많다.  개인적인 생각이지만 현업에서 겪게 되는 상황들과 느끼는 고민거리들과도 더 잘 맞아 떨어지는 내용들이 많다.
 그러다보니 책을 읽다보면 제프 형(이제 형이다.ㅋㅋ)이 나를 위해 좋은 말씀을 해준다는 느낌을 받게 되는듯 했다.

아래에는 두고 두고 보면서 마음속에 새겨두면 좋을 만한 내용을 옮겨 보았다.


p.38
 실패는 놀라운 선생님이다. 그렇지만 일부러 실패를 찾아다닐 필요는 없다. 그것이 당신을 찾아올 것이다. 어떤 프로젝트에 참여하든 그것을 당신의 기술을 연마하고 새로운 것을 배우는 기회로 삼아라. 그렇게 하는데는 그럴만한 가치가 있기 때문이다. 프로젝트라는 여행은 그 여행의 끝에 어떤 결과가 기다리고 있는가에 상관없이 그 자체로 보상이 될 것이다.

p.39
전문가가 된다는 것은 다른 사람에게 자기가 아는 것을 말하는 것이 아니다. 그것은 바로 어떤 질문을 할지 아는 것, 자신의 지식을 주어진 특정한 상황에서 어떻게 적용할지 아는 것을 의미한다. 전문가가 된다는 것은 합리적이고 상황에 매우 적절한 방향을 제시할 수 있음을 의미하다. 
  • 연습하라, 연습하라, 연습하라!
  • 경험과 전문성을 혼동하지 말라.
  • 민간풍습을 믿지 말라. 하지만 그것을 배우기는 해라.
  • 아무것도 절대적으로 믿지 말라. 자신만의 방법론을 세워야 한다.
  • 자가 학습을 주도하라. 아무도 대신 해주지 않는다.
  • 명성 = 돈. 스스로의 명성을 구축하고 보호하라.
  • 자원, 자료, 도구를 끊임없이 확보하라.
  • 자신만의 기준과 도덕률을 확립하라.
  • 장인적 기술을 사소한 것으로 만드는 자격증을 피하라.
  • 항상 노력하는 동료를 곁에 둬라.
  • 쓰고, 말하고, 항상 자신이 보기에 진실인 것만을 발언하라.
p.59
반복의 속도가 반복의 질보다 우선한다. (보이드의 반복 법칙)
이와 동일한 의미의 법칙이 현대 소프트웨어 공학의 원리에도 적용된다는 사실을 알 수 있다.
  • 단위 테스트는 작고 빨라서 모든 빌드 과정에서 실행될 수 있어야 한다.
  • 사용성 테스트는 2주마다 작은 변화를 줘서 제대로 작동하지 않을 것을 바로바로 없앨 수 있을때 가장 효과적이다.
  • 대부분의 애자일 방법론에서는 4주보다 길지 않은 반복주기를 권장한다.
  • 소프트웨어 테스트는 빨리 그리고 자주 실패하는 것이 핵심이다.
  • 기능에 대한 명세는 간결하고 차츰 진호하는 방식으로 작성하는 것이 가장 좋다.
p.70
 코딩에 대한 열정은 경이로운 일이다. 하지만 이미 자기가 충분한 능력을 가지고 있다는 사실을 여러 차례에 걸쳐 증명한 기술에 대해 계속 아무 생각 없이 반사적으로 파고드는 경우가 너무나도 많다. 진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟아야 한다.

p.105
 혼자서 일하는 방식으로는 얼마 가지 못한다. 다른 영리한 프로그래머를 곁에 두도록 노력하라. 그들과 함께 일하라. 사무실 안에서 가장 멍청한 존재가 되려고 노력하라. 그렇게 하면 소프트웨어 개발이라는 것이 대부분의 사람들이 생각하는 것보다 훨씬 더 사회적인 활동이라는 사실을 깨닫게 될 것이다. 내성적인 동료들에게서 배울 수 있는 것이 너무나도 많다.

p.129
 먼저 단순한 것들을 디자인한 다음, 필요하면 더 큰 공간으로 옮겨가라. 복잡한 것을 먼저 만들고 작은 곳으로 옮겨가는 것은 잘못된 접근법이다.

p.133
 프로그래머로서 우리들이 도를 넘어서 영리해지는 것을 경계해야 한다는 점이다. 우리는 가능하면 최대한 다른 사람들이 하는 것과 똑같은 방식을 고수하려고 노력해야 한다. 왜냐고? 당신이 작성한 코드라고 해서 영원히 당신만 작업하리라는 보장은 없기 때문이다. 

p.145
코딩을 하는가? 그건 쉬운 일이다. 당신이 만드는 애플리케이션을 사용자의 손에 쥐어주고 그들이 사용하고 싶게 만드는 것. 그게 진짜 어려운 부분이다.

"스티브크룩의 사용성 평가, 이렇게 하라!"

p.169
  • 이걸 어떻게 테스트하지?
  • 어떤 종류의 테스트를 수행해야 하지?
  • 공통적이고, 기대되는 결과는 무엇이지?
  • 흔하지 않지만 발생 가능한 결과는 무엇이지?
  • 이 코드에는 외부 의존성(extnal dependency)이 얼마나 있지?
  • 어떤 종류의 시스템 오류를 야기할 수 있지?
단위 테스트는 프로그램이 올바르게 동작하는 것을 보장해주지 않는다. 그런 기대를 하는 것은 합리적이지 않다. 하지만 단위 테스트를 작성하는 것은 개발자가, 아무리 간단하게라도 앞에 나열한 것 같이 테스트와 관련된 어려운 질문을 스스로 고민하도록 만드는 것은 보장한다. 이것은 확실히 옮은 방향으로 나가는 일보 전진이다.

p.179
 책임감 있게 실행되는 소프트웨어를 만드는 프로젝트라면 맨 먼저 해야 하는 일이 예외와 에러를 보고하는 장치를 만드는 것이다.

p.203
 프로그래밍은 재미있다. 그것은 발견하는 기쁨으로 가득하다. 창조의 기쁨과 성취감으로 그득하다. 배우는 즐거움도 있다. 자신의 손으로 만든 무엇이 화면 위에서 동작하는 것을 지켜보는 즐거움도 있다.
옆에서 일하는 동료가 자기가 작성한 코드를 보고 감탄하는 것을 바라보는 기쁨도 있다. 자신이 만든 것을 사람들이 이용하는 것을 바라보드는 즐거움도 있다. 자신 작품을 대중이 사용하고, 이웃이 사용하고, 언론에서 다루는 것을 보는 쾌감도 있다. 
프로그래밍은 반드시 즐거운 것이어야 한다며, 만약 그렇지 않다면 그것을 즐겁지 않게 만드는 것이 무엇인지 알아내서 고쳐야 한다. 
나는 종종 제품을 출시하는 것이 마치 누군가 당신을 때리는 것을 멈추는 것처럼 좋은 기분을 전달해 준다고 말했왔다. 당신의 업무는 이 제품을 완성하고, 보그를 수정하고, 출시하는 것이다. 버그를 수정해야 한다면, 수정하라. 문서를 작성해야 한다면, 작성하라. 코드를 테스트할 필요가 있다면, 테스트하라. 이런 모든 것들은 출시를 구성하는 요소이다. 당신은 프로그래밍 자체를 위해 고용된 것이 아니라, 출시를 위해 고용된 것이다. 자기 업무에 충실하라. 

p.218
 나는 이미 존재하는 것을 되풀이해서 개발하는 것을 지지한다. 학습을 위한 최선의 방법이기 때문이다. 하지만 이미 존재하는 대상의 모든 측면을 철저하게 연구한 다음 그것을 다시 개발해야 하는 이유를 입증하기 전까지는 그렇게 하지 말아야 한다. 즉 철저한 연구라는 숙제를 먼저 해야 하는 것이다.