최근에 서버가 사망하는 일이 발생했습니다. 내 다시는 LVM 에 데이터랑 OS 를 공존시키지 않으리란 다짐을 하게 만드는 사건이였습니다. 인프라를 다시 갖추는 작업을 한번쯤 정리해 볼 필요가 있을 것 같아서 정리해봤습니다. 

12.04 LTS 버젼으로 설치해 주는 것이 편합니다. 12.10 버젼은 Remote Desktop 으로 접속시 D 를 누르면 발생하는 문제가 있습니다. (모든 창이 미니마이즈 가 됩니다)

설치하자 마자 접속하면 '소프트웨어 업데이트'가 뜹니다. 이때 '설정'을 눌러서 다운로드 받는 서버를 'ftp.daum.net' 으로 수정해 줍니다. 

 $ sudo apt-get install ssh 


shell 접속이 가능하게 ssh 관련 소프트웨어를 설치해 줍니다. 특정 망회사는 ssh 기본 포트를 막아놓는 테러를 저지르기 때문에 /etc/ssh/sshd_config 에서 port 를 바꾸어 줍니다. 

$ sudo apt-get install xrdp


원격 접속이 가능하도록 xrdp 관련 소프트웨어를 설치해 줍니다. 

$ sudo apt-get install emacs23-nox 


주로 shell 로 접속해서 쓸꺼기 때문에 emacs 를 nox 버젼으로 설치해 줍니다. 

 $ sudo apt-get install gnome-session


원격 데스크탑을 원활히 돌리기 위해서 놈-세션을 설치해 줍니다. 
원격 데스크탑이 잘 돌아갈 수 있도록 조치를 취해줍니다.  예전에 올려둔 포스트 참조 

이제 쓸데 없는 하드들을 전부 한개로 묶어서 데이터 디스크를 만들어 줍니다. LVM 을 활용하는 것입니다. 
예전에 정리해 뒀습니다. 

 

 $ sudo vgchange -a n data_vg
 $ sudo vgreduce --removemissing data_vg
 $ sudo vgchange -a n data_vg
 $ sudo vgremove data_vg


LVM 을 운용하는 중에 하드가 하나 날라가 버린 가슴 아픈 사람들 (저 같은 경우..)의 경우에는 그 부분을 제거해 줘야 합니다. 이거를 먼저 실행해주고 LVM 을 생성해 주면 됩니다. 
(다시는 OS 와 Data 를 LVM 으로 묶지 않으리란 다짐을 했습니다. )

이제 다시 git 레파지토리를 생성해주면 됩니다. 제 노트북에 로컬 레파지토리는 전부 남아 있으니 서버에서 재 구성해주고 이쪽에서 그쪽으로 push 만 해주면 될 듯합니다. 

예전 정리 참조 

이렇게 또 퇴근 후 자유시간을 잡아먹게 되는 군요. 
저작자표시

'계획-구현'(plan-and-implement) 방법론은 댐을 건설한다던가 국가를 침공하는데에는 훌륭한 방법이 될 수 있지만, 경험상 프로그래밍을 하는데는 좋은 방법론 같지는 않다. 

어째서? 

아마도 컴퓨터가 너무나 엄격하기 때문일 듯 싶다. 각각의 프로그램들간의 차이가 댐들이나 침공들 끼리의 차이보다 더 심하기 때문일 듯 싶다. 또는 아마도 여분을 남기는 것과 같은 오래된 행태는 소프트웨어 개발에서는 없기 때문에 옛날 방법론은 먹히지 않는다: 댐 건설시 30% 의 콘크리트를 더 가지고 있는 것은 실수에 대비한 방법이지만, 프로그램에서 30% 더 일을 한다는 것은 명백한 실수다. 

왜 오래된 방법론들이 실패했는지 말하기는 어려울 수도 있다. 하지만 그 방법론들은 명백히 실패했다. 누구나 실패한 것을 보지 않았는가? 언제 소프트웨어가 제때 개발되었는가? 경험 많은 프로그래머들은 아무리 조심스럽게 프로그램을 계획한다고 해도 막상 프로그램을 만들 때 계획은 예기치 못한 방향으로 바꿔버린다는 것을 알고 있다. 더구나 때때로 계획이란 것은 말도 안되게 잘못되어 버린다. 그러나 '계획-구현'(plan-and-implement) 방법론의 희생자중 극소수만이 기본적인 적합성에 의문을 가진다. 대신에 대부분의 사람들은 사람의 실수를 비난한다: 만약 계획이 더 많은 예측을 바탕으로 만들어 졌다면 이런 모든 문제들은 다 피해갈 수 있었을텐데.. 아무리 최고의 프로그래머라 할 지라도 '구현'단계로 접어들면 문제에 봉착한다. 아마도 사람들에게 그 이상으로 더 예측을 하라는 것은 너무 많은 기대를 가지는 것일 지도 모른다. '계획-구현'(plan-and-implement) 방법론은 우리의 한계에 더 잘 맞는 방법론으로 바꿔야 할지 모른다. 


폴 그레이엄의 Onlisp 책에서 언급되는 내용입니다. 이 책이 쓰여질 당시에 저는 졸업도 하기 전이였는데도 '계획-구현' 방법론을 옛날 방법론으로 치부하고 있습니다. 그 뒤로 애자일이니 래피드니 수많은 방법론들이 나왔지만 현실속에서 적용하기가 얼마나 쉬웠습니까? 석학들이 해외에서 95년도 쯤에도 이미 워터폴이니 뭐니 하는 소프트웨어 공학의 방법론들이 건설회사 방식에서 차용됐기 때문에 소프트웨어 개발에는 알맞지 않다고 이야기 해왔지만 습관이 참으로 무섭다는 생각이 듭니다. (10여년간 옛날 방식으로 꾸준히 개발되어 왔다는 이야기..) 

지금도 국내 굴지의 대기업과 개발을 진행하고 있는데, 개발 방향을 정하는 회의가 잡혔습니다. 이제 거기서 개발 진행이 결정되면 변경사항이 있을 수도 있을 것입니다. 그러나 이미 개발은 완료를 향해 나아가고 있습니다. 얼마나 세세한 계획을 요구하는지는 대기업 SI 회사들과 일해 보신 분들이라면 누구나 공감하실 것입니다. 하지만 그 시간에 개발에 총 집중을 한다면 또한 얼마만큼 빠르게 개발을 진행할 수 있는지도 잘 아실 것입니다. 

이제 진정한 소프트웨어 개발 방법론이 필요할 때라 생각합니다. 폴 그레이엄이 평소에도 계속 주장하듯이 'Bottom-Up' 방식도 또 하나의 대안이 될 수 있으며, 이 새로운 방법론에 대한 가능성은 소프트웨어를 개발하는 방법의 수만큼 많으리라 봅니다. 

저작자표시
후배가 준 펜티엄 4에 우분투 32비트 버젼을 설치해서 잘 사용하고 있던 서버가 사망했습니다. 몇가지 이유가 있겠지만 자세한 이유는 잘 모르고, 나타난 현상으로 추론해 볼 수는 있습니다. 

SATA 1번 포트가 맛이 갔습니다. 2번 포트로 (이걸 포트라고 하는게 맞는 건지 잘 모르겠지만..) 바꿔서 하드를 달면 문제 없이 돌아가지만 SATA 1번에서는 하드를 인식 못하는 문제가 있습니다.

-> 즉 보드가 맛이 갔다. (정확히는 보드의 특정 부분이 ㅎㅎ)

하드 IDE Secondary SLAVE 가 맛이 갔다. 어떤 방식으로 어떻게든 꼽아도 인식을 못하더군요. 그렇게 그는 가버렸습니다. ㅜ.ㅜ



물론 사양도 안 좋은 컴퓨터에 정말 무리하게 많은 일을 시키면서 혹사시키긴 했지만 이리도 빨리 운명할 줄은 몰랐습니다.

역시 미디어 서버로 만들어서 토렌트를 열라게 돌린게 서버 사망의 가장 큰 이유가 아닌가 싶지만..

게다가  LVM 으로 모든 하드를 묶어서 한개의 하드로 만들어서 OS 건 데이터건 한 로지컬 파티션에서 돌렸던 문제도 발생했습니다. 데이터 파트가 고장이 나도 OS 도 같이 맛이 가는 문제가 발생하는 것입니다. 이것은 좀 큰 문제더군요.

이번에 문제가 발생하는 하드를 제외시키고, SATA 하드에 OS 를 Ext4 로 설치하고 데이터 하드들만 따로 LVM 으로 묶어서 관리해야 겠습니다.  

 
저작자표시
두번째 게시물  (게시판 형식으로 변경)
첫번째 게시물  (뼈대를 만들고)

Node.js 를 이용해서 열악한 하드웨어 스펙으로도 많은 사용자를 접속 처리를 하며, MongoDB 를 이용해서 엄청난 수의 게시물도 소화가 가능한 말 그대로의 대용량 게시판에 대한 개인 작업입니다.  

프로젝트 페이지는 https://github.com/crazia/nodejs-mongodb 입니다.  천천히 천천히 작업중이라 진도가 느리지만 이번 커밋 내용은 소스에 대한 간단한 리팩토링과 README 파일 수정입니다.

다음에는 시나리오에 맞게 회원가입을 만들어 볼 예정입니다.

 
저작자표시


와우 안한지 1년 가까이 되 가지만 후회는 없네요. 다만 이렇게 계속 되는 걸 보니 왠지 애처롭다는 생각만 가득.. ㅜ.ㅜ 

대충 보기에도 재미도 없어보이고, 줄구룹의 재탕 같은 느낌 .. 
저작자표시
GIT 은 소스 레파지토리 시스템인데 그 중에 특별히 '분산' 개념이 들어가 있습니다. 다른 레파지토리랑 (cvs, svn) 비교를 많이 하지만 '분산' 이라는 점에서 많은 차별점이 있습니다. 원래 태어날 때도 여타 소스 레파지토리에 '분산' 기능이 없기 때문에 태어났기도 합니다. 

조금 쉽게 이해를 하자면, GIT 은 기본적으로 제 Local 에 레파지토리를 가지고 있는 방식이라고 볼 수 있습니다. 즉 중앙 개념이 희박합니다. Local 에서 리비젼 관리가 완벽하게 이루어 집니다. Remote (원격) 개념은 공동 작업을 할 때 필요하다고 보면 될 것입니다. 결국 push / pull 은 원격에만 관여하는 것이고 나머지 기능들은 Local 에서 소스 관리하는 기능이라고 보시면 됩니다. (자질 구레한 것은 따지지 말기로 하죠 ㅎㅎ)

그렇다면 가장 헷갈리기도 하고 잘 쓰기가 어려운 merge / branch 개념을 git 에서는 필수적으로 사용할 줄 알아야 하는데 그 내용을 살펴보기로 하겠습니다. 

시나리오

1. 웹 사이트에서 일을 하는 중 
2. 새로운 스토리에 맞춰서 브랜치를 생성함
3. 위에서 생성한 브랜치에 무엇인가 작업을 하는중 

 이슈가 발생하고 핫픽스를 (hotfix) 해야 합니다. 이는 다음과 같은 절차로 할 수가 있습니다. 

1. 운영 브랜치로 바꾸고
2. 핫픽스를 추가할 브랜치를 생성합니다. 
3. 핫픽스가 테스트 됐다면,  핫픽스 를 머지(merge) 하고, 운영 브랜치로 밀어넣습니다. (push)
4. 원래 하던 작업으로 돌아가서 계속 일을 합니다. 


커밋이 세번 일어난 브랜치라고 가정합니다. 세번째 커밋을 master 가 가르키고 있는것에 주목합니다. 이 때 이슈가 발생했습니다. 이슈를 처리하기 위해서 브랜치를 만듭니다. 

$ git checkout -b iss53
Switched to a new branch "iss53"


iss53 으로 브랜치를 만듭니다. 이 명령은 실은 두가지 명령이 하나로 합쳐진 것입니다. 

$ git branch iss53
$ git checkout iss53


이렇게 하는 것이지만 귀찮으니 축약 버젼을 쓰기로 합니다. 



iss53 브랜치가 생성 됐기 때문에 2개의 브랜치가 공존하는 형태가 됩니다. C/C++ 언어의 포인터 개념과 비슷하군요 

그리고 그 브랜치에서 무엇인가 작업을 하고 커밋을 합니다. 가령 예를 들자면 

$ emacs index.html 
$ git commit -a -m 'added a new footer [issue 53]'


이런식으로 (원문의 vim 을 emacs 로 바꿨습니다.)



이제 이 와 같이 브랜치의 모습이 바꼈을 것입니다. 이제 작업한 내용을 합쳐야 합니다. 다시 master 브랜치로 바꾸어 줍니다. 

$ git checkout master
Switched to branch "master"

이제 핫픽스 해줘야 하는 경우 입니다. 브랜치를 만들고 수정을 가하고 commit 을 합니다. 

$ git checkout -b hotfix
Switched to a new branch "hotfix"
$ emacs index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix]: created 3a0874c: "fixed the broken email address"
1 files changed, 0 insertions(+), 1 deletions(-)





이 과정이 끝나면 위와 같은 형태로 브랜치들이 정리될 것입니다. 이제 머지(merge)를 해야 할 시간이 왔습니다. 

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
README |    1 -
1 files changed, 0 insertions(+), 1 deletions(-)


master 로 브랜치를 변경하고 합치는 것에 유의하셔야 합니다. 



master 와 hotfix 브랜치가 같은 곳을 지정하고 있습니다. 이제 브랜치(포인터) 하나를 삭제해 줍니다. 

$ git branch -d hotfix
Deleted branch hotfix (3a0874c).



그리고 다시 원래 하던 작업으로 돌아가서 작업을 계속 합니다. 

$ git checkout iss53
Switched to branch "iss53"
$ emacs index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53]: created ad82d7a: "finished the new footer [issue 53]"
1 files changed, 1 insertions(+), 0 deletions(-)




그러면 위와 같은 형태의 브랜치 모습이 될 것입니다. 

구체적으로 merge 부분을 자세하게 보는 것과 컨플릭트(conflict)를 해결하는 방법은 원문을 살펴 보세요 
저작자표시
무엇이든 지 간에 실제로 짜보기 전에는 공부가 됐다고 말할 수가 없을 것입니다. 그런 의미로 조금 복잡한 프로그램을 만들어 본다면, 거의 할 수 있는 최고의 공부가 될 것입니다. 거기다가 처음부터 차근 차근 만들어 볼 수 있다면? 

그런 의미에서 Nethack 이라는 게임을 클로져로 만들어 보는 것이 정말 괜찮은 공부가 될 수 있을 것입니다.  
저도 우연히 발견한 사이트 인데 정말 많은 공부가 되고 있습니다. 실전 Clojure 공부라고 볼 수 있습니다.

http://stevelosh.com/blog/  

1 부터 차례로 따라하시면 됩니다. 
저작자표시
요즘 Protocol 을 사용해서 (defprotocol) 무엇인가 만들어 보는 중인데, 알 수 없는 이상한 버그가 종종 발생합니다. 분명히 돌아가는 코드인데, 코드를 살짝 변경했는데, method 를 찾을 수 없다는 에러. 답답해서 별 짓을 다 해봤지만 원인을 알 수가 없었는데, 우연히 발견한 방법으로 에러를 추정할 수가 있었습니다. 

target/ 디렉토리 안에 들어있는 class 파일들을 캐싱하다가 definition 을 못 찾는 것으로 추정됩니다. 뻔하게 돌아가야 하는데 안 돌아간다면 project 디렉토리에서

$ lein clean



한 번 실행해 주고 다시 컴파일을 해 준다면 정상적으로 돌아 갈 것입니다. (이 걸 몰라서 몇 주째 고생했음 ㅜ.ㅜ)

ps.
 명령을 실행하기 전에 clojure  연결은 다 끊어 주셔야 합니다. 
 
저작자표시
맥북을 사용할려는 사람들이 가지는 두려움은 바로 OS 에 대한 두려움 입니다. OSX!! 물론 저는 별 상관없이 쓰지만 부담 되는 사람들은 엄청 부담된다고 합니다. 

디자인은 맥북이 좋지만, OS 는 윈도우가 좋다. 또는 리눅스 신봉자니까 노트북에는 리눅스를 깔아줘야지? 이런 분들을 위한 최강의 가성비(가격대 성능비)를 자랑합니다.

바로 인민-에어!!!

 
생긴건 완전 비슷합니다. 바로 저 별(사과 대신) 마크 때문에 인민-에어 라는 별칭으로 불리고 있습니다. 비슷한 디자인에 가격은 살인적인 국내 대기업 L모사의 노트북하고 비교해도 최강의 선택이라 할 수 있을 정도입니다. (그 노트북은 220만원 대였고 얘는 70만원 이내입니다. 소니가 왜 망했는지 기억하라!! L모사!!) 

 
사양입니다. 와우!! 라는 소리가 나올만큼 훌륭합니다. -ㅅ- 아아.. 어쩌자고 지금 나왔단 말입니까, 내가 빌어먹을 맥북을 사기전에 나왔음 바로 사서 Linux Mint 를 설치해서 사용했을 텐데요 흑흑

 ps. 
 
체게바라 에어!! 도 있다는 군요 ㅋㅋ  
저작자표시
원래 의도는 이런게 아니였습니다. 하지만 같은 효능을 가지고 있더군요 쿨럭.. 
특정 사이트에 기생하는 충(蟲)분들이 열심히 일러 바쳐서 못 들어가지는 사이트가 있었습니다. 저를 번뇌에 들게  만드는 자료를 주로 구하던 곳(?) 이라 막힌게 가슴이 아팠지만 이 방법을 쓰니 다행히 접근이 되더군요.

완벽한 방법은 아니지만 토렌트 관련 자료들이나 자석 관련 자료들이 몰려 있는 곳이라면 충분히 사용해 볼만 합니다.

방법은 쉽습니다.

http://www.google.com/gwt/n?u= 



위 사이트에 들어가서 URL 입력하라는 곳에 들어가시고 싶은 주소를 적으면 됩니다.  거듭 말하지만 완벽한 것은 아닙니다. 

자매 사이트로 

http://www.1proxy.de/



가 있습니다. 사용법은 동일합니다. (다만 이쪽이 더 월등히 성능이 좋아 보이더군요 ㅎㅎ) 


 
저작자표시

+ Recent posts

티스토리툴바