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








2014년 11월 30일 일요일

프로그래머 철학을 만나다 - 도서 리뷰

오전 7:10 Posted by jonnung No comments
<프로그래머 철학을 만나다, 유석문 지음, 2014.08, 로드북>

 올해 여름이 끝나갈 무렵에 '유석문'님의 '라이엇 게임즈' 입사 후기를 읽어보고 참 멋지다라고 생각했었다. 그리고 때마침 기회가 되서 '유석문'님이 발표하는 세미나에 참석할 기회가 있었는데 미련하게도 날짜를 착각하는 바람에 다른 약속을 잡아버려서 결국 취소했다. 얼마나 아쉬웠던지...

 얼마전에 회사에서 운영하는 도서관에 신간 몇권이 들어왔는데 대여를 한 책이 '유석문'님이 쓰신 책이였다. 왠지모를 반가움! 
실제로 뵙지 못한 분을 책으로 뵙게 되니 예전에 아쉬움이 좀 달래지는 기분이였다.

 이 책에 대해 말하기 전에 잠시 내가 회사 생활을 하면서 마주쳤던 걱정과 고민에 대한 이야기를 해볼까 한다. 

 업무가 잘 안풀릴때나 사람 관계에서 발생하는 여러가지 문제들을 해결하기 위해 내 스스로 묻고 답을 구하려고 했던 노력들. 나름대로 수없이 많은 생각들로 해결책을 찾으려고 했지만, 결국 만족스러운 답을 찾지 못했을때 느끼는 스트레스로 자존감, 자신감에 흠집이 나기도 했었다.
 혼자하는 고민으로 해결하고자 하는게 과연 가능했던 걸까? 내안에 지배적인 생각은 세상 어디에도 나의 걱정을 해결하거나 도와줄 사람은 없다는 것이다.
하지만 그렇다고 계속 이렇게 살 수는 없지 않은가? 내가 찾은 대안은 책이였다. 책을 전혀 읽지 않는 편은 아니지만 내 입으로 자랑(?)스럽게 말할 정도로 많이 읽지는 않는다.

 난 자기 계발 서적을 좋아하는데 개발자라는 직군에 초점을 맞춰서 자기 성찰을 다루는 책은 그다지 많지 않은 것 같다. '나는 프로그래머다' 라는 책도 읽어 본 적이 있는데 선배 개발자분들의 개발 인생에서 겪은 노하우와 생각을 책을 통해 만나볼 수 있는 기회 였지만, 나에게 어떤 길을 제시하기 보다는 '난 이렇게 살았다' 정도의 인상만 남아있는 것 같다.

 이 책은 개발자들이 살아가면서 겪게 되는 비슷한 상황들에 대해 느끼게 되는 감정들에 대해 더 좋은 방향으로 나아갈 수 있는 해결책을 철학적인 관점에서 이야기 해준다.
이런 컨셉이 좋았다고 느낀 이유는 저자의 개인적인 경험을 통해서 '난 이런식으로 생각하고 행동했다'라는 것보다 철학자들이 평생에 걸쳐서 연구하고 도달하게 된 지혜를 바탕으로 방향을 제시하기 때문에 더 설득력 있게 느껴졌다. 

 책을 읽어가면서 중요하다고 생각했던 부분을 표시해 두었는데 아래 그 내용들을 정리해 보았다. 

 '자존감'을 높이기 위해서는 외부 환경에 영향을 받지 말고, 자신이 통제할 수 있는 영역에만 집중해야한다고 말한다. 회사내에서 겪을 수 있는 상사의 권위에 대한 실체와 올바른 권위란 무엇인가를 제안한다. 
외부 요인을 바꾸기 힘든 것은 누구나 알고 있다. 그렇다고 외부 요인에 맞춰 자신을 바꿔서는 안된다. 자신의 내면에 집중하고, 자신의 존재가치를 확고히 해야하며 외부의 통제 시도에 단호하게 저항할 수 있어야 한다.
 나 자신의 영향력을 확장하는 것은 외부를 지배하거나 통제하고자 얻는 것이 아니다. 올바른 영향력의 확장은 자신의 내면이 확고하고 올바르게 발전하여 외부에서 이를 인지하고 인정하는 것이다.
 실패를 두려워 할 필요가 없다. 실패라는 것은 끝이 아니며 삶의 과정이다. 받아들이고 직시하면서 그것을 통해 더 배우면 되는 것이다. 실패한 순간을 떠올리며 몸서리 치듯 자책하는 대신 잘했던 부분과 개선할 점을 찾아 실천해야 한다.

 '지속적인 발전'을 위해서는 좋은 습관을 만들고, '나쁜 습관'을 제거해야 한다. 그렇게 하기 위해서는 첫째 '목표 설정', 둘째 '동기 부여' 셋째는 '꾸준한 실천'이다. 내안에 철학을 정착시켜 자신이 개선되고 있다는 좋은 피드백을 받아 작은 성공을 만드는 것이 훌륭한 동기 부여가 될 것이다.

 가장 기억에 많이 남는 부분은 '화에 대하여'이다. 사실 나의 고민과 스트레스들은  '화'에서부터 시작된 것이라고 생각한다. '화'가 나를 지배하게 했기 때문에 어떠한 긍정적인 생각과 다짐들도 무력화되기 마련이다. 
 내 안에서 시작된 '화'는 내가 받은 질책과 항의가 그대로 흡수되어 진화한 것이다. 상대가 내비친 화의 원인을 파악하지 못하고 그대로 나 자신의 '화'가 되는 것이다. 
나의 '화'를 다룰수 있다면 상대방의 화를 조절할 방도가 없는 상태라고 하더라도 완화 시킬 수 있는 여유와 기회가 있을 것이다.

 그리고 미래를 예측하는 것에 대한 주의를 요구한다. 인간이 예측하는 미래는 현재를 기준으로 삼기 때문이다. 현재의 행복이 미래를 반영한다고 볼 수 없다. 행복한 현재를 살아가는 개발자가 되기 위해서는 함께 하는 사람들과의 조화로운 삶을 위한 노력이 필요하다. 두리뭉실하게 노력하자가 아니라 증명된 효과적인 방법론들을 접목해보자. ATDD(Acceptance Test Driven Development), TDD(Test Driven Development)는 저자가 가장 추천하는 방법중에 하나이다.

 마지막으로 '실천적인 지혜'를 쌓기를 바란다. 나 자신을 믿고 내 잠재력 위에 지적인 미덕을 쌓고, 이를 실천하며 도덕적인 미덕을 쌓아야 한다. 

 나는 내 주위에 함께 일하는 개발자분들이 이 책을 꼭 한번 읽어보기를 강력하게 추천한다. 내 자신이 좋은 영향을 받은 이유도 있고, 이 지혜를 함께 이해하고 느끼면서 살아가면 더 즐겁고 행복한 (개발) 인생을 살아갈 수 있지 않을까 생각한다.



2014년 10월 14일 화요일

코딩호러의 이펙티브 프로그래밍 - 도서 리뷰

오전 9:12 Posted by jonnung No comments
<코딩 호러의 이펙티브 프로그래밍, 제프 앳 우드 지음, 2013.03, 위키북스>

 작년(2013년)쯤에 이 책이 도서관에 비치된 것을 봤을 때만해도 제목 때문인지 뭔가 어려울 것 같은 느낌을 받았다. 지금 생각하면 조금 웃긴게 "코딩 호러"라고 하니 무시무시한 느낌도 나고, "이펙티브(Effective)"라고 하니 '그래..이펙티브 하게 해야겠지.. 그런데 지금 난 잘 못할 것 같아'라고 생각 했던 것 같다. (겁먹은 거겠지..)
아무튼 지금은 그게 중요한건 아닌 결국에 시간이 흘러서 내가 이 책을 펼치는 순간이 찾아왔다는 것이다.

 간략하게 책에 대한 소개를 하자면, 개발자라면 누구나(그치?) 알고 있고, 많은 도움을 얻고 있는 http://stackoverflow.com 을 만든 제프 앳우드 가 지은 에세이 형식의 개발담 + 인생 조언에 대한 내용이다.

 개발자라는 직군에 종사하는 사람들(= 우리 모두)에게 힐링과 자극을 줄 수 있는 내용들로 시작하는데 아래는 '1부_들어가며: 결국은 프로그래머가 되고 싶은 거로군'에 나오는 내용중 일부를 옮겨봤다.

"솔찍히 말해서 나는 사람들이 너무 많은 일을 벌이는 것보다는 자기가 진심으로 좋아하는 것이 무엇인지 발견하고, 그 대상을 집중적으로 파는 것이 좋다고 생각한다. 
인생에서 정말 어려운 일은 이론적으로만 유용한 무엇을 실제로 배우는 과정이 아니라 자기가 진짜로 좋아하는 것이 무엇인지 깨닫는 과정에 놓여 있기 때문이다. 
자기가 정말 좋아하는 것을 찾아가는 연구와 탐색의 과정이 자신을 마침내 코딩으로 이끌었다면, 나의 축복을 받으며 코딩을 하기 바란다."

 프로그래머로써 살아가면서 한번쯤은 해봤을 법한 갈등과 고뇌들. 저자도 똑같이 느꼈기 때문에 이렇게 말해 줄 수 있지 않을까 싶다. 나는 개인적으로 저 말에 많은 용기와 힘을 얻었다.
이렇게 초반부터 감동을 받으니 평소 같으면 꾸벅꾸벅 졸기 바쁜 왕복 3시간의 출퇴근 시간에도 계속 책을 찾게 되었나 보다.

 그런데 300페이지 정도 이후 부터는 솔찍히 좀 지루했다. 처음에는 내 집중력을 탓하기도 하고, 그것이 지속되니 번역하신 분(임백준님..ㅎㄷㄷ)을 의심하기도 했지만 결론적으로는 내 관심사의 문제였던거 같다.
초중반의 stackoverflow의 개발담들이 사실 더 재밌던거지모..

 한줄 서평으로 마무리 하자면..

"재밌다. 그리고 출퇴근 지하철에서 읽으면 표지 덕분에 눈길을 끌 수 있다"


2014년 10월 12일 일요일

파이썬 소켓(socket) 모듈을 사용한 네트워크 프로그래밍 - Python 도서 리뷰

오전 1:49 Posted by jonnung , 8 comments


네트워크 프로그래밍(2/2)

 이전 포스트에서 '클라이언트/서버 아키텍처와 소켓 (socket)' 부분에 대해 정리했다. 이번에는 이 개념을 파이썬에 도입해서 프로그램을 작성 해보자.

일단 책에 나오는 TCP 서버/클라이언트, UDP 서버/클라이언트를 예제를 통해서 주로 사용하는 socket 모듈에 대한 구조를 파악해봤고, 이번에는 연습문제 중에 하나인 '전이중(full-duplex) 채팅 프로그램'을 만들어 보겠다.

책에는 나오지 않지만 검색을 해보던 중에 소켓 프로그램의 주요 이슈중 하나인 블럭킹(Blocking)에 대해 알게 되었는데 블럭킹을 해결하기 위한 방법중에 하나인 select 모듈을 채팅 프로그램에 적용해 보았다.

소스코드를 살펴 보기 전에 당연히 이 블럭킹(Blocking) 이라는 녀석이 무엇인지 살펴 보는 것이 순서겠다.


블럭킹(Blocking)

 어떤 일이 일어나기를 기다리면서 멍하니 있는 상태를 말한다. 예를 들어 소켓 서버에서 recv() 를 호출해 놓고, 클라이언트가 보내는 데이터를 기다리는 경우, 소켓 서버는 읽기 상태에서 블럭킹 되어 있다고 말한다고 한다.
 서버나 클라이언트나 차례대로 서로 데이터를 주고 받으면 이것은 크게 문제가 되지 않는다. 하지만 만약 서로가 데이터를 주기를 기다리는 상태가 된다면 어떻게 될까?

 이런 블럭킹 상태를 피하는것이 가장 좋겠지만, 그렇지 못할 수도 있기 때문에 일정 시간 이후 타임아웃이 걸려서 이 상태를 벗어나는 것도 좋은 방법이 될 수 있다.

그래서 채팅 프로그램 예제에서는 이 블럭킹 문제를 해결하기 위해 select 모듈을 사용한 것이다.
현재 수준에서 select 모듈을 더 파보는 것은 조금 무리가 있기 때문에 간단한 사용법만 익혀서 바로 적용했다. 하하;;


TCP 서버/클라이언트 채팅 프로그램

일단 전체 소스코드는 아래와 같다. 

상대적으로 클라이언트(tcpChatClient.py)가 쉽다(?)고 느껴지기 때문에 공을 더 들인 부분은 서버측 스크립트(tcpChatServer.py) 이다.

select 모 듈의 select 메소드는 양쪽 모두에서 사용되었다. 네번째 인자로 전달된 값이 '블럭킹' 단락에서 언급한 그 타임아웃 시간이다. 
10초라는 의미의 값을 전달 했기 때문에 읽어 들일 객체(첫번째 인자에 리스트 형태로 전달한 소켓들)가 없으면 비어있는 리스트를 반환한다.

38 ~39번 라인의 # 새로운 접속 부분에서 select() 가 반환한 read_socket 리스트의 값중에 서버소켓(serverSocket)과  같은 객체를 체크해서 새로운 접속인지를 판단한다.
하지만 아직 서버는 클라이언트의 연결이 받아들여진 상태는 아니다. listen() 메소드에서 일단 클라이언트의 접속이 되면, accept() 를 호출해서 별도의 소켓에 넘겨주고 통신을 진행하는 방식이 TCP 통신의 특징이고 UDP 와의 큰 차이인 것이다.

프로그램을 종료 하려면 강제로 종료시키는 방법 밖에 없는데 이때 KeyboardInterrupt 예외가 발생한다.
연습 삼아 만든 프로그램이지만 보기 안좋은 부분을 보완하기 위해서 try ~ except로 예외를 잡아 소켓을 닫고, 프로그램을 종료 시켰다. (책에서는 이 부분에 대한 코드는 없지만 '부드럽게 종료하기' 라는 참고사항으로 권장하고 있다.)


참 고

클라이언트/서버 아키텍처와 소켓(Socket) - Python 도서 리뷰

오전 12:46 Posted by jonnung , No comments




네트워크 프로그래밍(1/2)



'코어 파이썬 애플리케이션 프로그래밍' 의 두번째 챕터 '네트워크 프로그래밍'에 대한 리뷰 형식의 포스트 이다.
이번 챕터에서는 네트워크 프로그래밍의 배경 지식과 파이썬에서의 소켓(Socket)을 사용하는 방법을 설명하고 있다.


클라이언트/서버 아키텍처

  • 클라이언트/서버 아키텍처의 전제는 하드웨어일 수도, 소프트웨어일 수도 있는 서버가 하나 이상의 클라이언트(사용자)에게 '서비스'를 제공한다는 점
  • 서버의 존재 목적은 (클라이언트의) 요청을 기다리다가 클라이언트의 요청에 응답 후 다시 다른 요청을 기다리는 것
  • 2가지 형태의 클라이언트/서버 아키텍처를 소개하고 있다.
    1. 하드웨어 클라이언트/서버 아키텍처
    2. 소프트웨어 클라이언트/서버 아키텍처
  • 네트워크 프로그래밍은 서버가 클라이언트의 요청에 응답하려면 설정 과정이 필요하고, 통신 종단점(communication endpoint)은 서버가 요청을 리슨(listen)하기 위해 만들어지고 무한 루프에 들어가서 연결해 오는 클라이언트를 기다린다.
    그리고 클라이언트는 자신의 통신 종단점을 만든 후 서버에 연결해야 한다.

소켓

소켓은 '통신 종단점'이라는 개념을 구체화한 컴퓨터 네트워크 데이터 구조이다.
네트워크를 사용하는 애플리케이션은 통신을 시작하기 전에 항상 소켓을 만들어야 한다.
소켓 없이는 통신을 시작할 수 없기 때문이다.
원래 소켓은 실행중인 프로그램(프로세스)이 같은 호스트안에 실행 중인 다른 프로그램과 통신하기 위해 깨발 되었다고 한다.

소켓의 유형

  1. 유닉스 소켓
    • AF_UNIX 라는 '패밀리 이름' 을 가진다. AF는 주소 패밀리(Address family)를 의미.
    • 쉽게 클라이언트와 서버가 유닉스 환경의 동일한 컴퓨터에 존재해야 한다는 뜻.
    • 이 소켓은 파일 기반이다. 소켓의 기반 구조가 파일 시스템을 통해 지원된다는 것이다.
    • 파일 시스템은 같은 호스트에서 실행 중인 프로세스 사이에 지속적으로 공유되므로, 합리적인 방법이라고 할 수 있다.
  2. 네트워크 기반
    • 패밀리 이름은 AF_INET 이다.
    • 클라이언트와 서버가 인터넷 어디서든 존재할 수 있다는 의미를 갖는다.
파이썬은 AF_UNIX, AF_NETLINK, AF_TIPC, AF_INET{,6} 패밀리를 지원한다.

연결 방식에 따른 소켓의 종류

  1. 연결 지향 소켓(connection oriented)
    • 통신을 하기 전에 반드시 연결 돼 있어야 한다(전화를 거는 것과 유사)
    • 레코드 경계 없이 데이터를 순서대로 신뢰성 있게 중복없이 전달. 각 메세지는 여러 조각으로 나뉘어서 반대편에 확실히 전달된 다음에 다시 순서대로 한데 묶인 후 기다리는 애플리케이션에 전달
    • 연결 지향 소켓을 구현한 프로토콜(protocol)로는 전송 제어 프로토콜(TCP, Trasmission Control Protocol) 이 있으며, 이 소켓을 만드려면 소켓 유형으로 SOCK_STREAM(스트림 소켓)을 지정
    • 이 소켓은 네트워크상에서 IP를 호스트를 찾기 위해 사용하기 때문에 두 프로토콜의 이름을 붙여 TCP/IP 라고 함.
  2. 비연결형 소켓(connectionless)
    • 스트림 소켓과 대비되는 데이터그램(Datagram) 유형의 비연결 소켓
    • 통신 시 최초 연결하는 과정이 필요 없음
    • 데이터 전달 과정에서 순서나 신뢰성 이나 중복 방지를 보장할 수 없음. 이는 메세지가 연결 지향 소켓처럼 조각으로 나뉘지 않고 통째로 송신된다는 것을 의미(우편 서비스에 비유)
    • 연결 지향 소켓은 가상 회선을 맨 처음 만들고 유지하기 위해 상당한 부가 비용이 드는데 비연결 지향 소켓은 이런 부담이 덜하고 성능면에서 더 좋다.
    • 데이터그램 소켓을 구현한 프로토콜로는 데이터그램 프로토콜(UDP, User Datagram Protocol)이 있고, UPD 소켓을 만들려면 SOCK_DGRAM을 소켓 유형으로 지정.
    • 이 소켓도 IP를 네트워크상에서 호스트를 찾기 위해 사용하므로, UPD/IP라고도 부름





2014년 9월 21일 일요일

파이썬의 정규식(re) - Python 도서 리뷰

오전 9:02 Posted by jonnung , 1 comment

추석전에 연휴기간에 볼 책을 빌리러 도서관에 갔다가 신간으로 들어온 책을 1빠로 득했다. 
최초 번역판일 것 같아서 빌리지말까 하다가 읽어보니까 번역이 상당히 잘 되어 있는 것 같은 느낌이다. 아 그리고 이미 예전에 '코어 파이썬 프로그래밍' 이라는 책에서 '응용' 부분만 좀 더 확장했다는 것 같다.

그런데 반납일까지 1주일 남았는데 1챕터밖에 못봤다. ㅠ_ㅠ  어짜피 사려고 했으니까 뭐;;;
(페이지랑 가격이 좀 후덜덜;;; 하긴 함)

아무래도 파이썬에 대한 책이고, 실습(실행 > 확인) 위주로 공부를 하다보니까 IPython notebook 이 딱 일것 같다.

첫번째 정규식 챕터, 리뷰 보러가기


Python - 클로저(Closure) 쉽게 생각하기

오전 8:28 Posted by jonnung 1 comment


함수 안에 다른 함수가 정의된 함수를 중첩 함수(Nested Function) 이라고 한다.
중첩 함수는 자신을 감싸고 있는 함수가 가진 변수에 접근 할 수 있다. 이건 자바스크립트(Javascript)도 동일한 특성이다. 

일단 간단한 예제 코드를 살펴보자.
#-*- coding: utf-8 -*-
 
def print_hello(msg):
    def inner_print():
         # nonlocal msg  # python3.x에만 있는 키워드
        print('Hello %s' % msg)
    return inner_print
 
printer = print_hello('jonnung')

printer()  # Hello jonnung

print_hello() 함수는 'jonnung'을 전달 받아 호출 되었고, 반환된 inner_print함수는 printer 변수에 할당 되었다.
printer() 함수의 실행 결과로 출력되는 값으로 알 수 있는 사실은 print_hello()의 실행이 종료 되었더라도 전달된 값(msg)이 기억되고 있는 것을 알 수 있다.

이러한 코드를 파이썬에서는 클로저(Closure)라고 한다.
그리고 감싸는 함수 안에 변수는 현재 네임스페이스상에서 함수가 삭제되더라도 사라지지 않는다.
del print_hello
 
printer()  # Hello jonnung

결국 중첩 함수가 감싸진 영역안에 변수를 참조할때 클로저를 갖는다고 할 수 있다.

그럼 이제 파이썬에서 클로저를 만들기 위한 조건을 정리해보자.
  • 중첩 함수(Nested Function)를 갖는다.
  • 중첩 함수는 자신을 감싸고 있는 함수 영역(부모함수)의 변수를 참조하고 있다.
  • 부모함수는 중첩 함수(자식 함수)를 반환한다.
여기서 한가지 물음이 생길 수 있겠다. 그렇다면 클로저는 언제 사용해야 할까?
클로저는 전역 변수를 사용하지 않기 위함과 내부 데이터에 대한 은닉을 위해서 활용할 수 있겠다.
그리고 객체지향에 대한 문제점의 해결책이 될 수 있다. 적은 메소드(대부분 1개?)를 갖는 클래스에 대한 대체로 클로저를 활용한 코드는 좀 더 우아한 방법이 될 수도 있다고 한다. 

위 샘플 코드의 실행 결과와 추가적인 예제는 아래 IPython Notebook에서 자세히 확인 할 수 있다.



2014년 9월 16일 화요일

gae-init (약간) 사용 후기, 구글 앱 엔진(Google App Engine) 웹 어플리케이션 빠르게 시작하기

오전 6:53 Posted by jonnung , , , , , No comments

gae-init 은 Google App Engine에 웹 어플리케이션을 좀 더 쉽게 시작하기 위한 프로젝트 이다. 
일반적인 웹 어플리케이션 개발에서 수행하는 공통적인 작업들(파일 구조를 잡고, 최신 라이브러리를 다운로드 받고, 이전 프로젝트에서 개발한 코드 조각들을 모으는 등)을 자동으로 세팅 할 수 있도록 도와준다.
개발자는 더이상 시간 낭비 하지 않고, 좀 더 어렵고 중요한 작업에 집중할 수 있는 것이다.

공식 문서에서 제공하는 튜토리얼(Tutorial) 에서는 gae-init을 사용해서 개발, 빌드, 실행 그리고 배포까지 다루는 phonebook 예제(데모 보기)를 다루고 있다.

gae-init을 사용하기 위해서는 당연히 python이 있어야 한다.(GAE는 아직 python2.7만 지원함)
그리고 Node.js / Git / pip, virtualenv가 필수적으로 있어야 한다.
설치는 gae-init git 저장소를 clone 받으면 간단하게 시작 할 수 있다. 그리고  run.py -s  를 실행하면 venv(python 가상 환경)과 bower_components, node_modules을 자동으로 세팅하고, Flask로 만든 간단한 구조의 어플리케이션이 GAE SDK에서 제공하는 개발 서버를 통해 실행된다.

튜토리얼의 대부분의 내용은 기본적인 gae-init 세팅 구조에 phonebook 앱의 연락처 기능을 만드는 방법을 자세하게 다루고 있다. 

일단 난 튜토리얼을 다 따라해보지는 않았다. (이미 해 본 내용이기도 하고..)
사실 gae-init 이 세팅하는 구조가 내 입맛에 딱 맞지는 않았다.
그리고 난 거의 pycharm으로 개발을 하니까 개발 서버 실행을 위해 run.py 을 실행 할 일은 없겠지만, 그래도 run.py 파일을 보니까 나중에 참고해 볼만한 코드가 상당히 많았다.
Flask 어플리케이션 코드가 위치한 main 디렉토리도 커스터마이징해서 사용하면 될 것 같다.


(와아~ 어디서 run.py를 실행했는지도 수집하네ㅋㅋㅋ)