프로그래밍 세계의 어둠의 마법 (Dark Magic) 으로 불리우는 Lispy Macro 를 다시금 정복할려고 도전중입니다. 벌써 한 세번째 도전했나.. 좌절할 때마다 아니야 도저히 이럴 수는 없어!! 내가 이렇게 평범할 리는 없어!! 라며 눈물을 (?) 흘리게 만듭니다. 이제 다시 기초 지식을 쌓았으니 다시 도전할 시기입니다. 

예전포스트  
저작자표시
저번에 살짝 언급했던 일을 처리중입니다. ( 요기에서 언급함 ) 뭐 우리가 무슨 힘이 있겠습니까? 해달라면 해줄 뿐이지 ㅎㅎ 

바꾸면서 나도 무슨 테이블인지, 무슨 컬럼인지 자세히 봐야지만 알 수가 있는 네이밍 컨벤션이더군요.. 투덜 투덜..

아 이제 그만 투덜되고!! 그렇다고 많지도 않지만 또 어찌보면 많은 부분을 다 찾아주기가 귀찮더군요. 그래서 어떻게 하면 편하게 바꿀 수 있을까를 고민했습니다. 

'훌륭한 해커는 게을러 지기 위해서 프로그래밍을 한다!!' 라는 멋진 사상과 부합되간다면 저도 훌륭하지는 않지만 해커의 길로 나선 것이라고 볼 수가 있습니다.  더구나 제가 쓰는 텍스트 에디터가 바로 이맥스 아닙니까? 바로 개발 들어갔습니다. 



바껴야 될 쿼리 부분을 리젼으로 지전하고 change-table 함수를 호출해 주면 변환은 끝입니다.

 
저작자표시
원래는 다른 의미로 쓰는 용어인데, 요즘은 이 한가지를 의미하는 말로 바뀐거 같습니다. 
프로그래머가 웹 프로그래밍을 할 때 제일 싫어하는 게 무엇인지 물어보면 10중 7은 서슴치 않고 대답을 할 것입니다. 망할 CSS ..

전문 프로그래머에 가까우면 가까울 수록 이쁜 웹 디자인하고는 거리가 멀리 멀리 떨어지게 마련입니다. 혹 유려한 디자인과 훌륭한 개발 실력을 동시에 갖춘 개발자 아닌 돌연변이가 있기는 하지만 그런 사람 찾기가 하늘의 별 따기입니다.

그래서 혹시나 특출난 아이디어를 기반으로 하여 웹 서비스를 개발한다고 하더라도 그 못생긴 UI 에 실망하며 아 못생겼으니 이용도 하기 싫구나!! 를 연발하기 마련입니다.

그런 개발자분들을 위한 트위터 형식의 UI 형식을 갖춰줄 수 있게 해주는 훌륭한 개발 패키지 입니다.

http://twitter.github.com/bootstrap/

일단 직접 찾아가서 살펴 보시면 됩니다. 소개 부분에 있는 'by Nerds, for Nerds' 라는 말이 인상 깊군요 ㅎㅎ. 만들어진 예제 사이트를 보시면 어디선가 본듯한 형상이실 것입니다. 맞습니다!! 게으른 개발자들이 바로 이걸 이용해서 만든 것이지요!! 

EDITED: 2013-01-22

 
저도 이정도의 화면 작업이 가능해진답니다 ㅋㅋㅋ  
저작자표시
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20130117094340

천재 해커가 자살했습니다. 논문 절도 혐의에 대한 4억달러 배상과 50년 이상의 형이 집행될 예정을 비관해서.. 지적 재산권이 중요하지만 인권에 비하겠습니까? 그는 평소 해커정신을 소유해서 정보의 자유로운 공유를 주장했을 뿐입니다. 물론 그 방법이 범법적 행위 였지만 그 행위가 4억달러와 50년 이상의 형을 받을 만큼 참혹한 행위라고 볼 수 있었을 까요? 

이 논쟁은 사실 첨예한 부분이고 다른 사람들도 많이 의견이 분분한 분야이기 때문에, 저는 다른 관점으로 보고 있습니다. RSS  초기 개발자이며, Reddit 사이트의 개발자 인건 유명하지만 Reddit 의 초기 개발은 Lisp 으로 만들어 졌습니다. 초천재 Lisper 가 사망한 것이지요 ㅜ.ㅜ 안그래도 고수가 부족한 리습 세상에서 또 한사람의 고수가 세상을 뜨다니 나중에 이 사실을 접하고 가슴이 멍하더군요. 26살의 젊은 나이에 ..  이제 슬슬 물이 올라서 놀라운 창작을 만들어 내야 할 나이에.. 

더 열받는건 판결에 정치적 이슈가 끼어 있을지도 모르는 사실이군요.. 이놈의 신 자유주의가 뭔지 돈 때문에 정말 중요한 것들이 무시 받는 세상이 되버렸군요. 

매카시 옹께서 스와르츠군을 잘 보살펴 드릴꺼라 믿습니다.  
저작자표시
최근에 자기 기업 스타일과 다른 디비 설계 컨벤션을 썼다고 설계 품질이 낮다고 지적하면서 이걸 전체 회신으로 보내는 엽기 행각을 당했다. (디비 테이블명을 명사 복수형으로 쓰는게 그렇게 이상한가? -ㅅ- person / people , user / users  등등) 

대체 설계품질을 뭐로 따지는 건가? 디비 컬럼명을 대문자로 안 썼다고? 어트리뷰트가 컬럼명으로 전환이 안된다고?

심지어 모델 케이스 툴을 안쓰냐고 (거의 ㅉㅉ 가 뒤에 붙어있는지 음성 지원 효과도 되는 듯한..) 원하면 교육시켜준다는 소리까지..

그거 다 알거든요? 몇년전에 쓰다가 그냥 대충 만들어도 되길래 안 쓰는거거든요?

완전 느낌이  "C/C++ 코딩할 때 헝가리안 표기법 안쓰니까 당신 초급 개발자네요 열심히 노력하세요.." 라는 지적을 당한 기분!! 그르르르릉!! 
저작자표시
최근에 서버가 사망하는 일이 발생했습니다. 내 다시는 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' 방식도 또 하나의 대안이 될 수 있으며, 이 새로운 방법론에 대한 가능성은 소프트웨어를 개발하는 방법의 수만큼 많으리라 봅니다. 

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

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

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

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

 
저작자표시
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 부터 차례로 따라하시면 됩니다. 
저작자표시

+ Recent posts

티스토리툴바