왜 나는 웹의 개발을 불편해하는가. (불편해하지 않게 하기 위한 질문)
첫번째 이유로는 완성품의 정의를 명확하게 정의하기 어렵기 때문에, 결국 많은 混乱と遅れ를 반복하기 때문입니다.
Refactorying, 명확하지 않거나 모호한 요건은 가능한 다음 Iteration에서 대응하는 방법도,
Iteration이 반복될 수록, 고객(또는 사업부)쪽에서 이번기회에 요구되는 기능이 확 추가해버리고자 하면 더욱 곤란해집니다.
->
스스로 pseudo를 작성하고, 완성하면 이것을 함께 제출하는 방법을 써봐야겠습니다.
두번째 이유는 테스트.
아무리 최신 DI, ORM, Test framework을 사용해 코드를 멋지게 우아하게 작성했다고 해도,
결국 브라우저에서 입력하고 클릭해가며 하는 테스트를 수행해야하는데, 정말 재미가 없습니다.
기능 업데이트나 변경이 있으면 그 테스트를 반복해 수행해야 합니다.
->
각 브라우저별 플러그인이나 익스텐션등을 제작해서 하는 자동화라도 생각해 봐야겠습니다.
더있을까요?
흠.
Sunday, December 6, 2009
Thursday, December 3, 2009
개발 방법론? xp? 애자일? 우리 팀장 이야기를 들어보세요
우리 팀장은 경력 19년입니다.
나이는 43세이고 2010년이면 한살이 더 많아집니다. 대학을 졸업하고 줄곧 개발라인에서 있어왔습니다.
19년전이면 1990년이군요. 제가 91학번인데, 제가 입학할 때쯤 부터 사회에서 활약한 것 같습니다.
이때는 당연하지만 윈도우즈95가 없던 시절입니다. 대학 1학년때 허큘레스나 cga 그래픽 환경에서 디스켓을 교환해가며 아래아 한글을 배우던 시절입니다. wikipedia를 보니 윈도우즈 3.1이 92년에 발표되었다고 하는군요.
정식 직급은 팀장이나 과장이라는 명칭이 없기 때문에 '매니저'라는 타이틀이 있습니다.
다들 그러한지 모르겠지만, 이 회사에서는 본부장-부장-매니저-어시스턴트 매니저- 라는 타이틀을 사용합니다.
우리 팀장은 제가 일하는 회사에 들어온지 8년정도 되었습니다. 내년이면 9년이 됩니다.
일본회사이다보니 그런지(모든 일본회사가 다 그런 것은 아닐것입니다만) 임원진이 아니면 승진은 근속년으로 정합니다. 그래서 훨씬 젊은 30대의 10년근속(내년이면 11년이 되는) 부장 밑에 있습니다.
인물의 소개는 이쯤으로 하고, 제가 소개하고 싶은 것을 말씀드리자면 이 팀장이 팀을 꾸러나가는 방법입니다.
---------
소개하기 전에 앞서, 저도 일본회사에 들어오기 전, 한국회사에서 과장 2년차까지 지내다 왔고, 저 또한 개발매니저의 역할이라던지, XP니, 애자일이니, 스크럼이니 하는 방법론들에 대해 연구를 많이 하고 경험해 보았기 때문에, 한 쪽으로 치우친 의견만은 아니라는 것을 언급해 두고 싶습니다.
각 장점, 단점, 그리고 지금도 많이 토론되고, 개선방법등 연구되어져 가고 있는 것을 잘 알고 있습니다만, 이런 방식도 있구나 하는 것으로 들어봐 주세요.
---------
우리 팀장의 방식을 서머라이즈 해보면,
1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.
2) 개발 팀원은 기획회의에 참여하지 않습니다.
3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.
4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.
가 특징입니다.
1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.
우선 이 내용은 팀장이 자신의 매니징 방법등을 공식적으로 설명한 것이 아니라, 제가 멤버로서 함께 일하며 경험해 '아-! 이런 방식이구나.'하고 느낀 것입니다.
작업의 단위는 크게 주어지지 않습니다. 한국에서의 경험으로 말하자면 어느 모듈, 어느 메뉴의 한 부분등을 한 개발자가 맡아서 3-4일이나, 일주일등의 어느 정도 기간을 할당하여 맡기지 4시간 정도로 맡기지는 않지 않습니까.
우리 팀장은 4시간이면 끝낼만 하겠다 싶게끔 일을 줍니다.
그리고 끝나면 보고해 달라고 합니다.
만일 예상한 시간보다 더 짧은 시간내에 끝내면, 다음번은 조금 난이도를 높여서 줘봅니다.
반대로, 만일 예상한 시간보다 더 오래 걸렸다면, 다음번에는 난이도를 낮춰서 줘봅니다.
4시간이면 하루 8시간 근무의 절반의 시간입니다.
메신저를 많이 했다던가, 회사일 이외의 개인적인 일이나, 업무에 집중하지 못해서 4시간 분량의 일을 퇴근할 때쯤 8시간을 사용해 다 했습니다 하고 보고하는 경우에도, 다음번에는 난이도를 낮춰서 줘봅니다.
이것이 반복되면 일의 단위가 소스 몇줄을 고치는 정도의 일 정도의 단위로 나오게 되다가, 나중에는, 소스가 아닌 브라우저로 테스트하고, 결과를 엑셀에 적어서 제출하는 일을 하게 되기도 합니다. (실제 중국인 여성의 개발자가 그렇게 되었었던 적이 있습니다.)
일을 다 하면 보고합니다. 4시간 정도의 분량을 4시간정도에 끝내면 하루에 2번은 팀장과 작업에 대해 커뮤니케이션 하는 것이 됩니다.
이 방법을 사용하면, 제가 옆에서 보기에도 확실히 프로젝트나 인력(리소스)등의 매니징이 됩니다. 프로젝트가 현재 어디까지 진행중이고, 완료 예정일을 확실히 잡을 수 있습니다. 팀원이 낮에 집중하지 못하고 일하다가 습관적으로 야근하며 일하게 하는 것도 방지됩니다.
또, 팀원들의 개별 실력파악도 이것으로 확실히 할 수 있습니다. 사분기로 나눠서 하는 평가에도 그대로 반영됩니다.
2) 개발 팀원은 기획회의에 참여하지 않습니다.
이 팀장의 방식 이야기를 누군가에게 했더니, '회의라던지 가면 어떻게 4시간내에 끝낼 수 있느냐..' 라고 질문을 받은 적이 있습니다. 답은. '일반 개발자는 기획회의에 참여하지 않는다' 입니다.
회사 전체가 이러한 방법을 취하고 있는 것은 아닙니다. 우리 팀원의 팀장의 방식입니다.
이것은 여러가지 의미가 있습니다.
기획을 담당하는 사업부와 개발부간의 창구의 일원화. 팀의 개발자들에게 집중할 수 있는 환경을 제공. 그리고 로직의 결정등 사공이 여럿이 생기지 않는 것 등. 장점이 큽니다.
그러나 저도 한국에서 이렇게 하지 않았고, 회사의 다름 팀도 대게는 이렇게 하지 않는데, 그 이유는 회의에 참석한 사람에게 전달된 내용의 구현의 책임이 주어지게 되는 것이기 때문에, 로직을 생각하는 것과 구현의 책임을 팀장 혼자서 책임 지는 것과 같은 부담을 피하기 위해서입니다.
그러나 우리 팀장은 혼자서 참석하고, 들은 내용의 로직을 생각해 적어서, 변수명이나 파라메터 설정값등도 생각나는 범위의 한에서 적어서 메일로 전달합니다. (큰 내용을 전달하더라도 4시간 분량의 작업범위만큼을 정해서 이정도 까지 되면 보고해 주세요. 그 뒤 그 다음의 세부 내용을 말로 설명하겠습니다 하고 작업을 냅니다.)
3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.
전달은 팀 전원에게 CC로 전달합니다. 이것은 팀장의 특별한 방식이 아니라, 대게의 일본의 회사가 그러합니다. 만일 팀원이 결원되더라도, 다른 팀원도 메일박스를 조사해보면, 이 부분의 작업이 어떻게 흘러가고 있었는지를 알 수 있습니다.
작업은 메일로 전달하고, 반드시 구두로도 다시 한 번 전달합니다. 일본에서는 認識間違い라고 하는, 하나의 내용을 서로 다르게 이해하고 있는 것을 피하게 하기 위해서 입니다.
4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.
예전에는 사용하는 곳이 드믈었지만, 지금은 어디서나 SVN이나 VSS같은 소스 관리 툴을 사용하는 것이 상식화되어 있습니다. 커밋된(또는 체크인된) 소스는 반드시 팀장이 읽어봅니다.
Connection.close를 잊었었다던지(또는 더 빨리 할 수 있는 것을 발견했다던지), transaction걸고 에러나면 rollback되는 처리를 빠뜨렸다던지, 불필요한 변수 선언이 남아있었다던지, 퍼포먼스가 나쁜 부분을 발견했다던지 하면 수정해 달라고 다시 요청합니다. 반복 요청된 만큼 소스관리툴에서는 그 개발자의 커밋또는 체크인이 기록되기 때문에, 이는 또 창피한 요소가 됩니다. 말은 안하고 있지만 당연히 평가에도 반영되고 있을 것입니다.
'OK입니다'라고 말을 들었더라도 그것으로 완전히 끝난 것이 아닙니다. 자신이 작업한 부분의 검증이 다른 팀원에게 할당되기도 합니다.
매니저는 매우 바쁩니다. 기획 회의에 참석하고, 개발자들에게 작업을 내고, 결과를 받고 피드백을 줘야 합니다. 참석한 회의에서 들은 내용의 구현 로직을 생각해 적어야 하고, 팀 보고의 매니저 회의에 참석해야합니다. 자잘한 업무보고도 취합해 부장, 본부장에게 적어서 내야하고, 휴가등의 스케쥴 관리도 해야합니다. 분기별 새로운 기술공유를 위해 매니저들에게 내는, 연구과제 숙제도 해야합니다. 결제와 관련된 Batch가 잘 동작하고 있는지 주말에도 한번쯤 확인해야하고, 월말이면 더욱 많아집니다. 캠페인이라도 있는 날이면, 서버 부하도 한번씩 살펴봐야 합니다.
소스관리나, Deploy는 보안과 관련된 것이어서 함부로 팀원에게 맡길 수도 없기 때문에 직접합니다. 팀원이 개발의 구현을 헤매고 있으면 도와주기도 하고(절대 코드를 대신 짜주는 것은 아닙니다만), 스케쥴에 맞추기 위해 그중에서도 개발을 합니다.
그런데, 절대 운용상 큰 오류를 내거나, 납기를 맞추지 못한 적이 없습니다.
이것은 XP, 애자일, 스크럼등의 새로운 방법론과 확실히 대조가 되는 방법입니다. 전통적이라고 해야할까요. 중요한 것은 굉장히 안정된 개발과 팀 운영이 되고 있다는 점입니다.
단점도 분명히 있습니다.
예를 들면 매니저에게 너무 막강한 Role이 주어져있는 것, 팀원이 많으면 이 방법을 사용할 수 없는 것(우리팀은 팀장포함 4명입니다). 후임을 양성시키기에 불편한 방식이라는 점등.
그런데 야근도 없고, 개발팀원은 개발에 집중할 수 있습니다. 잘만 운영되고 있는 것을 보면 신기합니다. 저라면, 제가 매니저가 된다면, 저도 이 방법을 취할 것만 같습니다. 그래서 한번쯤은 소개해야겠다라고 생각이 들었습니다.
여러분도, 한번 생각해 보세요.
뭔가 질문이 있으면 보충하겠습니다.
이상.
나이는 43세이고 2010년이면 한살이 더 많아집니다. 대학을 졸업하고 줄곧 개발라인에서 있어왔습니다.
19년전이면 1990년이군요. 제가 91학번인데, 제가 입학할 때쯤 부터 사회에서 활약한 것 같습니다.
이때는 당연하지만 윈도우즈95가 없던 시절입니다. 대학 1학년때 허큘레스나 cga 그래픽 환경에서 디스켓을 교환해가며 아래아 한글을 배우던 시절입니다. wikipedia를 보니 윈도우즈 3.1이 92년에 발표되었다고 하는군요.
정식 직급은 팀장이나 과장이라는 명칭이 없기 때문에 '매니저'라는 타이틀이 있습니다.
다들 그러한지 모르겠지만, 이 회사에서는 본부장-부장-매니저-어시스턴트 매니저- 라는 타이틀을 사용합니다.
우리 팀장은 제가 일하는 회사에 들어온지 8년정도 되었습니다. 내년이면 9년이 됩니다.
일본회사이다보니 그런지(모든 일본회사가 다 그런 것은 아닐것입니다만) 임원진이 아니면 승진은 근속년으로 정합니다. 그래서 훨씬 젊은 30대의 10년근속(내년이면 11년이 되는) 부장 밑에 있습니다.
인물의 소개는 이쯤으로 하고, 제가 소개하고 싶은 것을 말씀드리자면 이 팀장이 팀을 꾸러나가는 방법입니다.
---------
소개하기 전에 앞서, 저도 일본회사에 들어오기 전, 한국회사에서 과장 2년차까지 지내다 왔고, 저 또한 개발매니저의 역할이라던지, XP니, 애자일이니, 스크럼이니 하는 방법론들에 대해 연구를 많이 하고 경험해 보았기 때문에, 한 쪽으로 치우친 의견만은 아니라는 것을 언급해 두고 싶습니다.
각 장점, 단점, 그리고 지금도 많이 토론되고, 개선방법등 연구되어져 가고 있는 것을 잘 알고 있습니다만, 이런 방식도 있구나 하는 것으로 들어봐 주세요.
---------
우리 팀장의 방식을 서머라이즈 해보면,
1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.
2) 개발 팀원은 기획회의에 참여하지 않습니다.
3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.
4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.
가 특징입니다.
1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.
우선 이 내용은 팀장이 자신의 매니징 방법등을 공식적으로 설명한 것이 아니라, 제가 멤버로서 함께 일하며 경험해 '아-! 이런 방식이구나.'하고 느낀 것입니다.
작업의 단위는 크게 주어지지 않습니다. 한국에서의 경험으로 말하자면 어느 모듈, 어느 메뉴의 한 부분등을 한 개발자가 맡아서 3-4일이나, 일주일등의 어느 정도 기간을 할당하여 맡기지 4시간 정도로 맡기지는 않지 않습니까.
우리 팀장은 4시간이면 끝낼만 하겠다 싶게끔 일을 줍니다.
그리고 끝나면 보고해 달라고 합니다.
만일 예상한 시간보다 더 짧은 시간내에 끝내면, 다음번은 조금 난이도를 높여서 줘봅니다.
반대로, 만일 예상한 시간보다 더 오래 걸렸다면, 다음번에는 난이도를 낮춰서 줘봅니다.
4시간이면 하루 8시간 근무의 절반의 시간입니다.
메신저를 많이 했다던가, 회사일 이외의 개인적인 일이나, 업무에 집중하지 못해서 4시간 분량의 일을 퇴근할 때쯤 8시간을 사용해 다 했습니다 하고 보고하는 경우에도, 다음번에는 난이도를 낮춰서 줘봅니다.
이것이 반복되면 일의 단위가 소스 몇줄을 고치는 정도의 일 정도의 단위로 나오게 되다가, 나중에는, 소스가 아닌 브라우저로 테스트하고, 결과를 엑셀에 적어서 제출하는 일을 하게 되기도 합니다. (실제 중국인 여성의 개발자가 그렇게 되었었던 적이 있습니다.)
일을 다 하면 보고합니다. 4시간 정도의 분량을 4시간정도에 끝내면 하루에 2번은 팀장과 작업에 대해 커뮤니케이션 하는 것이 됩니다.
이 방법을 사용하면, 제가 옆에서 보기에도 확실히 프로젝트나 인력(리소스)등의 매니징이 됩니다. 프로젝트가 현재 어디까지 진행중이고, 완료 예정일을 확실히 잡을 수 있습니다. 팀원이 낮에 집중하지 못하고 일하다가 습관적으로 야근하며 일하게 하는 것도 방지됩니다.
또, 팀원들의 개별 실력파악도 이것으로 확실히 할 수 있습니다. 사분기로 나눠서 하는 평가에도 그대로 반영됩니다.
2) 개발 팀원은 기획회의에 참여하지 않습니다.
이 팀장의 방식 이야기를 누군가에게 했더니, '회의라던지 가면 어떻게 4시간내에 끝낼 수 있느냐..' 라고 질문을 받은 적이 있습니다. 답은. '일반 개발자는 기획회의에 참여하지 않는다' 입니다.
회사 전체가 이러한 방법을 취하고 있는 것은 아닙니다. 우리 팀원의 팀장의 방식입니다.
이것은 여러가지 의미가 있습니다.
기획을 담당하는 사업부와 개발부간의 창구의 일원화. 팀의 개발자들에게 집중할 수 있는 환경을 제공. 그리고 로직의 결정등 사공이 여럿이 생기지 않는 것 등. 장점이 큽니다.
그러나 저도 한국에서 이렇게 하지 않았고, 회사의 다름 팀도 대게는 이렇게 하지 않는데, 그 이유는 회의에 참석한 사람에게 전달된 내용의 구현의 책임이 주어지게 되는 것이기 때문에, 로직을 생각하는 것과 구현의 책임을 팀장 혼자서 책임 지는 것과 같은 부담을 피하기 위해서입니다.
그러나 우리 팀장은 혼자서 참석하고, 들은 내용의 로직을 생각해 적어서, 변수명이나 파라메터 설정값등도 생각나는 범위의 한에서 적어서 메일로 전달합니다. (큰 내용을 전달하더라도 4시간 분량의 작업범위만큼을 정해서 이정도 까지 되면 보고해 주세요. 그 뒤 그 다음의 세부 내용을 말로 설명하겠습니다 하고 작업을 냅니다.)
3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.
전달은 팀 전원에게 CC로 전달합니다. 이것은 팀장의 특별한 방식이 아니라, 대게의 일본의 회사가 그러합니다. 만일 팀원이 결원되더라도, 다른 팀원도 메일박스를 조사해보면, 이 부분의 작업이 어떻게 흘러가고 있었는지를 알 수 있습니다.
작업은 메일로 전달하고, 반드시 구두로도 다시 한 번 전달합니다. 일본에서는 認識間違い라고 하는, 하나의 내용을 서로 다르게 이해하고 있는 것을 피하게 하기 위해서 입니다.
4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.
예전에는 사용하는 곳이 드믈었지만, 지금은 어디서나 SVN이나 VSS같은 소스 관리 툴을 사용하는 것이 상식화되어 있습니다. 커밋된(또는 체크인된) 소스는 반드시 팀장이 읽어봅니다.
Connection.close를 잊었었다던지(또는 더 빨리 할 수 있는 것을 발견했다던지), transaction걸고 에러나면 rollback되는 처리를 빠뜨렸다던지, 불필요한 변수 선언이 남아있었다던지, 퍼포먼스가 나쁜 부분을 발견했다던지 하면 수정해 달라고 다시 요청합니다. 반복 요청된 만큼 소스관리툴에서는 그 개발자의 커밋또는 체크인이 기록되기 때문에, 이는 또 창피한 요소가 됩니다. 말은 안하고 있지만 당연히 평가에도 반영되고 있을 것입니다.
'OK입니다'라고 말을 들었더라도 그것으로 완전히 끝난 것이 아닙니다. 자신이 작업한 부분의 검증이 다른 팀원에게 할당되기도 합니다.
매니저는 매우 바쁩니다. 기획 회의에 참석하고, 개발자들에게 작업을 내고, 결과를 받고 피드백을 줘야 합니다. 참석한 회의에서 들은 내용의 구현 로직을 생각해 적어야 하고, 팀 보고의 매니저 회의에 참석해야합니다. 자잘한 업무보고도 취합해 부장, 본부장에게 적어서 내야하고, 휴가등의 스케쥴 관리도 해야합니다. 분기별 새로운 기술공유를 위해 매니저들에게 내는, 연구과제 숙제도 해야합니다. 결제와 관련된 Batch가 잘 동작하고 있는지 주말에도 한번쯤 확인해야하고, 월말이면 더욱 많아집니다. 캠페인이라도 있는 날이면, 서버 부하도 한번씩 살펴봐야 합니다.
소스관리나, Deploy는 보안과 관련된 것이어서 함부로 팀원에게 맡길 수도 없기 때문에 직접합니다. 팀원이 개발의 구현을 헤매고 있으면 도와주기도 하고(절대 코드를 대신 짜주는 것은 아닙니다만), 스케쥴에 맞추기 위해 그중에서도 개발을 합니다.
그런데, 절대 운용상 큰 오류를 내거나, 납기를 맞추지 못한 적이 없습니다.
이것은 XP, 애자일, 스크럼등의 새로운 방법론과 확실히 대조가 되는 방법입니다. 전통적이라고 해야할까요. 중요한 것은 굉장히 안정된 개발과 팀 운영이 되고 있다는 점입니다.
단점도 분명히 있습니다.
예를 들면 매니저에게 너무 막강한 Role이 주어져있는 것, 팀원이 많으면 이 방법을 사용할 수 없는 것(우리팀은 팀장포함 4명입니다). 후임을 양성시키기에 불편한 방식이라는 점등.
그런데 야근도 없고, 개발팀원은 개발에 집중할 수 있습니다. 잘만 운영되고 있는 것을 보면 신기합니다. 저라면, 제가 매니저가 된다면, 저도 이 방법을 취할 것만 같습니다. 그래서 한번쯤은 소개해야겠다라고 생각이 들었습니다.
여러분도, 한번 생각해 보세요.
뭔가 질문이 있으면 보충하겠습니다.
이상.
Tuesday, November 24, 2009
박성수님께.
xxxxx@main.gjssm 의 메일계정으로 메일을 보낸 박성수님.
gmail로 제게 문의하셨는데, 이메일 주소가 이상해서 찾아보니
광주삼성멤버쉽의 약자더군요. 그런데 제가 답장을 보냈습니다만, 도착하지 않았을 거라고 생각하고 있는데요.
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
> set type=mx
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
>
일반 인터넷 네트웍으로는 main.gjssm의 MX주소를 찾을 수 없어요.
메일 헤더에 이런 내용이 있어서
Received: from main1.main.gjssm (u73.e3.xgate.co.kr [210.118.73.3])
by mx.google.com with ESMTP id 29si9691858pzk.85.2009.11.24.06.54.56;
Tue, 24 Nov 2009 06:54:57 -0800 (PST)
u73.e3.xgate.co.kr가 SMTP였을 거라고 따라가 보았습니다만
C:\Documents and Settings\usr0100023>tracert u73.e3.xgate.co.kr
racing route to u73.e3.xgate.co.kr [210.118.73.3]
ver a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.30.3 2 <1 ms <1 ms <1 ms 192.168.2.5 3 <1 ms <1 ms <1 ms 192.168.4.5 4 6 ms 1 ms 1 ms ceru-nat2.interq.or.jp [210.172.128.225] 5 2 ms 3 ms 2 ms g-svc1-e-0-4.interq.or.jp [210.172.130.78] 6 1 ms 1 ms 1 ms b5-e-2-4.interq.or.jp [210.172.191.193] 7 2 ms 2 ms 2 ms AS15412.ix.jpix.ad.jp [210.171.224.139] 8 31 ms 31 ms 31 ms so-0-3-0.0.ejr03.seo002.flagtel.com [62.216.128.18] 9 35 ms 33 ms 32 ms 80.77.1.178 10 32 ms 32 ms 32 ms 157.197.66.5 11 32 ms 32 ms 33 ms user233.s163.samsung.co.kr [203.241.163.233] 12 34 ms 33 ms 32 ms u78.ppp80.unitel.co.kr [157.197.80.78] 13 32 ms 32 ms 32 ms u174.gpu47.samsung.co.kr [203.244.223.174] 14 250 ms 225 ms 184 ms 121.253.214.234 15 199 ms 203 ms 195 ms u73.e3.xgate.co.kr [210.118.73.3]
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
>
> server red.samsung.co.kr
Default Server: red.samsung.co.kr
Address: 203.241.135.111
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
> server u73.e3.xgate.co.kr
Default Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
> set type=mx
> main.gjssm
Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
local
primary name server = nis.dacom.co.kr
responsible mail addr = dnsadm.bora.net
serial = 2008052301
refresh = 3600 (1 hour)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)
> exit
역시나 네임서버를 u73.e3.xgate.co.kr를 쓰지 않으면 인식할 수 없는 도메인(또는 mx)이에요.
아무래도 메일이 도착하지 않았을 경우에는 답장가능한 메일 주소로 다시한번 연락해 주세요.
김동현.
gmail로 제게 문의하셨는데, 이메일 주소가 이상해서 찾아보니
광주삼성멤버쉽의 약자더군요. 그런데 제가 답장을 보냈습니다만, 도착하지 않았을 거라고 생각하고 있는데요.
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
> set type=mx
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
>
일반 인터넷 네트웍으로는 main.gjssm의 MX주소를 찾을 수 없어요.
메일 헤더에 이런 내용이 있어서
Received: from main1.main.gjssm (u73.e3.xgate.co.kr [210.118.73.3])
by mx.google.com with ESMTP id 29si9691858pzk.85.2009.11.24.06.54.56;
Tue, 24 Nov 2009 06:54:57 -0800 (PST)
u73.e3.xgate.co.kr가 SMTP였을 거라고 따라가 보았습니다만
C:\Documents and Settings\usr0100023>tracert u73.e3.xgate.co.kr
racing route to u73.e3.xgate.co.kr [210.118.73.3]
ver a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.30.3 2 <1 ms <1 ms <1 ms 192.168.2.5 3 <1 ms <1 ms <1 ms 192.168.4.5 4 6 ms 1 ms 1 ms ceru-nat2.interq.or.jp [210.172.128.225] 5 2 ms 3 ms 2 ms g-svc1-e-0-4.interq.or.jp [210.172.130.78] 6 1 ms 1 ms 1 ms b5-e-2-4.interq.or.jp [210.172.191.193] 7 2 ms 2 ms 2 ms AS15412.ix.jpix.ad.jp [210.171.224.139] 8 31 ms 31 ms 31 ms so-0-3-0.0.ejr03.seo002.flagtel.com [62.216.128.18] 9 35 ms 33 ms 32 ms 80.77.1.178 10 32 ms 32 ms 32 ms 157.197.66.5 11 32 ms 32 ms 33 ms user233.s163.samsung.co.kr [203.241.163.233] 12 34 ms 33 ms 32 ms u78.ppp80.unitel.co.kr [157.197.80.78] 13 32 ms 32 ms 32 ms u174.gpu47.samsung.co.kr [203.244.223.174] 14 250 ms 225 ms 184 ms 121.253.214.234 15 199 ms 203 ms 195 ms u73.e3.xgate.co.kr [210.118.73.3]
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
>
> server red.samsung.co.kr
Default Server: red.samsung.co.kr
Address: 203.241.135.111
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
> server u73.e3.xgate.co.kr
Default Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
> set type=mx
> main.gjssm
Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
local
primary name server = nis.dacom.co.kr
responsible mail addr = dnsadm.bora.net
serial = 2008052301
refresh = 3600 (1 hour)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)
> exit
역시나 네임서버를 u73.e3.xgate.co.kr를 쓰지 않으면 인식할 수 없는 도메인(또는 mx)이에요.
아무래도 메일이 도착하지 않았을 경우에는 답장가능한 메일 주소로 다시한번 연락해 주세요.
김동현.
Friday, October 23, 2009
Thursday, October 8, 2009
마이크로소프트 Tech ed 2009 (요코하마편) 레포트
[정보공유]
시스템본부 미팅과 더불어 마이크로소프트의 Tech ed 2009 참석자의 레포트가 있었는데,
기존의 IIS는 불필요한 것들도 들어가 security문제가 빈번히 발생
(으로 인해 간단한 사용으로는 가능하지만, IT업계에서는 퇴역화 라고 말해졌습니다.)
IIS7을 소개하며 필요한 것만 load하도록 Apache처럼 모듈화가 된다는 군요.
더불어 여러가지 cgi 언어의 모듈도 가능하기 때문에
php모듈, python모듈.. 처럼 여러 언어의 스크립트도 서포트 가능. 이랍니다.
(유닉스 유저를 끌어들이기 위한 전략.)
유닉스 유저를 끌어들이기 위한 전략의 또 하나로,
Powershell.
(명령어 실행시키기로는 불편하고 별로 쓸모 없는 툴이라고 생각했었는데)
이는 기존의 GUI 위주로 설정을 변경하던 것을(CUI로도 몇몇은 가능했지만) CUI화 지원으로,
설정변경등을 스크립트화 하는 것. 이 큰 목적인 툴이랍니다.
또 가상화
Hyper-V 2.0
게임관련으로 윈도우즈 서버를 사용하는 시스템에서는 연구해 봐도 좋을 듯합니다.
특히 Live Migration 기술(복수개의 가상화서버가 움직이고 있는 어떤 Host서버에서 다른 Host서버로, down time 없이 실시간으로 이동하는 것).
그리고 VHD(Virtual Hard Disk) <--> Physical Hard Disk 간의 변환이 자유로움
은.
(참석자가 호스팅이 메인사업인 호스팅 사업부 멤버였기 때문에)
아직 윈도우즈 호스팅이 없는 일본 호스팅업계에서,
수 년 후, 윈도우즈 호스팅이 매우 늘어날(그리고 MS에서 이에 대해 서포트전략을 세우고 있다는) 전망의 얘기가 나왔습니다.
윈도우즈 엔지니어라면 눈여겨봐둬도 좋을 내용.
시스템본부 미팅과 더불어 마이크로소프트의 Tech ed 2009 참석자의 레포트가 있었는데,
기존의 IIS는 불필요한 것들도 들어가 security문제가 빈번히 발생
(으로 인해 간단한 사용으로는 가능하지만, IT업계에서는 퇴역화 라고 말해졌습니다.)
IIS7을 소개하며 필요한 것만 load하도록 Apache처럼 모듈화가 된다는 군요.
더불어 여러가지 cgi 언어의 모듈도 가능하기 때문에
php모듈, python모듈.. 처럼 여러 언어의 스크립트도 서포트 가능. 이랍니다.
(유닉스 유저를 끌어들이기 위한 전략.)
유닉스 유저를 끌어들이기 위한 전략의 또 하나로,
Powershell.
(명령어 실행시키기로는 불편하고 별로 쓸모 없는 툴이라고 생각했었는데)
이는 기존의 GUI 위주로 설정을 변경하던 것을(CUI로도 몇몇은 가능했지만) CUI화 지원으로,
설정변경등을 스크립트화 하는 것. 이 큰 목적인 툴이랍니다.
또 가상화
Hyper-V 2.0
게임관련으로 윈도우즈 서버를 사용하는 시스템에서는 연구해 봐도 좋을 듯합니다.
특히 Live Migration 기술(복수개의 가상화서버가 움직이고 있는 어떤 Host서버에서 다른 Host서버로, down time 없이 실시간으로 이동하는 것).
그리고 VHD(Virtual Hard Disk) <--> Physical Hard Disk 간의 변환이 자유로움
은.
(참석자가 호스팅이 메인사업인 호스팅 사업부 멤버였기 때문에)
아직 윈도우즈 호스팅이 없는 일본 호스팅업계에서,
수 년 후, 윈도우즈 호스팅이 매우 늘어날(그리고 MS에서 이에 대해 서포트전략을 세우고 있다는) 전망의 얘기가 나왔습니다.
윈도우즈 엔지니어라면 눈여겨봐둬도 좋을 내용.
Wednesday, September 30, 2009
정보공유 : 리눅스 터미널 로그인시 1-2분 걸리는 현상
[정보공유]
리눅스 터미널 로그인시 1-2분 걸리는 현상이 발생하고 있다면?
이전에도 몇 번 경험한 내용이었는데 해결방법을 몰랐다가 이번에 알게 되었음.
sshd에서 정방/역방 IP조회를 하고 있기 때문에 DNS 타임아웃이 발생하는 시간까지 걸리는 것일 듯.
DNS에 정방/역방 등록을 하지 않고서 해결하는 방법으로는.
(A) 우선 sshd설정(/etc/ssh/sshd_config)에서 useDNS를 no로 하는 방법과.
(B) 접속하는 곳이 고정이라면 서버측 /etc/hosts에 이름을 등록하는 방법.
이상 정보공유.
리눅스 터미널 로그인시 1-2분 걸리는 현상이 발생하고 있다면?
이전에도 몇 번 경험한 내용이었는데 해결방법을 몰랐다가 이번에 알게 되었음.
sshd에서 정방/역방 IP조회를 하고 있기 때문에 DNS 타임아웃이 발생하는 시간까지 걸리는 것일 듯.
DNS에 정방/역방 등록을 하지 않고서 해결하는 방법으로는.
(A) 우선 sshd설정(/etc/ssh/sshd_config)에서 useDNS를 no로 하는 방법과.
(B) 접속하는 곳이 고정이라면 서버측 /etc/hosts에 이름을 등록하는 방법.
이상 정보공유.
Friday, September 25, 2009
rxvt on windows
윈도우즈의 cmd로는 뭔가 부족하게 느껴집니다.
1) 프로세스를 백그라운드로 실행시키기 라던가,
2) (default로) ansi가 적용되지 않기 때문에, groovysh할 때 컬러를 쓸 수 없는 것도 그렇고. (음? 이건 장점?),
3) parameter로 묶을 때, single quotation은 사용할 수 없고, double quotation ""만 사용할 수 있는 것
4) cmd에서는 터미널타입이 적당한 것이 없어서 perl로 ssh를 자동화하기도 곤란.
이러한 이유로 rxvt + bash를 사용해 보고 있습니다.
rxvt는 vt102터미널 에뮬레이터입니다. 이번에 GNUstep인스톨할 때 같이 설치된 rxvt를 사용해 보고 있습니다.(이럴 바에는 cygwin을 쓸까 하는 생각도 해보았습니다만, 아직까지는 일반 cmd상에서도 유닉스 커맨드를 사용할 수 있는 linux command for win32 처럼 cygwin의 커맨드를 cmd에서 사용가능한 지, 확인하지 못했습니다.)
유니코드용으로 컴파일된 urxvt와 탭형식으로 된 mrxvt도 있다고 합니다만, 모두 X-windows용으로, 아직 win32용으로 컴파일된 것은 못구했습니다. (시간이 없다는 이유로 아직 직접 컴파일 해보고 있지 않습니다. m(__)m )
그런대로 사용하기는 괜찮을 듯 합니다.
소프트링크도 제대로 사용할 수 있기 때문에, 필요한 경우
/c 이하의 디렉토리를 shell root안으로 가져온다던지 하는 것도 가능했고.
괜찮은 느낌입니다.
좀 더 사용해 보겠습니다.
1) 프로세스를 백그라운드로 실행시키기 라던가,
2) (default로) ansi가 적용되지 않기 때문에, groovysh할 때 컬러를 쓸 수 없는 것도 그렇고. (음? 이건 장점?),
3) parameter로 묶을 때, single quotation은 사용할 수 없고, double quotation ""만 사용할 수 있는 것
4) cmd에서는 터미널타입이 적당한 것이 없어서 perl로 ssh를 자동화하기도 곤란.
이러한 이유로 rxvt + bash를 사용해 보고 있습니다.
rxvt는 vt102터미널 에뮬레이터입니다. 이번에 GNUstep인스톨할 때 같이 설치된 rxvt를 사용해 보고 있습니다.(이럴 바에는 cygwin을 쓸까 하는 생각도 해보았습니다만, 아직까지는 일반 cmd상에서도 유닉스 커맨드를 사용할 수 있는 linux command for win32 처럼 cygwin의 커맨드를 cmd에서 사용가능한 지, 확인하지 못했습니다.)
유니코드용으로 컴파일된 urxvt와 탭형식으로 된 mrxvt도 있다고 합니다만, 모두 X-windows용으로, 아직 win32용으로 컴파일된 것은 못구했습니다. (시간이 없다는 이유로 아직 직접 컴파일 해보고 있지 않습니다. m(__)m )
그런대로 사용하기는 괜찮을 듯 합니다.
소프트링크도 제대로 사용할 수 있기 때문에, 필요한 경우
/c 이하의 디렉토리를 shell root안으로 가져온다던지 하는 것도 가능했고.
괜찮은 느낌입니다.
좀 더 사용해 보겠습니다.
Thursday, September 24, 2009
Record : 'use constant' on perl
perl의 constant는 반드시 먼저 선언해 주어야 하는 듯.
BEGIN으로 컴파일타임시에 정의되도록 해봤지만 잘 되지 않았습니다.
'use constant'는 컴파일타임 이전의 preprocessor가 처리하는 듯?(짐작) 합니다.
evalperl
use constant CONST_SERVICEID_IPADDR => 101;
eeprint(CONST_SERVICEID_IPADDR);
101
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
use constant CONST_SERVICEID_IPADDR => 101;
CONST_SERVICEID_IPADDR
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
BEGIN { use constant CONST_SERVICEID_IPADDR => 101; }
CONST_SERVICEID_IPADDR <- 101 이 아님. orz
-----------------------------
evalperl
eeprint($CONST_SERVICEID_IPADDR);
BEGIN { our $CONST_SERVICEID_IPADDR = 101; }
101 <- 이건 101. orz
어디선가 본 글처럼, perl이나 jscript같은 interpretor에서는, 그냥 constant를 사용하기 보다는 변수로 사용하는 것이 performance면에서도, 정신적인 건강면에서도 좋지 않은가 싶습니다.
# 생각해보면, python에서도 constant가 없긴합니다.
사진은 파키스탄의 10세(2008년기준) 최연소 MCP 인증받은 소녀 프로그래머.
http://www.pakassociationdubai.com/business_details.php?id=55
.
BEGIN으로 컴파일타임시에 정의되도록 해봤지만 잘 되지 않았습니다.
'use constant'는 컴파일타임 이전의 preprocessor가 처리하는 듯?(짐작) 합니다.
evalperl
use constant CONST_SERVICEID_IPADDR => 101;
eeprint(CONST_SERVICEID_IPADDR);
101
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
use constant CONST_SERVICEID_IPADDR => 101;
CONST_SERVICEID_IPADDR
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
BEGIN { use constant CONST_SERVICEID_IPADDR => 101; }
CONST_SERVICEID_IPADDR <- 101 이 아님. orz
-----------------------------
evalperl
eeprint($CONST_SERVICEID_IPADDR);
BEGIN { our $CONST_SERVICEID_IPADDR = 101; }
101 <- 이건 101. orz
어디선가 본 글처럼, perl이나 jscript같은 interpretor에서는, 그냥 constant를 사용하기 보다는 변수로 사용하는 것이 performance면에서도, 정신적인 건강면에서도 좋지 않은가 싶습니다.
# 생각해보면, python에서도 constant가 없긴합니다.
사진은 파키스탄의 10세(2008년기준) 최연소 MCP 인증받은 소녀 프로그래머.
http://www.pakassociationdubai.com/business_details.php?id=55
.
Wednesday, September 23, 2009
programming way of system engineer
이번 기술부 지원 프로젝트에서 경험했던, 'SE의 프로그래밍을 서포트한 2009년 여름 프로젝트'는 굉장히 색다른 느낌이었습니다. 이 이야기를 적어볼까 합니다.
서포트를 나가게 된 배경은 다음과 같습니다.
2008년 리만브러더스 파산과 더불어 시작된 불경기, 그리고 사내 파견사원의 감축과 정사원위주만으로의 운영, 신규프로젝트 발생과 기술부 리소스부족(perl과 python코딩에 대한), 개발부에 지원요청과 해당 경험이 있고 덜 중요한(?!) 리소스(바로 접니다)의 지원제공.
1. 굉장히 간결한 방식을 선호(shell script를 확장한 것과 같은 느낌의 프로그래밍.)
'심플한 것이 아름답다'라는 프로그래밍에서의 정석이 있습니다만, 정말 그것을 실천하려고 애를 씁니다. 특히, 한 줄 코드로 가능할 수 있다면, 그렇게 하려고 애를 씁니다. 여기서 몇가지 지금까지와는 다른 상식으로 진행되었는데, 예를 들면,
1) 가능하면 클래스는 사용하거나 작성하지 않습니다.
어차피 pointer를 tie하는 것에 지나지 않는 클래스를 생성하려고, new하는 한 줄의 코드를 작성하는 것은, 불필요한 리소스 낭비로 여기어 지는 것 같았습니다.
2) parameter는 주로 array of hash reference
hash reference인 것은 이해가 가지만, 그것의 array였다는 것은 좀 색달랐습니다.
3) 리턴값, int형 보다는 (rc, rm)의 배열.
rc는 return code, rm은 return message입니다.(간혹 엔지니어에 따라 rv 즉 return value로 사용하는 경우도 있었습니다.)
리턴이 perl의 subroutine이든, python의 method이든, 실패했을 경우 그 이유를 알기 위한 메시지를 함께 전달합니다. 실패라면 exception을 함께 전달하는 느낌입니다.
문제없이 진행되어 rc가 성공이라면, rm은 해당 리턴값을 가지게 하는 설계가 많았습니다.
4) 리턴값, 0 = 성공, 1 = 실패
이는 시스템 커맨드의 리턴(batch라면 errorlevel)이 대게 에러번호를 리턴하는데 기인합니다.
개발자로서의 인식으로는 non-zero = true, 0 = false 이기 때문에 checkData와 같은 함수의 리턴이 1(true)라면, OK라는 인식이지만, SE에게는 NG라는 인식입니다.
이는 정의하고 진행하면 되는 것이기 때문에 특별히 문제는 없었습니다만, "음? 성공하면 0입니까? (성공하면 false입니까?)"하고 물었을 때, '음? 당연한 것을 왜묻지?'하는 느낌의 반응은 약간의 이질감을 느끼게 되더군요.
2. 놀라운 시스템 관련 지식.
이것은 말할 것도 없습니다. (모든 SE가 다 그렇지는 아니겠지만) 굉장히 정확한 지식을 가지고 있었습니다.
이런 예가 있었습니다. 한번은 '어떤 명령어 | sed xxxxx'와 같은 외부 프로세스를 실행한 결과를 치환해 값을 받도록 실행하는 코드를 작성한 적이 있었습니다. 이때 다른 명령어는 모두 문제가 없었는데 어느 특정 한 명령어는 프로세스가 종료하지 않고 메모리에 남아 있게 되는 일이 있었습니다.
이를 SE에게 문의했는데, 추적하는 것을 보여주더군요. 값진 경험이었습니다.
우선, ps상 이 프로세스가 defunc가 아니었기 때문에(좀비가 아니었기 때문에) 폭주인지, 아니면 무엇을 하고 있는지 strace를 통해 pid에 걸어서 무엇을 하고 있는지 알아보더군요. 지금까지 나 이외에 strace를 사용하는 것을 '직접' 본 두번째 경험이었습니다.)
우선은 표준입력을 기다리고 있는 것을 알아내어 폭주는 아닌 것을 확인했습니다. 그다음 왜 표준입력을 기다리고 있는지 알아보았는데, 그 '특정 명렁어'가 표준 출력으로 출력하는 것을 모두 /dev/null로 돌려놓고 있었더군요. 결국 sed는 뭔가 파이프로 전해져 오는 것이 없었기 때문에 sed가 입력을 기다리고 있었고, child의 pid를 수확하지 못하고 있기 때문에 parent의 '특정 명령어' 및 shell이 살아남아 있는 것이었습니다.
이때 잠깐 질문을 제가 했는데, sed를 echo로 바꾸면 정상종료하는데, 그 차이를 잘 이해하지 못하다라고 얘기했을 때, 설명을 받았습니다.
이때 그는 파이프 처리에 관련된 설명을 하면서 File Descriptor라는 용어를 사용해 설명하였는데, 나는 시스템 프로그래밍 기사나 책을 읽으면서 몇번 본 적은 있지만, file descriptor라는 단어를 내 입으로 조차 발음해 그 소리를 내 귀로 들은 적이 한 번도 없었는데, 이때 설명받으면서 들은 것이 난생 처음이었습니다.(그만큼 그 개념을 직접 말해 설명하는 것을 듣는 것이 굉장히 드믄 일입니다.)
3. 기타
<작성중>
1) 자기가 작성한 코드는 장해 발생때 대응하는 사람이 살펴보고 긴급히 수정해 대응할 수 있어야 하는 코드
2) '로직을 아직 다 못썼습니다.'
3) '단순한 버그이기 때문에 위치를 알면 곧 수정해 대응이 가능합니다.'
대신 환경(장비상의, 또는 시스템상의) 이나 데이타의 대응이 훨씬 더 큰 일.
서포트를 나가게 된 배경은 다음과 같습니다.
2008년 리만브러더스 파산과 더불어 시작된 불경기, 그리고 사내 파견사원의 감축과 정사원위주만으로의 운영, 신규프로젝트 발생과 기술부 리소스부족(perl과 python코딩에 대한), 개발부에 지원요청과 해당 경험이 있고 덜 중요한(?!) 리소스(바로 접니다)의 지원제공.
1. 굉장히 간결한 방식을 선호(shell script를 확장한 것과 같은 느낌의 프로그래밍.)
'심플한 것이 아름답다'라는 프로그래밍에서의 정석이 있습니다만, 정말 그것을 실천하려고 애를 씁니다. 특히, 한 줄 코드로 가능할 수 있다면, 그렇게 하려고 애를 씁니다. 여기서 몇가지 지금까지와는 다른 상식으로 진행되었는데, 예를 들면,
1) 가능하면 클래스는 사용하거나 작성하지 않습니다.
어차피 pointer를 tie하는 것에 지나지 않는 클래스를 생성하려고, new하는 한 줄의 코드를 작성하는 것은, 불필요한 리소스 낭비로 여기어 지는 것 같았습니다.
2) parameter는 주로 array of hash reference
hash reference인 것은 이해가 가지만, 그것의 array였다는 것은 좀 색달랐습니다.
3) 리턴값, int형 보다는 (rc, rm)의 배열.
rc는 return code, rm은 return message입니다.(간혹 엔지니어에 따라 rv 즉 return value로 사용하는 경우도 있었습니다.)
리턴이 perl의 subroutine이든, python의 method이든, 실패했을 경우 그 이유를 알기 위한 메시지를 함께 전달합니다. 실패라면 exception을 함께 전달하는 느낌입니다.
문제없이 진행되어 rc가 성공이라면, rm은 해당 리턴값을 가지게 하는 설계가 많았습니다.
4) 리턴값, 0 = 성공, 1 = 실패
이는 시스템 커맨드의 리턴(batch라면 errorlevel)이 대게 에러번호를 리턴하는데 기인합니다.
개발자로서의 인식으로는 non-zero = true, 0 = false 이기 때문에 checkData와 같은 함수의 리턴이 1(true)라면, OK라는 인식이지만, SE에게는 NG라는 인식입니다.
이는 정의하고 진행하면 되는 것이기 때문에 특별히 문제는 없었습니다만, "음? 성공하면 0입니까? (성공하면 false입니까?)"하고 물었을 때, '음? 당연한 것을 왜묻지?'하는 느낌의 반응은 약간의 이질감을 느끼게 되더군요.
2. 놀라운 시스템 관련 지식.
이것은 말할 것도 없습니다. (모든 SE가 다 그렇지는 아니겠지만) 굉장히 정확한 지식을 가지고 있었습니다.
이런 예가 있었습니다. 한번은 '어떤 명령어 | sed xxxxx'와 같은 외부 프로세스를 실행한 결과를 치환해 값을 받도록 실행하는 코드를 작성한 적이 있었습니다. 이때 다른 명령어는 모두 문제가 없었는데 어느 특정 한 명령어는 프로세스가 종료하지 않고 메모리에 남아 있게 되는 일이 있었습니다.
이를 SE에게 문의했는데, 추적하는 것을 보여주더군요. 값진 경험이었습니다.
우선, ps상 이 프로세스가 defunc가 아니었기 때문에(좀비가 아니었기 때문에) 폭주인지, 아니면 무엇을 하고 있는지 strace를 통해 pid에 걸어서 무엇을 하고 있는지 알아보더군요. 지금까지 나 이외에 strace를 사용하는 것을 '직접' 본 두번째 경험이었습니다.)
우선은 표준입력을 기다리고 있는 것을 알아내어 폭주는 아닌 것을 확인했습니다. 그다음 왜 표준입력을 기다리고 있는지 알아보았는데, 그 '특정 명렁어'가 표준 출력으로 출력하는 것을 모두 /dev/null로 돌려놓고 있었더군요. 결국 sed는 뭔가 파이프로 전해져 오는 것이 없었기 때문에 sed가 입력을 기다리고 있었고, child의 pid를 수확하지 못하고 있기 때문에 parent의 '특정 명령어' 및 shell이 살아남아 있는 것이었습니다.
이때 잠깐 질문을 제가 했는데, sed를 echo로 바꾸면 정상종료하는데, 그 차이를 잘 이해하지 못하다라고 얘기했을 때, 설명을 받았습니다.
이때 그는 파이프 처리에 관련된 설명을 하면서 File Descriptor라는 용어를 사용해 설명하였는데, 나는 시스템 프로그래밍 기사나 책을 읽으면서 몇번 본 적은 있지만, file descriptor라는 단어를 내 입으로 조차 발음해 그 소리를 내 귀로 들은 적이 한 번도 없었는데, 이때 설명받으면서 들은 것이 난생 처음이었습니다.(그만큼 그 개념을 직접 말해 설명하는 것을 듣는 것이 굉장히 드믄 일입니다.)
3. 기타
<작성중>
1) 자기가 작성한 코드는 장해 발생때 대응하는 사람이 살펴보고 긴급히 수정해 대응할 수 있어야 하는 코드
2) '로직을 아직 다 못썼습니다.'
3) '단순한 버그이기 때문에 위치를 알면 곧 수정해 대응이 가능합니다.'
대신 환경(장비상의, 또는 시스템상의) 이나 데이타의 대응이 훨씬 더 큰 일.
Thursday, September 17, 2009
which script language shall I choose?
어떤 언어를 주된 무기로 사용할까?
제가 생각하는 프로그래밍이란, 로직을 만드는 것(또는 일)이고,
프로그래밍 언어는 그 로직을 기록하는 Tool입니다.
이 정의만으로, 프로그래밍은 프로그래밍 언어 없이도(psudo code로) 할 수 있습니다.
그리고 정말 그렇다고 생각합니다.
프로그래밍 언어의 문법은 컴파일러가 사용하는 Parser의 Rule이고,
필요하다면 preprocessor를 만들어 더 간결하게 하는 것도 가능합니다.
즉 여기까지는, '문법만으로 프로그래밍언어를 선택하는 것'은 의미가 크지 않다고 생각합니다.
내장함수와 기초 클래스 라이브러리.
여기서부터는 꽤 중요해집니다.
우선 객체지향이 아닌 순차적프로그램에서 지원되는 내장함수는, 호환성때문에 업데이트가 자주 되지 않는다는 특징을 가지고 있습니다.(예를 들면, 그 유명한, javascript의 array의 length property, hash형식으로 사용할 때 엉뚱한 값을 리턴하더라도 유지되는.)
bash나 batch같은 shell script, perl, jscript, vbscript는 내장함수가 나타난 버전 이후로는 처음에 정의된 내용 그대로 거의 변화없이 사용되고 있습니다. (이는 어쩌면 장점일 수 있습니다.)
객체지향의 언어의 경우는, 기초 문법은 거의 그대로 유지하면서, 기초 클래스를 확장하거나 method를 override할 수도 있어, 순차적 프로그래밍 언어보다 비교적 더 잦은 업데이트(문법보다는 클래스쪽의)가 일어나는 특징이 있으며(역시 이는 단점일 수 있습니다.), 기초 클래스 라이브러리가 아니더라도 사용자가 만들어 배포하는 클래스는, 순차적 프로그래밍 언어의 라이브러리보다 더 응용해 접근하기 쉬운느낌입니다.(이것도 역시 단점일 수 있습니다. 프레임웍 수준의 사용자 정의 클래스 라이브러리의 등장, 그리고 난립은 축복이면서 동시에 재앙-가족과 사회에서 멀어지게 하는-입니다.)
또 순차지향적 프로그래밍 언어는, 작성하면서 곧 실행해 볼 수 있는 코드를 작성하는 경우기 많은 반면, 객체지향 언어는 바로 곧 실행해 볼 수 있는 코드를 작성한다라기 보다는, 라이브러리를 작성한다라는 느낌입니다.
----
어떤 개발언어의 레벨을 올려둘까 하고 고민했습니다.
이러한 고민을 한 계기로는 jscript로 작성한 개인의 Outlook관련 스크립트가 있는데, OutLook을 control하자니, COM을 다룰 수 있는 언어를 해야했고, JScript는 그다지 나쁘지 않은 선택이었습니다만,
Loop를 stop, start를 걸 수 있도록 하자니 여의치가 않더군요. VBS와 JScript에서는 Thread를 생성할 수가 없었습니다. OTL
지금까지 작성해 둔 것은 어쩔 수 없고, 다음에는 이런 작업으로 적절한 언어로 작업해야겠다하는 생각이 들어 어떤 것으로 할까 생각을 해보았습니다.
jscript, vbs는 앞으로도 많이 사용하겠지만, 윈도우즈환경에서만 돌아가므로 Pending
php만으로는 할 수 있는 것이 제한되어 php는 탈락
C, C++, MFC로는 스크립팅언어보다 손이 조금 더가므로 탈락
java자체로는 COM에 Access하도록 하자니 번거로운게 많아서 탈락.
유력한 후보는
perl, python, groovy(groovy는 Loop나 Daemon 형식으로 돌린다고 가정했을 때), ruby
결론
그중에 perl이 제일 유력했지만,
결론으로는 (나에게는) python.
왜냐하면
저는 일본OS를 사용합니다. 일본회사이고 회사에서 제공한 컴퓨터입니다.
일본OS에서 일본어를 사용하여 스크립트를 작성하는 경우는 거의 문제가 없지만,
한글을 사용하여 스크립트를 작성하는 경우, 문제가 발생하는 경우가 종종 있습니다.
또 저는 emmeditor의 매크로로 실행하게 하는 스크립트도 굉장히 많이 작성하는 편인데,
다른 언어로는 유니코드가 emeditor에서 지원되지 않는 한편(vbs와 jscript는 물론 지원합니다.), python은 유니코드를 emeditor에서 사용할 수 있었습니다.
evalpy
#!/usr/bin/python
a = [ "AAA", "BBB", "CCC", "똠방각하", u"똠방각하", "表示する", u"表示する"]
for i in a:
window.document.writeln( i )
AAA
BBB
CCC
・・ｩ・・葺
똠방각하
陦ｨ遉ｺ縺吶ｋ
表示する
그렇게 나쁜 선택은 아닌 것 같습니다만, 분명히 다른 언어로 작업하는 경우도 많을 것입니다.
제가 생각하는 프로그래밍이란, 로직을 만드는 것(또는 일)이고,
프로그래밍 언어는 그 로직을 기록하는 Tool입니다.
이 정의만으로, 프로그래밍은 프로그래밍 언어 없이도(psudo code로) 할 수 있습니다.
그리고 정말 그렇다고 생각합니다.
프로그래밍 언어의 문법은 컴파일러가 사용하는 Parser의 Rule이고,
필요하다면 preprocessor를 만들어 더 간결하게 하는 것도 가능합니다.
즉 여기까지는, '문법만으로 프로그래밍언어를 선택하는 것'은 의미가 크지 않다고 생각합니다.
내장함수와 기초 클래스 라이브러리.
여기서부터는 꽤 중요해집니다.
우선 객체지향이 아닌 순차적프로그램에서 지원되는 내장함수는, 호환성때문에 업데이트가 자주 되지 않는다는 특징을 가지고 있습니다.(예를 들면, 그 유명한, javascript의 array의 length property, hash형식으로 사용할 때 엉뚱한 값을 리턴하더라도 유지되는.)
bash나 batch같은 shell script, perl, jscript, vbscript는 내장함수가 나타난 버전 이후로는 처음에 정의된 내용 그대로 거의 변화없이 사용되고 있습니다. (이는 어쩌면 장점일 수 있습니다.)
객체지향의 언어의 경우는, 기초 문법은 거의 그대로 유지하면서, 기초 클래스를 확장하거나 method를 override할 수도 있어, 순차적 프로그래밍 언어보다 비교적 더 잦은 업데이트(문법보다는 클래스쪽의)가 일어나는 특징이 있으며(역시 이는 단점일 수 있습니다.), 기초 클래스 라이브러리가 아니더라도 사용자가 만들어 배포하는 클래스는, 순차적 프로그래밍 언어의 라이브러리보다 더 응용해 접근하기 쉬운느낌입니다.(이것도 역시 단점일 수 있습니다. 프레임웍 수준의 사용자 정의 클래스 라이브러리의 등장, 그리고 난립은 축복이면서 동시에 재앙-가족과 사회에서 멀어지게 하는-입니다.)
또 순차지향적 프로그래밍 언어는, 작성하면서 곧 실행해 볼 수 있는 코드를 작성하는 경우기 많은 반면, 객체지향 언어는 바로 곧 실행해 볼 수 있는 코드를 작성한다라기 보다는, 라이브러리를 작성한다라는 느낌입니다.
----
어떤 개발언어의 레벨을 올려둘까 하고 고민했습니다.
이러한 고민을 한 계기로는 jscript로 작성한 개인의 Outlook관련 스크립트가 있는데, OutLook을 control하자니, COM을 다룰 수 있는 언어를 해야했고, JScript는 그다지 나쁘지 않은 선택이었습니다만,
Loop를 stop, start를 걸 수 있도록 하자니 여의치가 않더군요. VBS와 JScript에서는 Thread를 생성할 수가 없었습니다. OTL
지금까지 작성해 둔 것은 어쩔 수 없고, 다음에는 이런 작업으로 적절한 언어로 작업해야겠다하는 생각이 들어 어떤 것으로 할까 생각을 해보았습니다.
jscript, vbs는 앞으로도 많이 사용하겠지만, 윈도우즈환경에서만 돌아가므로 Pending
php만으로는 할 수 있는 것이 제한되어 php는 탈락
C, C++, MFC로는 스크립팅언어보다 손이 조금 더가므로 탈락
java자체로는 COM에 Access하도록 하자니 번거로운게 많아서 탈락.
유력한 후보는
perl, python, groovy(groovy는 Loop나 Daemon 형식으로 돌린다고 가정했을 때), ruby
결론
그중에 perl이 제일 유력했지만,
결론으로는 (나에게는) python.
왜냐하면
저는 일본OS를 사용합니다. 일본회사이고 회사에서 제공한 컴퓨터입니다.
일본OS에서 일본어를 사용하여 스크립트를 작성하는 경우는 거의 문제가 없지만,
한글을 사용하여 스크립트를 작성하는 경우, 문제가 발생하는 경우가 종종 있습니다.
또 저는 emmeditor의 매크로로 실행하게 하는 스크립트도 굉장히 많이 작성하는 편인데,
다른 언어로는 유니코드가 emeditor에서 지원되지 않는 한편(vbs와 jscript는 물론 지원합니다.), python은 유니코드를 emeditor에서 사용할 수 있었습니다.
evalpy
#!/usr/bin/python
a = [ "AAA", "BBB", "CCC", "똠방각하", u"똠방각하", "表示する", u"表示する"]
for i in a:
window.document.writeln( i )
AAA
BBB
CCC
・・ｩ・・葺
똠방각하
陦ｨ遉ｺ縺吶ｋ
表示する
그렇게 나쁜 선택은 아닌 것 같습니다만, 분명히 다른 언어로 작업하는 경우도 많을 것입니다.
Wednesday, September 16, 2009
release, release, after release,
（Dev） Kim tonghyun says:
헉 못보던 책이네
nowhere527 says:
오늘 갔다와서 받은 거야 .. 자기는 점심 먹고??.
nowhere527 says:
괜챦아??.
（Dev） Kim tonghyun says:
응 다이죠부. 오늘 부터 정상퇴근.
（Dev） Kim tonghyun says:
어디 갔다온건데??
（Dev） Kim tonghyun says:
책 받고 너무 좋아하네
nowhere527 says:
애기 셋 있는 집 .. 승환이 신났음..
nowhere527 says:
하영이랑도 놀고 .. 좋았지 ..
nowhere527 says:
오는 내내 재잘재잘 ..
（Dev） Kim tonghyun says:
나루호도 나루호도
nowhere527 says:
간식도 마다하고 책 하고 있음..
nowhere527 says:
소세지는 내팽개침 ..
（Dev） Kim tonghyun says:
ㅋㅋㅋㅋㅋㅋㅋㅋ
Tuesday, September 15, 2009
Redmine - Issue grapgh
약 오픈 1개월 전부터 테스트팀을 조직해 진행한 결과입니다. 그 전까지는 개발부, 기술부, 자체 테스트였습니다. (이정도는 올려도 괜찮겠지....)
Sunday, September 13, 2009
개발프로젝트의 경험공유 : TestCase의 문제와 TestCase만으로 해결 할 수 없는 문제에 대한 풀이의 고안.
개발프로젝트의 경험공유
TestCase의 문제와 TestCase만으로 해결 할 수 없는 문제에 대한 풀이의 고안.
이번 프로젝트로 테스트팀이 개발팀 외부에 있을 경우에 품질에 대한 확신이 높아지는 것을 확인했습니다.
전체적인 진행에 대해서는 따로 포스트 하려고 합니다만, 여기서는 우선, 개인적으로 이번 프로젝트에서 얻은 성과를 공유하고자 합니다.
개인적으로는 이번 프로젝트에서 느낀 것은,
1) perl의 경우, 프로그램을 종료하지 않는, 대화식의 interactive한 테스트용 프로그램을 만들기가 훨씬 더 쉬웠으며
2) eval이 지원된다면 모듈을 hot deploy도 할 수 있고, 직접적인 함수의 사용 결과를 눈으로 볼 수도 있어 유연한 테스트를 할 수 있었습니다.
우선은 TestCase를 사용했습니다.
처음에는 제가 작성하는 Module의 함수의 테스트를, Perl에서의 Test Framework이라고 말 할 수 있는 Test::More를 통해서 했습니다.
이 테스트를 통과하면 업로드 했습니다. 처음에는 괜찮았는데, 나중에 가니 테스트프로그램의 훨씬 더 커졌버리더군요.
하나의 함수를 사용할 수 있는 경우가 여럿인 경우, 모두 통과하게 해야 했으니까요.
예를 들면, select, insert, update, delete하는 DAO형식의 함수 4개를 만들었다고 할 때,
테스트 해야하는 항목으로는, 각 DAO의 함수에 대해 Parameter가 null일때, Parameter의 type이 잘 못되었을 때, Parameter의 조건이 안맞을 때
또, Data가 이미 있는데 insert하려 할 때, 없는데 update하려 할 때, 등등으로 4개함수당 테스트 해야할 케이스가 평균 50여개 정도가 나왔습니다.
이번 프로젝트에서는 외부로 공개해야하는 함수(perl에서는 subroutine)은 182개, 내부적으로 사용하는 것까지 합하면 작성한 함수는 약 220여개 정도가 되었습니다.
물론 만들어 놓고 보니, 납품하는 입장에서도 안심은 되더군요. 그러나 매우 노가다성 작업이라는 것을 알았습니다.
작성이 완료되었는데, 인터페이스상, Parameter가 하나 늘거나 또는 줄거나 하면(물론 parameter의 hash값의 key/value가 늘거나 줄거나 하는 것입니다.),
모듈만 수정하는 것보다, 테스트를 수정하는 것이 큰 일이었습니다.
TestCase만으로는 해결할 수 없는 문제.
문제는 또 있었습니다.
함수의 동작에는 문제가 없는데, 이를 사용해 조합하는 부분에서 잘 못 사용해서, 로그에는 제가 작성한 함수의 부분에서 출력하는 문자열이 남아서, 저에게 Bug Assign되는 것이었습니다.
조합하는 부분의 담당 개발자에게 api 인터페이스 문서를 보고 고치라고 강요할 수도 있지만,
결국은, 조합하는 부분의 코드를 어떻게 작성했는 지, 직접 열어보고야 말았습니다. (여기서 기가막혔습니다. perl 1만줄!)
이때는 실전에서 전달되는 값에 대한 테스트는 Test case로는 할 수 없습니다.
보통 이때의 디버깅 방법은
(1)console이나 파일로 값을 출력하게 하는 부분을 넣고, 다시 돌려보는 것이 일반적입니다.
(2)좀 더 똑똑하게 로그 파일로 출력하게 하는 경우도 있습니다. (그러나 웹과 같이 그 뒤에 요청되는 다른 request를 처리하는 로그가 계속 쌓이면 찾아보기 어렵습니다.)
(3)그보다 좀 더 수준높게 Debugger를 돌려 Trace하는 방법이 있습니다. 어쩌면 Perl에서 사용하기 쉬운 Debugger가 있었다면 이를 사용했을 지도 모릅니다.
우선, 조합하는 부분의 소스는 제가 직접 손 대는 것이 적합하지 않았습니다. 왜냐하면 계속 작업중이었기 때문이죠.
복사해서 로컬에서 수정해 볼 수는 있지만, 실전 DB의 값을 사용해 돌리게 하면, 시스템이 이상해 질 수도 있는 문제였습니다.
그렇다고 테스트 DB만 있으면 해결 할 수 있는 것도 아니었습니다. 가상머신을 생성하는 등, system call하는 부분이 많기 때문에, 적합한 환경이 제공되지 않으면, 기동하는 것도 불가능했습니다.
그래서 저는 이번에는 조그만 interactive한 프로그램(while(true)문으로 입력을 기다리고, 받아서 처리하고 다시 입력을 기다리고.. 하는 프로그램입니다.)을 만들어서, 현재의 실전 환경에서 이러한 값을 넣었을 경우, 함수가 어떻게 동작하는지 알아보는 방법을 취했습니다.
그리고 실전환경과 같은 함수에 데이타를 넣어보기 위해, 실행할 문장을 입력받아 실행하도록 eval을 사용했습니다.
이 방법은 매우 유연한 입력을 받을 수 있어서 테스트 하기에 아주 적합하다는 것을 알았습니다.
이번 경험의 확장
interactive한 프로그램은 perl로만 가능한 것이 아니라 어떤 언어든 가능합니다만,
eval은 그렇지 않습니다. eval은 주로 scripting언어에만 존재합니다.
compile언어에서는 실시간으로 해석하지 않고 컴파일된 코드를 수행하는 것이기 때문에 scripting언어보다 더 나은 퍼포먼스를 보이는 것이니까요.
그런데, java에서는 eval은 없지만, groovy에서 Eval 클래스가 있는 것을 알았습니다.
또 class의 핫디플로이라면 classloader의 loadClassData()를 직접 호출해서 hot deploy를 구현하면 될 것 같습니다.
그리고 닷넷 4.0에서는 Scripting을 지원한다고 하는데 어떻게 지원되는 지 아직 살펴보고 있지 않습니다.
c/c++에서는 아무래도 어렵지 않을까 싶습니다. (perl에서 inline c를 사용하는 방법으로 응용할 수 있을지. 어떨까 싶습니다.)
이러한 경험이, 다른 개발을 담당하시는 분들께 도움이 되었으면 하고, 정보공유합니다.
아직 개발이 완료된 것은 아닙니다. 좀 작업은 남아 있습니다.
좀 더 다른 느낀 점이 있다면 공유하겠습니다.
그리고...
저는, 개발경험 이외의 것이 더 큰 수확입니다. (다음번 포스트에서 적어볼가 합니다.)
개발경험도 개발경험이지만, 개발은 다른 사람에게 맡기고,
전체적으로 프로젝트를 지휘하는 것이 훨씬 재미있겠다라는 생각이 들었습니다.
이상.
정보공유 끝.
TestCase의 문제와 TestCase만으로 해결 할 수 없는 문제에 대한 풀이의 고안.
이번 프로젝트로 테스트팀이 개발팀 외부에 있을 경우에 품질에 대한 확신이 높아지는 것을 확인했습니다.
전체적인 진행에 대해서는 따로 포스트 하려고 합니다만, 여기서는 우선, 개인적으로 이번 프로젝트에서 얻은 성과를 공유하고자 합니다.
개인적으로는 이번 프로젝트에서 느낀 것은,
1) perl의 경우, 프로그램을 종료하지 않는, 대화식의 interactive한 테스트용 프로그램을 만들기가 훨씬 더 쉬웠으며
2) eval이 지원된다면 모듈을 hot deploy도 할 수 있고, 직접적인 함수의 사용 결과를 눈으로 볼 수도 있어 유연한 테스트를 할 수 있었습니다.
우선은 TestCase를 사용했습니다.
처음에는 제가 작성하는 Module의 함수의 테스트를, Perl에서의 Test Framework이라고 말 할 수 있는 Test::More를 통해서 했습니다.
이 테스트를 통과하면 업로드 했습니다. 처음에는 괜찮았는데, 나중에 가니 테스트프로그램의 훨씬 더 커졌버리더군요.
하나의 함수를 사용할 수 있는 경우가 여럿인 경우, 모두 통과하게 해야 했으니까요.
예를 들면, select, insert, update, delete하는 DAO형식의 함수 4개를 만들었다고 할 때,
테스트 해야하는 항목으로는, 각 DAO의 함수에 대해 Parameter가 null일때, Parameter의 type이 잘 못되었을 때, Parameter의 조건이 안맞을 때
또, Data가 이미 있는데 insert하려 할 때, 없는데 update하려 할 때, 등등으로 4개함수당 테스트 해야할 케이스가 평균 50여개 정도가 나왔습니다.
이번 프로젝트에서는 외부로 공개해야하는 함수(perl에서는 subroutine)은 182개, 내부적으로 사용하는 것까지 합하면 작성한 함수는 약 220여개 정도가 되었습니다.
물론 만들어 놓고 보니, 납품하는 입장에서도 안심은 되더군요. 그러나 매우 노가다성 작업이라는 것을 알았습니다.
작성이 완료되었는데, 인터페이스상, Parameter가 하나 늘거나 또는 줄거나 하면(물론 parameter의 hash값의 key/value가 늘거나 줄거나 하는 것입니다.),
모듈만 수정하는 것보다, 테스트를 수정하는 것이 큰 일이었습니다.
TestCase만으로는 해결할 수 없는 문제.
문제는 또 있었습니다.
함수의 동작에는 문제가 없는데, 이를 사용해 조합하는 부분에서 잘 못 사용해서, 로그에는 제가 작성한 함수의 부분에서 출력하는 문자열이 남아서, 저에게 Bug Assign되는 것이었습니다.
조합하는 부분의 담당 개발자에게 api 인터페이스 문서를 보고 고치라고 강요할 수도 있지만,
결국은, 조합하는 부분의 코드를 어떻게 작성했는 지, 직접 열어보고야 말았습니다. (여기서 기가막혔습니다. perl 1만줄!)
이때는 실전에서 전달되는 값에 대한 테스트는 Test case로는 할 수 없습니다.
보통 이때의 디버깅 방법은
(1)console이나 파일로 값을 출력하게 하는 부분을 넣고, 다시 돌려보는 것이 일반적입니다.
(2)좀 더 똑똑하게 로그 파일로 출력하게 하는 경우도 있습니다. (그러나 웹과 같이 그 뒤에 요청되는 다른 request를 처리하는 로그가 계속 쌓이면 찾아보기 어렵습니다.)
(3)그보다 좀 더 수준높게 Debugger를 돌려 Trace하는 방법이 있습니다. 어쩌면 Perl에서 사용하기 쉬운 Debugger가 있었다면 이를 사용했을 지도 모릅니다.
우선, 조합하는 부분의 소스는 제가 직접 손 대는 것이 적합하지 않았습니다. 왜냐하면 계속 작업중이었기 때문이죠.
복사해서 로컬에서 수정해 볼 수는 있지만, 실전 DB의 값을 사용해 돌리게 하면, 시스템이 이상해 질 수도 있는 문제였습니다.
그렇다고 테스트 DB만 있으면 해결 할 수 있는 것도 아니었습니다. 가상머신을 생성하는 등, system call하는 부분이 많기 때문에, 적합한 환경이 제공되지 않으면, 기동하는 것도 불가능했습니다.
그래서 저는 이번에는 조그만 interactive한 프로그램(while(true)문으로 입력을 기다리고, 받아서 처리하고 다시 입력을 기다리고.. 하는 프로그램입니다.)을 만들어서, 현재의 실전 환경에서 이러한 값을 넣었을 경우, 함수가 어떻게 동작하는지 알아보는 방법을 취했습니다.
그리고 실전환경과 같은 함수에 데이타를 넣어보기 위해, 실행할 문장을 입력받아 실행하도록 eval을 사용했습니다.
이 방법은 매우 유연한 입력을 받을 수 있어서 테스트 하기에 아주 적합하다는 것을 알았습니다.
이번 경험의 확장
interactive한 프로그램은 perl로만 가능한 것이 아니라 어떤 언어든 가능합니다만,
eval은 그렇지 않습니다. eval은 주로 scripting언어에만 존재합니다.
compile언어에서는 실시간으로 해석하지 않고 컴파일된 코드를 수행하는 것이기 때문에 scripting언어보다 더 나은 퍼포먼스를 보이는 것이니까요.
그런데, java에서는 eval은 없지만, groovy에서 Eval 클래스가 있는 것을 알았습니다.
또 class의 핫디플로이라면 classloader의 loadClassData()를 직접 호출해서 hot deploy를 구현하면 될 것 같습니다.
그리고 닷넷 4.0에서는 Scripting을 지원한다고 하는데 어떻게 지원되는 지 아직 살펴보고 있지 않습니다.
c/c++에서는 아무래도 어렵지 않을까 싶습니다. (perl에서 inline c를 사용하는 방법으로 응용할 수 있을지. 어떨까 싶습니다.)
이러한 경험이, 다른 개발을 담당하시는 분들께 도움이 되었으면 하고, 정보공유합니다.
아직 개발이 완료된 것은 아닙니다. 좀 작업은 남아 있습니다.
좀 더 다른 느낀 점이 있다면 공유하겠습니다.
그리고...
저는, 개발경험 이외의 것이 더 큰 수확입니다. (다음번 포스트에서 적어볼가 합니다.)
개발경험도 개발경험이지만, 개발은 다른 사람에게 맡기고,
전체적으로 프로젝트를 지휘하는 것이 훨씬 재미있겠다라는 생각이 들었습니다.
이상.
정보공유 끝.
Wednesday, September 9, 2009
ssh for win32 cmd console
여러 전문 ssh용 프로그램이 있습니다만, 특별히 애용하거나, 싫어하거나 하는 것은 없습니다만, 주로 사용하는 것은 poderosa와 콘솔용 ssh입니다.
콘솔용 ssh는 rsync의 win32버전인 cwRsync에 딸려오는 ssh를 사용하고 있습니다. 아마도 cygwin을 설치했다면 같은 것이기 때문에 아무거나 상관없을 것입니다.
poderosa는 닷넷언어로 매크로가 가능하기 때문이고,
콘솔용 ssh의 장점이라면, 메모리를 적게 차지하고, ssh.exe는 표준 출력을 사용하기 때문에, 자기가 좋아하는 언어로, 입출력을 control하기 위해 접근할 수 있는 것이 장점입니다.
(putty도 가볍긴 하지만, 표준 출력을 사용하는 것이 아니기 때문에, 입출력을 control하는 데는 문제가 있습니다.)
큰 단점은 아니지만, 단점이라면 콘솔에서 지원하는 인코딩만을 사용해야 하는데, 주로 LANG=C나 LC_ALL=C를 주고 영어로만 사용하고 있습니다.
아. 그리고 Keep Alive가 안된다...
가끔 사람들이 윈도우 콘솔에서 SSH연결해 하는 걸 보면 신기하게 보고 갑니다. ^^;
콘솔용 ssh는 rsync의 win32버전인 cwRsync에 딸려오는 ssh를 사용하고 있습니다. 아마도 cygwin을 설치했다면 같은 것이기 때문에 아무거나 상관없을 것입니다.
poderosa는 닷넷언어로 매크로가 가능하기 때문이고,
콘솔용 ssh의 장점이라면, 메모리를 적게 차지하고, ssh.exe는 표준 출력을 사용하기 때문에, 자기가 좋아하는 언어로, 입출력을 control하기 위해 접근할 수 있는 것이 장점입니다.
(putty도 가볍긴 하지만, 표준 출력을 사용하는 것이 아니기 때문에, 입출력을 control하는 데는 문제가 있습니다.)
큰 단점은 아니지만, 단점이라면 콘솔에서 지원하는 인코딩만을 사용해야 하는데, 주로 LANG=C나 LC_ALL=C를 주고 영어로만 사용하고 있습니다.
아. 그리고 Keep Alive가 안된다...
가끔 사람들이 윈도우 콘솔에서 SSH연결해 하는 걸 보면 신기하게 보고 갑니다. ^^;
text file containing text files
내 에디터의 화면(현황)
지금 현재의 회사 컴퓨터의 에디터 화면입니다. 열어놓은 문서가 너무 많습니다.
그중에서도 제목없는 문서들이 굉장히 많습니다.
이 제목없는 문서들에도 필요한 내용들이 담겨 있는데, 대게 화일로 저장하지 않고 실행해본 스크립트언어의 코드들이 들어 있습니다.
(emeditor가 지원하는 WSH(즉, jscript나 vbscript)로 문서의 저장여부에 상관없이 현재 작성중인 ActiveDocument의 내용을 Windows Scripting Control에 전달해 실행해 보는 것이 가능합니다.)
전에는 Tab을 한줄로 하고, 기본으로 제공하는 Open Documents Plug-in을 사용해 보기도 했습니다만, Open Documents Plug-in으로도 창의 세로폭으로 나열할 수 있는 양보다 더 많은 문서를 열면 Scroll bar가 생기는데, Scroll bar로 올렸다 내렸다 하며 찾아 클릭해 activate시키는 것이 훨씬 더 불편하더군요 그래서 그냥 위의 이미지 대로 이렇게 쓰고 있었습니다.
그런데, 오늘 퇴근하면서 생각한 것입니다만, 하나의 에디터 창에 여러개의 문서를 함께 가지고 있으면 안될까 하는 생각이 들었습니다.
현대인에게의 (휴먼 인터페이스로서의)파일시스템(현황을 고찰)
우리가 현재 쓰고 있는 파일시스템은 User가 사용하는 인터페이스에 있어서 꽤 오래전의 그것과 크게 다르지 않습니다. 디렉토리가 있고, 파일이 있고, 하나의 파일에는 하나의 내용이 있습니다.
파일의 역할에 맞는 파일의 확장명이 있고, 이 확장명에 따라 기대되는 사용방법이 있습니다. (shell에 따라 shebang으로 기대하는 역할을 부여하기도 합니다.)
이러한 방식은, 컴퓨터에게 있어서는 꽤나 적합한 설계이고, 그렇기 때문에 지금까지도 이 방식이 사용되고 있는 것이라고 생각합니다..
그런데, 컴퓨터의 용량이 커지고,고속화된 지금. (그것도 C언어가 고안되던 70년대에 비하면 매우매우.) 전문직업인으로 컴퓨터를 다루는 사람에게는 매우 많은 파일을 다루게 되는 일이 많습니다.
오나마에의 스즈끼상은 이클립스를 2년째 정도 끈 적이 없는데, 언제나 열려있는 파일의 갯수는
50+ 라고 나옵니다. (100개 정도를 닫아보았는데도 50+로 표시되는 것이 똑같습니다.)
Legacy팀의 Gohko상은 vim를 잘 다루는데, 여러 디렉토리와 파일로 나누어 관리하는 것이 vim로는 귀찮았는지(vim은 훌륭한 에디터이지만, 여러 파일을 다루기는 역시 좀 귀찮겠지... 싶습니다.) 하나의 파일에 몽땅 적습니다. (그리고 나는 이 방식이 좋지 않다고 생각합니다.) 지금 작업중인 프로젝트에서는 perl 스크립트 코드가 1만줄이 넘었습니다. OTL.
Hmmm.....(문제를 일반화)
컴퓨터가 작업하는 단위로서 파일이라는 단위는 꽤 적합하다라고 생각한다고 얘기했습니다.
그런데, 전문 직업인이 작업으로 생각하고 있는 하나의 작업은 하나의 파일 이상일 때가 있습니다.
예를 들면 c언어의 프로그래밍에서 c파일은 대게 c파일과 h파일, make파일로 나뉩니다.
자바등과 같이 객체지향의 프로그래밍의 경우라면, 전통적인 방법으로 하나의 파일에 하나의 public 클래스를 가지도록 구성하지만, 작업의 단위라면 여러개의 클래스가 동시에 손대야 할 경우가 생깁니다.(interface와 class, abstract class의 구분도 그렇고, BL, DAO의 구분도 그렇습니다. ant니 properties니 xml이니 하는 것 까지 생각하면 더욱 그렇습니다.)
aspx파일과 그 code behind파일도 그렇구요.
그렇다면?
그렇다면 에디터에서의 하나의 편집중인 Document는, 여러개의 문서의 내용을 포함하고 있으면 어떨까 하는 것을 생각해 보았습니다.
SDI를 바탕으로 하는 MDI(고안)
단순하게 생각해 보았습니다.
하나의 SDI인 ActiveDocument에서, 파일을 구분하는 markup이 있으면, 하고 말입니다.
즉, 하나의 텍스트 파일이 작은 project파일과 같이 작동하는 방법입니다.
이렇게 말이죠.
<file path="c:\temp\makefile">
</file>
<file path="c:\temp\test.h">
</file>
<file path="c:\temp\test.c">
</file>
<file path="${ActiveDocument.Path}\makefile">
</file>
save를 하면 덩치가 큰 이 파일하나와 각 markup에 있는 파일들이 생성 또는 update되도록 하는 것이 기본 조건입니다.
이 방식으로는 100개 이상의 파일이니, 1만줄이니 하는 그런 큰 규모의 프로젝트를 하나의 SDI로 대체할 수는 없습니다만, 작업의 단위로 나눠 사용하기에는 나쁘지 않을까 합니다.
준비해야할 매크로로는
현재 커서가 있는 부분의 파일을 save 하는 매크로
현재 커서가 있는 부분의 파일을 load 하는 매크로
ActiveDocument가 포함하고 있는 파일을 전부 save 하는 매크로
실행커맨드가 있는 부분의 내용을 실행하는 매크로
등이 있으면 편리하겠군요.
아이디어는 여기까지 입니다만, 효율성이 많이 좋을 지는 사용해 봐야 알겠습니다.
#적어도 lex & yacc작업할 때는 편해지겠다는 생각이 듭니다.
지금 현재의 회사 컴퓨터의 에디터 화면입니다. 열어놓은 문서가 너무 많습니다.
그중에서도 제목없는 문서들이 굉장히 많습니다.
이 제목없는 문서들에도 필요한 내용들이 담겨 있는데, 대게 화일로 저장하지 않고 실행해본 스크립트언어의 코드들이 들어 있습니다.
(emeditor가 지원하는 WSH(즉, jscript나 vbscript)로 문서의 저장여부에 상관없이 현재 작성중인 ActiveDocument의 내용을 Windows Scripting Control에 전달해 실행해 보는 것이 가능합니다.)
전에는 Tab을 한줄로 하고, 기본으로 제공하는 Open Documents Plug-in을 사용해 보기도 했습니다만, Open Documents Plug-in으로도 창의 세로폭으로 나열할 수 있는 양보다 더 많은 문서를 열면 Scroll bar가 생기는데, Scroll bar로 올렸다 내렸다 하며 찾아 클릭해 activate시키는 것이 훨씬 더 불편하더군요 그래서 그냥 위의 이미지 대로 이렇게 쓰고 있었습니다.
그런데, 오늘 퇴근하면서 생각한 것입니다만, 하나의 에디터 창에 여러개의 문서를 함께 가지고 있으면 안될까 하는 생각이 들었습니다.
현대인에게의 (휴먼 인터페이스로서의)파일시스템(현황을 고찰)
우리가 현재 쓰고 있는 파일시스템은 User가 사용하는 인터페이스에 있어서 꽤 오래전의 그것과 크게 다르지 않습니다. 디렉토리가 있고, 파일이 있고, 하나의 파일에는 하나의 내용이 있습니다.
파일의 역할에 맞는 파일의 확장명이 있고, 이 확장명에 따라 기대되는 사용방법이 있습니다. (shell에 따라 shebang으로 기대하는 역할을 부여하기도 합니다.)
이러한 방식은, 컴퓨터에게 있어서는 꽤나 적합한 설계이고, 그렇기 때문에 지금까지도 이 방식이 사용되고 있는 것이라고 생각합니다..
그런데, 컴퓨터의 용량이 커지고,고속화된 지금. (그것도 C언어가 고안되던 70년대에 비하면 매우매우.) 전문직업인으로 컴퓨터를 다루는 사람에게는 매우 많은 파일을 다루게 되는 일이 많습니다.
오나마에의 스즈끼상은 이클립스를 2년째 정도 끈 적이 없는데, 언제나 열려있는 파일의 갯수는
50+ 라고 나옵니다. (100개 정도를 닫아보았는데도 50+로 표시되는 것이 똑같습니다.)
Legacy팀의 Gohko상은 vim를 잘 다루는데, 여러 디렉토리와 파일로 나누어 관리하는 것이 vim로는 귀찮았는지(vim은 훌륭한 에디터이지만, 여러 파일을 다루기는 역시 좀 귀찮겠지... 싶습니다.) 하나의 파일에 몽땅 적습니다. (그리고 나는 이 방식이 좋지 않다고 생각합니다.) 지금 작업중인 프로젝트에서는 perl 스크립트 코드가 1만줄이 넘었습니다. OTL.
Hmmm.....(문제를 일반화)
컴퓨터가 작업하는 단위로서 파일이라는 단위는 꽤 적합하다라고 생각한다고 얘기했습니다.
그런데, 전문 직업인이 작업으로 생각하고 있는 하나의 작업은 하나의 파일 이상일 때가 있습니다.
예를 들면 c언어의 프로그래밍에서 c파일은 대게 c파일과 h파일, make파일로 나뉩니다.
자바등과 같이 객체지향의 프로그래밍의 경우라면, 전통적인 방법으로 하나의 파일에 하나의 public 클래스를 가지도록 구성하지만, 작업의 단위라면 여러개의 클래스가 동시에 손대야 할 경우가 생깁니다.(interface와 class, abstract class의 구분도 그렇고, BL, DAO의 구분도 그렇습니다. ant니 properties니 xml이니 하는 것 까지 생각하면 더욱 그렇습니다.)
aspx파일과 그 code behind파일도 그렇구요.
그렇다면?
그렇다면 에디터에서의 하나의 편집중인 Document는, 여러개의 문서의 내용을 포함하고 있으면 어떨까 하는 것을 생각해 보았습니다.
SDI를 바탕으로 하는 MDI(고안)
단순하게 생각해 보았습니다.
하나의 SDI인 ActiveDocument에서, 파일을 구분하는 markup이 있으면, 하고 말입니다.
즉, 하나의 텍스트 파일이 작은 project파일과 같이 작동하는 방법입니다.
이렇게 말이죠.
<file path="c:\temp\makefile">
</file>
<file path="c:\temp\test.h">
</file>
<file path="c:\temp\test.c">
</file>
<file path="${ActiveDocument.Path}\makefile">
</file>
save를 하면 덩치가 큰 이 파일하나와 각 markup에 있는 파일들이 생성 또는 update되도록 하는 것이 기본 조건입니다.
이 방식으로는 100개 이상의 파일이니, 1만줄이니 하는 그런 큰 규모의 프로젝트를 하나의 SDI로 대체할 수는 없습니다만, 작업의 단위로 나눠 사용하기에는 나쁘지 않을까 합니다.
준비해야할 매크로로는
현재 커서가 있는 부분의 파일을 save 하는 매크로
현재 커서가 있는 부분의 파일을 load 하는 매크로
ActiveDocument가 포함하고 있는 파일을 전부 save 하는 매크로
실행커맨드가 있는 부분의 내용을 실행하는 매크로
등이 있으면 편리하겠군요.
아이디어는 여기까지 입니다만, 효율성이 많이 좋을 지는 사용해 봐야 알겠습니다.
#적어도 lex & yacc작업할 때는 편해지겠다는 생각이 듭니다.
Tuesday, September 1, 2009
본부장의 고민과 RedMine
현재 근무하고 있는 곳에서 재미있는 시도를 하고 있습니다.
지금의 회사에서는 메일을 지금껏 일해본 여느 회사보다 더 많이 사용합니다.
거의 모든 작업의뢰는 메일을 사용하여 전달하는 것을 기본으로 하고, CC도 굉장히 많이 입력합니다.
메일로 보고되는 것은 구두로 보고되는 것과 동일시 하게 취급됩니다.
메일의 사용에 있어, 특별히 교육받은 것은 없습니다만, 상식으로 여겨지고 있다라고 생각되는 것들이 몇가지 있는데,
예를 들면, 팀 멤버가 발송하는 메일은 누구에게 발송하든 CC로 팀 매니저를 넣는 것을 원칙으로 하고 있는 것 같습니다.
팀 매니저도 또한 관련된 모든 팀원은 CC로 넣어서 발송합니다. 또 팀간의 조정이 필요한 경우에는 부서장을 CC로 입력합니다.
CC가 없는 메일은 매우 드믑니다. 예를 들면, 패스워드를 전달하는 메일정도일까.
작업의 전달은 구두 + 메일을 원칙으로 합니다. 대인 접촉을 어려워하는 일본인의 특성이 더해져 있달까(plus 엔지니어의 특성),
구두 전달은 생략될 수 있습니다.
만일 전달이 명확하지 않은 경우는 받은 쪽에서 미팅을 의뢰합니다. 이 의뢰도 역시 메일로 전달이 됩니다.
여기서, 본부장의 고민이 발생했나봅니다.
메일로 보고는 되고있고, 정기적으로 매니저들간의 회의를 통해 이를 파악하고 있기는 하지만,
어느 부서가 어느 부서에게 어떤 의뢰를 받아 어떤 작업을 하고 있고, 어떤 이슈가 얼마만큼 로드가 걸려있고, 그 각각의 진행은 어떻게 되어 가고 있는 지,
부서의 Resource를 어디에 어떻게 운영해야 적절한 판단이 되고, 어느 시기에 어떻게 Resource를 충당해야 할 지 파악하기 어려웠나봅니다.
어느 팀이 사람이 없다라고 호소를 해도, 매 분기별 평가를 통해 팀의 성과를 평가하는 자료로도, 메일과 미팅으로만은 부족하고, 뭔가 다른 툴이 필요하다고 느꼈던 것 같습니다.
그래서 최근, Redmine을 통한 전체의 Activity를 일람해 보고자 하는 시도가 이루어졌습니다.
각 팀별, 세부 부서별, 프로젝트별 티켓시스템이라던지는 존재했었습니다만, 부서 전체에 대한 시도는 아직 없었습니다.
원래 Redmine은 프로젝트 툴입니다. 엔지니어라면 Trac을 선호하는 사람도 있겠습니다만, Calender와 Gantt등을 지원하는 Redmine쪽이 관리자의 측면에 좀 더 매리트가 있다는데 동의합니다.
이 툴의 도입에서 빛나는 부분은 부서간의 Activity를 한 눈에 알 수 있다라는 것입니다.
설정은
메인 프로젝트로 시스템본부,
서브프로젝트로 각각의 부서와 팀을 넣습니다. 이 프로젝트들은 실제 프로젝트가 아니라 부서를 대표하고 이슈를 관리하는 것이니, 부서, 팀이 존재하는 한 종료되지 않는 프로젝트가 됩니다.
멤버로는 시스템본부의 멤버 전원, 사업부의 멤버 전원, 그리고 몇명의 재무부와 인사부의 인원이 멤버로 등록되어 있습니다.
이슈로는 내부적으로 발생하는 작업이 아닌 부서간의 의뢰의 내용을 적습니다.
Issue Tracking Item으로는 다음과 같은 내용이 있습니다.
상재 서버 상태 확인 의뢰:
상재 서버의 설정 변경 의뢰:
상재 서버의 어플리케이션 거동 확인 의뢰:
데이터 추출 의뢰:
멘테넌스 대응 의뢰:
사내 메일 로그 조사 의뢰:
사전 상담:
장해에 관련하는 조사 의뢰:
돌발적인 작업 의뢰:
청구 관련의 처리 의뢰:
각 팀원이 이 시스템의 사용에 익숙해지기까지는 조금 시간이 걸리겠지요.
그러나 어떤 부서가 어떤작업을 하고 있는 지 한눈에 알기 쉽다라는 느낌입니다.
회사의 시스템을 캡춰해 계재할 수 없는 것이 안타깝습니다.
RedMine을 사용한 프로젝트는 여러차례 경험해 보았습니다만, 이러한 사용방식은 처음이었고, 꽤 Smart하다고 생각합니다.
비슷한 고민을 하고 있다면, 한 번쯤 도입을 연구해 보는 것도 좋다라고 생각합니다.
어쩌면 이미 사용하고 있는 곳이 벌써 많은지도.
지금의 회사에서는 메일을 지금껏 일해본 여느 회사보다 더 많이 사용합니다.
거의 모든 작업의뢰는 메일을 사용하여 전달하는 것을 기본으로 하고, CC도 굉장히 많이 입력합니다.
메일로 보고되는 것은 구두로 보고되는 것과 동일시 하게 취급됩니다.
메일의 사용에 있어, 특별히 교육받은 것은 없습니다만, 상식으로 여겨지고 있다라고 생각되는 것들이 몇가지 있는데,
예를 들면, 팀 멤버가 발송하는 메일은 누구에게 발송하든 CC로 팀 매니저를 넣는 것을 원칙으로 하고 있는 것 같습니다.
팀 매니저도 또한 관련된 모든 팀원은 CC로 넣어서 발송합니다. 또 팀간의 조정이 필요한 경우에는 부서장을 CC로 입력합니다.
CC가 없는 메일은 매우 드믑니다. 예를 들면, 패스워드를 전달하는 메일정도일까.
작업의 전달은 구두 + 메일을 원칙으로 합니다. 대인 접촉을 어려워하는 일본인의 특성이 더해져 있달까(plus 엔지니어의 특성),
구두 전달은 생략될 수 있습니다.
만일 전달이 명확하지 않은 경우는 받은 쪽에서 미팅을 의뢰합니다. 이 의뢰도 역시 메일로 전달이 됩니다.
여기서, 본부장의 고민이 발생했나봅니다.
메일로 보고는 되고있고, 정기적으로 매니저들간의 회의를 통해 이를 파악하고 있기는 하지만,
어느 부서가 어느 부서에게 어떤 의뢰를 받아 어떤 작업을 하고 있고, 어떤 이슈가 얼마만큼 로드가 걸려있고, 그 각각의 진행은 어떻게 되어 가고 있는 지,
부서의 Resource를 어디에 어떻게 운영해야 적절한 판단이 되고, 어느 시기에 어떻게 Resource를 충당해야 할 지 파악하기 어려웠나봅니다.
어느 팀이 사람이 없다라고 호소를 해도, 매 분기별 평가를 통해 팀의 성과를 평가하는 자료로도, 메일과 미팅으로만은 부족하고, 뭔가 다른 툴이 필요하다고 느꼈던 것 같습니다.
그래서 최근, Redmine을 통한 전체의 Activity를 일람해 보고자 하는 시도가 이루어졌습니다.
각 팀별, 세부 부서별, 프로젝트별 티켓시스템이라던지는 존재했었습니다만, 부서 전체에 대한 시도는 아직 없었습니다.
원래 Redmine은 프로젝트 툴입니다. 엔지니어라면 Trac을 선호하는 사람도 있겠습니다만, Calender와 Gantt등을 지원하는 Redmine쪽이 관리자의 측면에 좀 더 매리트가 있다는데 동의합니다.
이 툴의 도입에서 빛나는 부분은 부서간의 Activity를 한 눈에 알 수 있다라는 것입니다.
설정은
메인 프로젝트로 시스템본부,
서브프로젝트로 각각의 부서와 팀을 넣습니다. 이 프로젝트들은 실제 프로젝트가 아니라 부서를 대표하고 이슈를 관리하는 것이니, 부서, 팀이 존재하는 한 종료되지 않는 프로젝트가 됩니다.
멤버로는 시스템본부의 멤버 전원, 사업부의 멤버 전원, 그리고 몇명의 재무부와 인사부의 인원이 멤버로 등록되어 있습니다.
이슈로는 내부적으로 발생하는 작업이 아닌 부서간의 의뢰의 내용을 적습니다.
Issue Tracking Item으로는 다음과 같은 내용이 있습니다.
상재 서버 상태 확인 의뢰:
상재 서버의 설정 변경 의뢰:
상재 서버의 어플리케이션 거동 확인 의뢰:
데이터 추출 의뢰:
멘테넌스 대응 의뢰:
사내 메일 로그 조사 의뢰:
사전 상담:
장해에 관련하는 조사 의뢰:
돌발적인 작업 의뢰:
청구 관련의 처리 의뢰:
각 팀원이 이 시스템의 사용에 익숙해지기까지는 조금 시간이 걸리겠지요.
그러나 어떤 부서가 어떤작업을 하고 있는 지 한눈에 알기 쉽다라는 느낌입니다.
회사의 시스템을 캡춰해 계재할 수 없는 것이 안타깝습니다.
RedMine을 사용한 프로젝트는 여러차례 경험해 보았습니다만, 이러한 사용방식은 처음이었고, 꽤 Smart하다고 생각합니다.
비슷한 고민을 하고 있다면, 한 번쯤 도입을 연구해 보는 것도 좋다라고 생각합니다.
어쩌면 이미 사용하고 있는 곳이 벌써 많은지도.
tcc cgi, 그리고 몇가지 C trick에 대한 답입니다.
생각난 김에,
Tiny C Compiler로 cgi를 돌려보았습니다.
체감속도는,
perl 보다 빠른 듯했습니다.
----
++i와 i++은 c에서는 퍼포먼스(연산속도)는 같습니다.
단, c++에서는 ++i가 더 좋습니다.
왜냐하면 c++에서는 ++연산자를 다음과 같이 operator overloading하기 때문입니다.
(정수의 경우)
Tiny C Compiler로 cgi를 돌려보았습니다.
체감속도는,perl 보다 빠른 듯했습니다.
----
if ( blah(), 5) {
//do something
}
는
blah();
if (5) {
// do something
}
++i와 i++은 c에서는 퍼포먼스(연산속도)는 같습니다.
단, c++에서는 ++i가 더 좋습니다.
왜냐하면 c++에서는 ++연산자를 다음과 같이 operator overloading하기 때문입니다.
(정수의 경우)
// Prefix
Integer& Integer::operator++()
{
*this += 1;
return *this;
}
// Postfix
const Integer Integer::operator++(int)
{
Integer oldValue = *this;
++(*this);
return oldValue;
}
a[5] == 5[a] 는 true입니다.
왜냐하면*(a + 5)와*(5+a)는 같기 때문입니다.
이렇게 연산하는 이유는 c가 디자인된 70년대 64k면 많은 메모리였던 당시,
많은 syntax checking을 할 수 없었기 때문에 무조건*(a + 5)로 변환했기 때문입니다.
더불어"ABCD"[2] == 2["ABCD"] 역시 true이고,
모두 'C' 를 나타냅니다.
----
그리고 최근(2009/8/27) boost c++ library 1.40이 발표되었습니다.
http://www.boost.org/
gcc 4.4를 지원한다고 하는데, 저는 아직 3.4.5를 사용하고 있습니다.
살며시 버전을 올리는 것도 생각해 봐야겠습니다.
#어느 곳에서는 operator overriding이라고도 하는군요.
#나는 redefinition 플러스 operand에 따라 동작을 추가할 수 있으므로 overloading쪽에 한표.
Monday, August 24, 2009
Emeditor에서 Objective C용 Ctags 파일 사용하기
우선, sourceforge에 있는 ctag http://ctags.sourceforge.net/의 배포판에서는 Objective C Parser를 제공하고 있지 않습니다.
그런데, andew ruder라는 사람이 objective c용 tags parser를 만들었는데,
http://gitweb.aeruder.net/?p=ctags-objc.git;a=summary
2009-05-14
splhackさん이라는 분이 이를 이용해서 ObjC 대응하는 Exuberant Ctags 컴파일 버전을 만들어 공개했습니다.
http://iphone-dev.g.hatena.ne.jp/tokorom/20090514/1242324330
소스를 다운받아 윈도우즈용으로 컴파일했습니다.
C:\MinGW\bin\mingw32-make.exe -f mk_mingw.mak
아래의 화면에 보면 Objc가 추가되어 있습니다.
태깅파일을 만들어 보았습니다.
"c:\Program Files\EmEditor\PlugIns"\ctags.exe -R -V --language-force=objc --tag-relative=no -h=.m.h -f ..\tags --verbose=yes --objc-kinds=+f+c+d-n --sort=no
아래의 화면에 OPENING이 같은 파일에 대해 두번 써 지는 것은, Objective-C파서가 Objective-C문법으로 한번 Parse하고, C나 C++파서로 넘어가 다시 한번 parse하기 때문입니다.
Emeditor에서 프로젝트 플러그인을 열고, 태깅파일을 지정해 보았습니다.
오른쪽 Pane에 보이는 것이 태깅 리스트입니다.
흠. 이정도로, 어떤 클래스가 있고, 어떤 메서드, 프라퍼티가 있는지 알기에는 도움이 될 것 같습니다.
그런데, andew ruder라는 사람이 objective c용 tags parser를 만들었는데,
http://gitweb.aeruder.net/?p=ctags-objc.git;a=summary
2009-05-14
splhackさん이라는 분이 이를 이용해서 ObjC 대응하는 Exuberant Ctags 컴파일 버전을 만들어 공개했습니다.
http://iphone-dev.g.hatena.ne.jp/tokorom/20090514/1242324330
소스를 다운받아 윈도우즈용으로 컴파일했습니다.
C:\MinGW\bin\mingw32-make.exe -f mk_mingw.mak
아래의 화면에 보면 Objc가 추가되어 있습니다.
태깅파일을 만들어 보았습니다.
"c:\Program Files\EmEditor\PlugIns"\ctags.exe -R -V --language-force=objc --tag-relative=no -h=.m.h -f ..\tags --verbose=yes --objc-kinds=+f+c+d-n --sort=no
아래의 화면에 OPENING이 같은 파일에 대해 두번 써 지는 것은, Objective-C파서가 Objective-C문법으로 한번 Parse하고, C나 C++파서로 넘어가 다시 한번 parse하기 때문입니다.
Emeditor에서 프로젝트 플러그인을 열고, 태깅파일을 지정해 보았습니다.오른쪽 Pane에 보이는 것이 태깅 리스트입니다.
흠. 이정도로, 어떤 클래스가 있고, 어떤 메서드, 프라퍼티가 있는지 알기에는 도움이 될 것 같습니다.
Sunday, August 23, 2009
GNUStep 사용기 : NSAlertPanel 에서 한글
GNUStep을 사용중 NSAlertPanel에서 일본어,한글이 옆으로 나오고 있는 것을 발견했습니다.
실제 Mac에서 컴파일하면 정상적으로 보인다고 합니다.
컴파일 화면
실행화면
거의 스크립트 수준길이의 c 소스로, 그럴듯한 화면이 만들어 졌습니다.
어째 윈도우즈에서의 C프로그래밍보다 훨씬소스가 간결한 느낌입니다.
여기에 Xcode를 이용한 개발의 Tutorial youtube를 보고 있으면
http://www.youtube.com/watch?v=troUhf3hewA&feature=SeriesPlayList&p=B397075C08EBE329
맥을 써보고 싶다라는 생각이 들기 시작합니다.
아직 Winchain에서 Cocoa Touch API를 사용가능한지 확인하고 있지 않습니다.
다운로드의 사이트(http://code.google.com/p/winchain/downloads/list)를 보면, 97년 12월이 마지막 업데이트인데, GNUStep은 그보다 뒤에 나왔기 때문에, WinChain에서 Cocoa Touch를 사용할 수 있다면, GNUStep에서도 사용할 수 있겠지요. 그러나 둘 다 Cocoa API를 사용하지 못할 가능성이 가장 클 것 같습니다.
#Winchain은 또 하나의 MINGW을 설치하기 때문에 설치하고 않고 있습니다. 벌써 2개나 깔려있으니까요.
실제 Mac에서 컴파일하면 정상적으로 보인다고 합니다.
#import
#import
int
main (void)
{
NSAutoreleasePool *pool;
pool = [NSAutoreleasePool new];
[NSApplication sharedApplication];
//NSRunAlertPanel (@"Kim TongHyun Test", @"Hello from the GNUstep AppKit",
NSString *title = [NSString stringWithUTF8String:"김동현입니다日本語です。"];
NSString *content = [NSString stringWithUTF8String:"본문입니다. `本文です。"];
NSString *okmsg = [NSString stringWithUTF8String:"オッケー"];
NSString *cancelmsg = [NSString stringWithUTF8String:"キャンセル"];
int result = NSRunAlertPanel (title, content,
okmsg,
cancelmsg,
nil);
switch (result) {
case NSAlertDefaultReturn:
NSLog(@"OK");
break;
case NSAlertAlternateReturn:
NSLog(@"Cancel");
break;
case NSAlertOtherReturn:
NSLog(@"Other");
break;
default:
NSLog(@"Error");
break;
}
return 0;
}
컴파일 화면
실행화면
거의 스크립트 수준길이의 c 소스로, 그럴듯한 화면이 만들어 졌습니다.
어째 윈도우즈에서의 C프로그래밍보다 훨씬소스가 간결한 느낌입니다.
여기에 Xcode를 이용한 개발의 Tutorial youtube를 보고 있으면
http://www.youtube.com/watch?v=troUhf3hewA&feature=SeriesPlayList&p=B397075C08EBE329
맥을 써보고 싶다라는 생각이 들기 시작합니다.
아직 Winchain에서 Cocoa Touch API를 사용가능한지 확인하고 있지 않습니다.
다운로드의 사이트(http://code.google.com/p/winchain/downloads/list)를 보면, 97년 12월이 마지막 업데이트인데, GNUStep은 그보다 뒤에 나왔기 때문에, WinChain에서 Cocoa Touch를 사용할 수 있다면, GNUStep에서도 사용할 수 있겠지요. 그러나 둘 다 Cocoa API를 사용하지 못할 가능성이 가장 클 것 같습니다.
#Winchain은 또 하나의 MINGW을 설치하기 때문에 설치하고 않고 있습니다. 벌써 2개나 깔려있으니까요.
Saturday, August 22, 2009
iphone appli개발 대한 접근 전략
최근, 자꾸 옆에서 iphone 어플리케이션을 만들지 않겠느냐며 옆구리를 찌르는 사람이 있습니다.
솔직히, 작은 디스플레이를 가진 디바이스의 소프트웨어 개발은 까닭없이 끌리지 않아 지금껏 관심이 없었습니다. (아이폰도 가지고 있지 않구요. )
하지만, 제쪽도 개발이란 것이 너무나 웹 어플리케이션에 치우쳐져 있었기 때문에, Stand-Alone 어플리케이션의 개발이 그리워진 이유도 있고, Computer-Aid Study라면 iphone은 적당한 디바이스가 아닐까- 하는 생각도 있어, 가/부 를 대답하기까지 한달 정도 시간을 달라고 해서, 조금씩 보고 있습니다.
(만들어 보고 싶은 소프트웨어라면, 외국어 학습에 도움이 되는 소프트웨어를 만들어 보고 싶습니다. iphone에 음성인식기능이 있나요? "사까나"라고 말하면, 魚「さかな」：물고기 라고 나오는 어플리케이션이 있으면 좋을텐데.!)
우선 맥에서의 개발 경험이 거의 전무하기 때문에 가능한 한, 윈도우즈로 부터 시작하는 방법을 찾고 있었습니다. 이에 대한 전략(아직 시도하고 있지 않고, 이러한 방법으로 접근하면 될 것 같다라는)을 정리해보려 합니다.
1. Objective-C
Objective-C는 C의 확장문법입니다. NextStep사가 개발했습니다.
2. cocoa
코코아는 API이며, 즉 C 라이브러리입니다.
코코아는 Foundation 프레임웍과 Application Kit 프레임웍 두가지로 나눠집니다.
2.1 Foundation 프레임웍은 Objective-C클래스의 Base계층을 구현한 것입니다.
Objective-C의 문법을 구현한 것 이외에도 유틸리티 클래스와 메모리관리 규칙과 유니코드, 객체의 persistance등의 함께 제공합니다.
(정확하지는 않지만, VisualC의 MFC의 클래스들과 같은 것을 제공하는 것이라고 이해해도 좋을 것 같습니다.)
#import
에 해당하는 부분입니다.
NSArray, NSMutableArray,
NSDictionary, NSMustableDictionary,
NSSet, NSMutableSet, NSCountedSet
우선 정도를 익히고, 나머지는 습작 프로젝트를 통해 익혀나가면 좋을 것 같습니다.
2.2 Application Kit 프레임웍은 Foundation 프레임웍을 사용한 GUI class를 구현합니다.
#import
에 해당하는 부분입니다.
코드로 윈도우들을 만들고 다루는 방법.
Interface Builder로 디자인한 정보가 담긴 .nib파일 생성해 Outlet으로 연결해 정보를 다루는 방법.
(크로스플랫폼을 위해서라면 르네상스라는 GNUStep라이브러리를 이용하는 방법도 봐두면 좋을 것 같습니다.)
----
여기까지는 GNUStep을 사용하면 윈도우즈에서도 개발이 가능합니다.
그런데 맥에서는 Xcode라고하는 (이전의 이름은 Project Builder), MS의 Visual Studio와 같은 IDE가 있는데, 이 IDE는 Interface Builder를 사용하여 윈도우를 설정합니다.
Interface Builder는 Visual Studio의 윈도우 Designer와 비슷하다고 생각할 수 있습니다.
Interface Builder를 사용해서 디자인한 윈도우는 .nib (아마도 nextstep interface builder의 약자겠죠?)라는 binary파일로 저장해서 Xcode에서 이 파일과 링크해 어플리케이션을 build하는 것이 보통인 것 같습니다.
최근의 GNUStep에서도 Gorm을 통해서 nib파일을 읽고 쓸 수 있다고 합니다.
GnuStep은 또 .nib 파일은 맥에서만 사용되므로, 크로스플랫폼으로 사용가능한 xml포맷의 르네상스라는 것을 것을 소개,권장하고 있습니다.
----
여기까지 되었다면, 이제는 맥이 필요하게 될 것 같습니다.
이유로는, 윈도우즈용에서 작성한 소스가 맥에서 제대로 컴파일 되어 동작하는지를 검증하는 목적과
iphone SDK로 제공하는 특별한 api를 사용하기 위해서입니다.
아직 진행중인 탐색과정이며, 모르고 있는 툴, 사용해 보지 못한 툴도 너무 많습니다.
최적의 개발방법을 찾는데는, 아마 조금 더 걸릴 것 같습니다.
.
솔직히, 작은 디스플레이를 가진 디바이스의 소프트웨어 개발은 까닭없이 끌리지 않아 지금껏 관심이 없었습니다. (아이폰도 가지고 있지 않구요. )
하지만, 제쪽도 개발이란 것이 너무나 웹 어플리케이션에 치우쳐져 있었기 때문에, Stand-Alone 어플리케이션의 개발이 그리워진 이유도 있고, Computer-Aid Study라면 iphone은 적당한 디바이스가 아닐까- 하는 생각도 있어, 가/부 를 대답하기까지 한달 정도 시간을 달라고 해서, 조금씩 보고 있습니다.
(만들어 보고 싶은 소프트웨어라면, 외국어 학습에 도움이 되는 소프트웨어를 만들어 보고 싶습니다. iphone에 음성인식기능이 있나요? "사까나"라고 말하면, 魚「さかな」：물고기 라고 나오는 어플리케이션이 있으면 좋을텐데.!)
우선 맥에서의 개발 경험이 거의 전무하기 때문에 가능한 한, 윈도우즈로 부터 시작하는 방법을 찾고 있었습니다. 이에 대한 전략(아직 시도하고 있지 않고, 이러한 방법으로 접근하면 될 것 같다라는)을 정리해보려 합니다.
1. Objective-C
Objective-C는 C의 확장문법입니다. NextStep사가 개발했습니다.
2. cocoa
코코아는 API이며, 즉 C 라이브러리입니다.
코코아는 Foundation 프레임웍과 Application Kit 프레임웍 두가지로 나눠집니다.
2.1 Foundation 프레임웍은 Objective-C클래스의 Base계층을 구현한 것입니다.
Objective-C의 문법을 구현한 것 이외에도 유틸리티 클래스와 메모리관리 규칙과 유니코드, 객체의 persistance등의 함께 제공합니다.
(정확하지는 않지만, VisualC의 MFC의 클래스들과 같은 것을 제공하는 것이라고 이해해도 좋을 것 같습니다.)
#import
에 해당하는 부분입니다.
NSArray, NSMutableArray,
NSDictionary, NSMustableDictionary,
NSSet, NSMutableSet, NSCountedSet
우선 정도를 익히고, 나머지는 습작 프로젝트를 통해 익혀나가면 좋을 것 같습니다.
2.2 Application Kit 프레임웍은 Foundation 프레임웍을 사용한 GUI class를 구현합니다.
#import
에 해당하는 부분입니다.
코드로 윈도우들을 만들고 다루는 방법.
Interface Builder로 디자인한 정보가 담긴 .nib파일 생성해 Outlet으로 연결해 정보를 다루는 방법.
(크로스플랫폼을 위해서라면 르네상스라는 GNUStep라이브러리를 이용하는 방법도 봐두면 좋을 것 같습니다.)
----
여기까지는 GNUStep을 사용하면 윈도우즈에서도 개발이 가능합니다.
그런데 맥에서는 Xcode라고하는 (이전의 이름은 Project Builder), MS의 Visual Studio와 같은 IDE가 있는데, 이 IDE는 Interface Builder를 사용하여 윈도우를 설정합니다.
Interface Builder는 Visual Studio의 윈도우 Designer와 비슷하다고 생각할 수 있습니다.
Interface Builder를 사용해서 디자인한 윈도우는 .nib (아마도 nextstep interface builder의 약자겠죠?)라는 binary파일로 저장해서 Xcode에서 이 파일과 링크해 어플리케이션을 build하는 것이 보통인 것 같습니다.
최근의 GNUStep에서도 Gorm을 통해서 nib파일을 읽고 쓸 수 있다고 합니다.
GnuStep은 또 .nib 파일은 맥에서만 사용되므로, 크로스플랫폼으로 사용가능한 xml포맷의 르네상스라는 것을 것을 소개,권장하고 있습니다.
----
여기까지 되었다면, 이제는 맥이 필요하게 될 것 같습니다.
이유로는, 윈도우즈용에서 작성한 소스가 맥에서 제대로 컴파일 되어 동작하는지를 검증하는 목적과
iphone SDK로 제공하는 특별한 api를 사용하기 위해서입니다.
아직 진행중인 탐색과정이며, 모르고 있는 툴, 사용해 보지 못한 툴도 너무 많습니다.
최적의 개발방법을 찾는데는, 아마 조금 더 걸릴 것 같습니다.
.
Friday, August 21, 2009
Record : install gnustep and make gui application
1. download gnu-system and gnu-core setup.exe for windows
from http://ftpmain.gnustep.org/pub/gnustep/binaries/windows/
2. setup onto C:\GNUStep
3. ren C:\GNUstep\bin\rxvt-save.exe C:\GNUstep\bin\rxvt.exe
4. insert "cd C:\GNUstep\mingw\lib" at startup of C:\GNUstep\msys.bat
5. launch C:\GNUstep\msys.bat
6. write some code as source.m
7. compile on gnustep sh console
8. launch kim.exe
but if you have mingw already, you can do this on cmd console.
from http://ftpmain.gnustep.org/pub/gnustep/binaries/windows/
2. setup onto C:\GNUStep
3. ren C:\GNUstep\bin\rxvt-save.exe C:\GNUstep\bin\rxvt.exe
4. insert "cd C:\GNUstep\mingw\lib" at startup of C:\GNUstep\msys.bat
5. launch C:\GNUstep\msys.bat
6. write some code as source.m
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
int main (void)
{
NSAutoreleasePool *pool;
pool = [NSAutoreleasePool new];
[NSApplication sharedApplication];
NSRunAlertPanel (@"Kim TongHyun Test", @"Hello from the GNUstep AppKit",
nil, nil, nil);
return 0;
}
7. compile on gnustep sh console
gcc -o kim.exe source.m -I/GNUstep/Syste/Library/Headers -L/GNUstep/System/Library/Libraries/ -objc -lgnustep-base -gnustep-gui -fconstant-string-class=NSConstantString
8. launch kim.exe
but if you have mingw already, you can do this on cmd console.
gcc -o kim.exe source.m -IC:\GNUstep\GNUstep\Syste\Library/Headers -LC:\GNUstep\GNUstep\System\Library\Libraries\ -objc -lgnustep-base -lgnustep-gui -fconstant-string-class=NSConstantString
Thursday, August 20, 2009
Record : installing Python26 and SQLAlchemy
Record : upgrade python 2.6.1 -> 2.6.2 and easy-install and SQLAlchemy
1. remove python 2.6.2
2. down ActivePython 2.6.2 from http://downloads.activestate.com/ActivePython/windows/2.6/ActivePython-2.6.2.2-win32-x86.msi
3. install Python c:\Python26
4. junction -d c:\usr\local\python
5. junction c:\Python26 c:\usr\local\python
6. junction C:\Python26\scripts C:\Python26\Tools\scripts
1. download python package manager from http://sourceforge.net/projects/pythonpkgmgr/files/pythonpkgmgr/Windows%200.2/PythonPackageManagerInstall-0_2.exe/download
1. get easy-install from http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg
2. run PPM and install setuptools-0.6c9-py2.6.egg
1. using PPM, search and install SQLAlchemy
1. using PPM, search and install MYSQL-python
that's all
# 최근, cmd console에서도 vi를 사용하면서, cmd console의 폭을 120으로 놓고 사용하고 있습니다.
1. remove python 2.6.2
2. down ActivePython 2.6.2 from http://downloads.activestate.com/ActivePython/windows/2.6/ActivePython-2.6.2.2-win32-x86.msi
3. install Python c:\Python26
4. junction -d c:\usr\local\python
5. junction c:\Python26 c:\usr\local\python
6. junction C:\Python26\scripts C:\Python26\Tools\scripts
1. download python package manager from http://sourceforge.net/projects/pythonpkgmgr/files/pythonpkgmgr/Windows%200.2/PythonPackageManagerInstall-0_2.exe/download
1. get easy-install from http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg
2. run PPM and install setuptools-0.6c9-py2.6.egg
1. using PPM, search and install SQLAlchemy
1. using PPM, search and install MYSQL-python
that's all
# 최근, cmd console에서도 vi를 사용하면서, cmd console의 폭을 120으로 놓고 사용하고 있습니다.
Friday, August 14, 2009
Objective-C 맛보았습니다.
아이폰 어플리케이션 개발을 위해 기본적으로 알아야할 사항은 통합개발 환경인 Xcode와 인터페이스 빌더라는 툴의 사용법, Cocoa Touch 프레임워크, Objective-C 크게 세가지 라고 합니다.
이중 오늘 회사의 동료로부터 Objective-C에 대한 책을 빌려받아 보고 있습니다.
Objective-C만 한다면, Windows에서 GNUStep의 환경을 빌어서 컴파일 해보는 것은 가능했습니다. 문법만이라면 아마 2-3번 정도 습작을 해보면 알 수 있을 것 같습니다.
그런데 아무래도 Xcode, 인터페이스빌더의 사용법, OS X에서의 프로그래밍에대한 이해와 코코아 API를 배우는데 Objective-C 언어 자체를 배우는 것보다 더 많은 시간이 필요할 것 같습니다.
그 외에도 DB의 SQLite3 api, openGL인 cocos api까지 사용하려면 한달이면 매우 험난할 것 같습니다.
맥 사용은 완전히 처음이라고 해도 좋을 만큼 사용에 대한 불안감도 좀 있습니다.
에디터로는 vim과 perl, python이 사용가능하면 좋겠는데..
완전히 새로운 것을 접하는 것이기 때문에 두려운 느낌도 있습니다만, 조금 두근거리기도 합니다.
이중 오늘 회사의 동료로부터 Objective-C에 대한 책을 빌려받아 보고 있습니다.
Objective-C만 한다면, Windows에서 GNUStep의 환경을 빌어서 컴파일 해보는 것은 가능했습니다. 문법만이라면 아마 2-3번 정도 습작을 해보면 알 수 있을 것 같습니다.
그런데 아무래도 Xcode, 인터페이스빌더의 사용법, OS X에서의 프로그래밍에대한 이해와 코코아 API를 배우는데 Objective-C 언어 자체를 배우는 것보다 더 많은 시간이 필요할 것 같습니다.
그 외에도 DB의 SQLite3 api, openGL인 cocos api까지 사용하려면 한달이면 매우 험난할 것 같습니다.
맥 사용은 완전히 처음이라고 해도 좋을 만큼 사용에 대한 불안감도 좀 있습니다.
에디터로는 vim과 perl, python이 사용가능하면 좋겠는데..
완전히 새로운 것을 접하는 것이기 때문에 두려운 느낌도 있습니다만, 조금 두근거리기도 합니다.
Thursday, August 13, 2009
Gohko상의 Vim사용에 감명받았습니다.
Gohko상이 vim을 너무 멋있게 쓰는 것을 보고 감명받았습니다.
지금까지 본 vim user중에 최고입니다.
뒤에서 지켜보고 있다가 이런 점에서 좋구나 하고 생각한 것은,
다른 IDE나 Editor로는 화면을 둘 정도까지 나누면 거의 더 나누어 작업하기 곤란한데,
vim으로는 5개까지 나눠서 작업해도 할만하겠다 하는 것이었습니다.
거기에 탭까지 사용하고 있고, 이런 vim 창을 여러개 띄워두어 작업하고 있었습니다.
다음은 gvim으로 따라해본 것.
(듀얼모니터라면 오히려 시선이 분리될 느낌입니다.)
지금까지의 경험입니다만, 에디터를 잘 사용한다고 전부 개발을 잘 하는 것은 아니겠지만,
개발을 정말 잘 한다라고 느껴지는 사람들은 전부 에디터를 빠르고 멋지게 사용하고 있었습니다.
집에 돌아와 lucida console 9pt와 color torte를 적용시켜보았습니다.
vimrc파일은 http://amix.dk/vim/vimrc.html 의 것을 적용시켜두었습니다. 역시 3단으로 나누어도 파일을 편집하는데 크게 문제가 되지 않을 것 같습니다.(회사의 모니터보다 집의 모니터가 옆으로 조금 pixel이 많습니다만,) emeditor도 굉장히 좋은 에디터입니다만, gohko상의 vim쓰는 것을 보고 완전히 반해버렸습니다.
현재 사용하고 있는 Emeditor도 이런 방식으로 흉내내 보았습니다. 이케루?
각 explorer, outline, html preview는 단축키로 불러내 사용하고 있기 때문에, 어쩌면 이케루.
알파벳만 있으면 폰트를 더 작게 해서 좀 더 넓게 볼 수 있을 텐데,
한글과 일본어가 섞여 있기 때문에, 더이상 폰트를 작게 하면 보기 힘들다는,
사용하는 폰트는 Lucida Console 10.5pt입니다. (일본사람이 만든 에디터여서 알파벳사용권 에디터에서는 보통 잘 지원되지 않는 10.5pt가 지원됩니다. 한자와 알파벳이 적당한 사이즈로 함께 나타납니다.)
vim에서 사용하는 ex명령어 사용하는 방식도 emeditor에서 사용할 수 있다면 좋을 텐데.
totalcmd에서 cmd창을 부를 수 있는 것처럼. <-- 이것은 Slickrun으로 어떻게 될 수 있을 것 같습니다.
지금까지 본 vim user중에 최고입니다.
뒤에서 지켜보고 있다가 이런 점에서 좋구나 하고 생각한 것은,
다른 IDE나 Editor로는 화면을 둘 정도까지 나누면 거의 더 나누어 작업하기 곤란한데,
vim으로는 5개까지 나눠서 작업해도 할만하겠다 하는 것이었습니다.
거기에 탭까지 사용하고 있고, 이런 vim 창을 여러개 띄워두어 작업하고 있었습니다.
다음은 gvim으로 따라해본 것.
(듀얼모니터라면 오히려 시선이 분리될 느낌입니다.)
지금까지의 경험입니다만, 에디터를 잘 사용한다고 전부 개발을 잘 하는 것은 아니겠지만,
개발을 정말 잘 한다라고 느껴지는 사람들은 전부 에디터를 빠르고 멋지게 사용하고 있었습니다.
집에 돌아와 lucida console 9pt와 color torte를 적용시켜보았습니다.vimrc파일은 http://amix.dk/vim/vimrc.html 의 것을 적용시켜두었습니다. 역시 3단으로 나누어도 파일을 편집하는데 크게 문제가 되지 않을 것 같습니다.(회사의 모니터보다 집의 모니터가 옆으로 조금 pixel이 많습니다만,) emeditor도 굉장히 좋은 에디터입니다만, gohko상의 vim쓰는 것을 보고 완전히 반해버렸습니다.
현재 사용하고 있는 Emeditor도 이런 방식으로 흉내내 보았습니다. 이케루?
각 explorer, outline, html preview는 단축키로 불러내 사용하고 있기 때문에, 어쩌면 이케루.
알파벳만 있으면 폰트를 더 작게 해서 좀 더 넓게 볼 수 있을 텐데,
한글과 일본어가 섞여 있기 때문에, 더이상 폰트를 작게 하면 보기 힘들다는,
사용하는 폰트는 Lucida Console 10.5pt입니다. (일본사람이 만든 에디터여서 알파벳사용권 에디터에서는 보통 잘 지원되지 않는 10.5pt가 지원됩니다. 한자와 알파벳이 적당한 사이즈로 함께 나타납니다.)
vim에서 사용하는 ex명령어 사용하는 방식도 emeditor에서 사용할 수 있다면 좋을 텐데.
totalcmd에서 cmd창을 부를 수 있는 것처럼. <-- 이것은 Slickrun으로 어떻게 될 수 있을 것 같습니다.
Wednesday, August 5, 2009
cmd콘솔에서 한글, 일본어 둘 다 사용하기(?)
C:\>한글
C:\>한글이라니깐
C:\>씹냐?
'?' is not recognized as an internal or external command,
operable program or batch file.
C:\>음냐
C:\>you win.
'you' is not recognized as an internal or external command,
operable program or batch file.
C:\>にほんご
C:\>日本語
C:\>-_-;;
'-_-' is not recognized as an internal or external command,
operable program or batch file.
제가 지금 뭘 했냐면, 콘솔에서 한글과 일본어가 다 입력되도록 해봤습니다....
어떻게 했느냐면, 로컬에 텔넷서버를 띄워놓고, utf-8이 지원되는 xshell로 localhost에 접속해서
chcp 65001로 unicode로 코드페이지를 변경했습니다.
흠흠. 일본OS의 cmd쉘에서 한글과 일본어를 동시에 쓰고 싶어서...
cmd쉘에서 아무리 chcp, 레지스트리에서 폰트를 바꾸대도,
utf-8로 패치해서 cygwin을 돌려봐도, 일단 cmd계열의 프레임에서는 기본언어밖에 입력이 불가능했습니다. 결국 xshell과 같은 외부 터미널 에뮬레이터로 연결해 사용하는 것으로 할 수 있었습니다만,
원래 목적은 perl과 같은 간단한 커맨드라인 유틸리티로, gmail의 메일을 검사하는 것이라던지, 한글을 입출력 하게하는 것. 이었습니다만, 굉장히 불편해져 버린 느낌입니다....
C:\>한글이라니깐
C:\>씹냐?
'?' is not recognized as an internal or external command,
operable program or batch file.
C:\>음냐
C:\>you win.
'you' is not recognized as an internal or external command,
operable program or batch file.
C:\>にほんご
C:\>日本語
C:\>-_-;;
'-_-' is not recognized as an internal or external command,
operable program or batch file.
제가 지금 뭘 했냐면, 콘솔에서 한글과 일본어가 다 입력되도록 해봤습니다....
어떻게 했느냐면, 로컬에 텔넷서버를 띄워놓고, utf-8이 지원되는 xshell로 localhost에 접속해서
chcp 65001로 unicode로 코드페이지를 변경했습니다.
흠흠. 일본OS의 cmd쉘에서 한글과 일본어를 동시에 쓰고 싶어서...
cmd쉘에서 아무리 chcp, 레지스트리에서 폰트를 바꾸대도,
utf-8로 패치해서 cygwin을 돌려봐도, 일단 cmd계열의 프레임에서는 기본언어밖에 입력이 불가능했습니다. 결국 xshell과 같은 외부 터미널 에뮬레이터로 연결해 사용하는 것으로 할 수 있었습니다만,
원래 목적은 perl과 같은 간단한 커맨드라인 유틸리티로, gmail의 메일을 검사하는 것이라던지, 한글을 입출력 하게하는 것. 이었습니다만, 굉장히 불편해져 버린 느낌입니다....
Tuesday, July 28, 2009
「自由にどうぞ」라고 하는 포스트잇
어제 퇴근하려고 타임카드를 찍으려는데, 타임카드 앞에 「オペミスをなくそう」라고 하는 기사를 복사해서 「自由にどうぞ」라고 하는 포스트잇을 붙여놓은 것이 놓여 있어서, 퇴근하는 전철에서 읽었습니다.
이런 일은 제가 이 회사를 다니면서 처음 있는 일이었습니다.
작은 것이지만, 한국처럼(한국도 잘 안하긴 하지만) 동료끼리 물어보면 잘 알려준다던가, 새로운 것을 발견하면, 식사를 같이하면서 얘기하며 정보를 나눈다던가 하는 것이 전혀 없는 굉장히 삭막한 분위기의 일본회사 시스템본부 였기 때문에,
정말 이상하게 들릴 이야기일지 모르지만...
굉장히 흘겨쓴 글씨인 「自由にどうぞ」라고 하는 포스트잇에 전 「감동」받았답니다.
크-
기사는 Nikkei Systems 2009년 8월호 특집 이었습니다.
이런 일은 제가 이 회사를 다니면서 처음 있는 일이었습니다.
작은 것이지만, 한국처럼(한국도 잘 안하긴 하지만) 동료끼리 물어보면 잘 알려준다던가, 새로운 것을 발견하면, 식사를 같이하면서 얘기하며 정보를 나눈다던가 하는 것이 전혀 없는 굉장히 삭막한 분위기의 일본회사 시스템본부 였기 때문에,
정말 이상하게 들릴 이야기일지 모르지만...
굉장히 흘겨쓴 글씨인 「自由にどうぞ」라고 하는 포스트잇에 전 「감동」받았답니다.
크-
기사는 Nikkei Systems 2009년 8월호 특집 이었습니다.
Monday, July 27, 2009
stackoverflow.com의 경험
최근에 Aero님을 통해 알게된 개발자의 지식인 사이트에 해당하는 stackoverflow.com을 이용하는 일이 많았습니다.
꽤 사이트가 충실히 운영되고 있다라고 할까요. 원하는 내용을 검색해 나온 결과로 메일링 리스트나 뉴스그룹에 포스팅 된 글일 경우,
질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
와 같은 thread로 된 자료들은 자료를 찾기 어렵습니다. 내가 찾는 답변이 어느 post에 있는 지 운이 나쁘면 전부 다 열어서 확인해 보아야 하는 경우도 있구요.
그런데 stackoverflow.com은 자료를 찾기 쉬웠고, 특히, 그 질문과 답변의 질이 상당히 좋습니다.
로그인도 OpenID를 사용하고 있구요.
그래서 최근 많이 이용하고 있었습니다만, 아직 저는 추천을 클릭할 수 있는 레벨이 아니었습니다. 추천은 최초 15 reputation point를 얻어야 할 수 있습니다.
나도 추천에 참여하고 싶었습니다만, 좀 아쉬웠지요. 하지만 reasonable한 정책이라고 생각하기 때문에 어쩔 수 없었습니다.
___
그러던 중, 최근, 어떤 문제를 해결하기 위해 한참 씨름하고 있다가 결국 내가 원하는 해결방법을 경험한 사람은 Net상에 적혀있지 않다라고 결론을 내리고,
용기를 내어 stackoverflow에 글을 써보았는데 굉장히 신기한 게시판을 경험했습니다.
뭐랄까. 요즘 외국의 사이트에는 거의 다 있는 post에 투표하기, 그리고 자신의 포스트에 얻은 reputation(명성) 점수로
뱃지가 주어지며 (현재 저는 11점이며 student 뱃지입니다.) 뱃지가 매우 높은 유저는 낮은 유저의 post를 편집해 버릴 수도 있습니다.(이부분이 제일 쇼킹했습니다.)
원래의 글은
hi all.
I am struggling to get control of an IE preview control which is 'Internet Explorer_Server' class on an external windows application with perl
I can get a handle of that 'Internet Explorer_Server' with Win32::GUI::GetWindow(), but have no idea what to do next.
Any help would be greatly appreciated!
Thanks,
Kim
였습니다만, 7,386 reputation point를 가진 Sinan Ünür라는 사람이 'hi all.'과 'Any help would~' 부분을 떼어버리고,
타이틀도 수정해 버려서 깜짝놀랐습니다. 그런데 이게 순식간에 이루어진 일이었습니다.
내가 글을 post하고 submit한 뒤에, 30초쯤 있다가 잘 올라갔는지 확인하기 위해 보니, 내가 쓴 제목이 아니었습니다.
그리고는 질문이 코멘트로 달려 있었습니다.
Can you clarify what *Internet Explorer_Server* is? – Sinan Ünür
그래서 답변을 했지요.
Internet Explorer_Server is the class name of the window, I've found it with Spy++. and here’s my assertion code of it $className = Win32::GUI::GetClassName($window); if ($className eq "Internet Explorer_Server") { ... } – crowdy
그랬더니 이번에는 Manni라는 사람이 제 원래의 post에 제가 답한 코멘트의 코드를 더해 자세한 하나의 문장으로 편집해버리는 것이었습니다.
6번의 수정을 거쳐, 제목, 내용 flag 몽땅 적당한 것으로 추가, 편집되고, 사이트에 손색이 없는 포스트로 만들어져 버렸습니다.
post의 Title도 제가 쓴 것은
How to NAVIGATE an external Internet Explorer_Server class with perl
이었습니다만, 최종적으로
How can I automate an existing instance of Internet Explorer using Perl?
로 수정되었습니다.
___
일본에도 「教えて」등의 질문 답변 사이트가 많아지고 있습니다. 저희 그룹의 어느 회사에서도 그런 사이트를 하나 기획하고 있다라고 들었습니다.
하지만 아직 이러한 형식은 한국과 일본에서 시도되고 있는 것 같지는 않습니다. 그도 그럴것이 타인의 post를 수정하다니, 아주 Technical한 분야나, 수학, 과학등 Solution 또는 객관적 Information의 성격을 지닌 분야에서나 적용이 가능하겠지요.
응용한 기획을 생각해 볼 수도 있겠다는 생각이 들게하는 꽤 재미있는 경험이었습니다.
#결론으로 아직 원하는 solution은 못찾았습니다.
___
이상.
꽤 사이트가 충실히 운영되고 있다라고 할까요. 원하는 내용을 검색해 나온 결과로 메일링 리스트나 뉴스그룹에 포스팅 된 글일 경우,
질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
RE:질문입니다 어쩌고 저쩌고
와 같은 thread로 된 자료들은 자료를 찾기 어렵습니다. 내가 찾는 답변이 어느 post에 있는 지 운이 나쁘면 전부 다 열어서 확인해 보아야 하는 경우도 있구요.
그런데 stackoverflow.com은 자료를 찾기 쉬웠고, 특히, 그 질문과 답변의 질이 상당히 좋습니다.
로그인도 OpenID를 사용하고 있구요.
그래서 최근 많이 이용하고 있었습니다만, 아직 저는 추천을 클릭할 수 있는 레벨이 아니었습니다. 추천은 최초 15 reputation point를 얻어야 할 수 있습니다.
나도 추천에 참여하고 싶었습니다만, 좀 아쉬웠지요. 하지만 reasonable한 정책이라고 생각하기 때문에 어쩔 수 없었습니다.
___
그러던 중, 최근, 어떤 문제를 해결하기 위해 한참 씨름하고 있다가 결국 내가 원하는 해결방법을 경험한 사람은 Net상에 적혀있지 않다라고 결론을 내리고,
용기를 내어 stackoverflow에 글을 써보았는데 굉장히 신기한 게시판을 경험했습니다.
뭐랄까. 요즘 외국의 사이트에는 거의 다 있는 post에 투표하기, 그리고 자신의 포스트에 얻은 reputation(명성) 점수로
뱃지가 주어지며 (현재 저는 11점이며 student 뱃지입니다.) 뱃지가 매우 높은 유저는 낮은 유저의 post를 편집해 버릴 수도 있습니다.(이부분이 제일 쇼킹했습니다.)
원래의 글은
hi all.
I am struggling to get control of an IE preview control which is 'Internet Explorer_Server' class on an external windows application with perl
I can get a handle of that 'Internet Explorer_Server' with Win32::GUI::GetWindow(), but have no idea what to do next.
Any help would be greatly appreciated!
Thanks,
Kim
였습니다만, 7,386 reputation point를 가진 Sinan Ünür라는 사람이 'hi all.'과 'Any help would~' 부분을 떼어버리고,
타이틀도 수정해 버려서 깜짝놀랐습니다. 그런데 이게 순식간에 이루어진 일이었습니다.
내가 글을 post하고 submit한 뒤에, 30초쯤 있다가 잘 올라갔는지 확인하기 위해 보니, 내가 쓴 제목이 아니었습니다.
그리고는 질문이 코멘트로 달려 있었습니다.
Can you clarify what *Internet Explorer_Server* is? – Sinan Ünür
그래서 답변을 했지요.
Internet Explorer_Server is the class name of the window, I've found it with Spy++. and here’s my assertion code of it $className = Win32::GUI::GetClassName($window); if ($className eq "Internet Explorer_Server") { ... } – crowdy
그랬더니 이번에는 Manni라는 사람이 제 원래의 post에 제가 답한 코멘트의 코드를 더해 자세한 하나의 문장으로 편집해버리는 것이었습니다.
6번의 수정을 거쳐, 제목, 내용 flag 몽땅 적당한 것으로 추가, 편집되고, 사이트에 손색이 없는 포스트로 만들어져 버렸습니다.
post의 Title도 제가 쓴 것은How to NAVIGATE an external Internet Explorer_Server class with perl
이었습니다만, 최종적으로
How can I automate an existing instance of Internet Explorer using Perl?
로 수정되었습니다.
___
일본에도 「教えて」등의 질문 답변 사이트가 많아지고 있습니다. 저희 그룹의 어느 회사에서도 그런 사이트를 하나 기획하고 있다라고 들었습니다.
하지만 아직 이러한 형식은 한국과 일본에서 시도되고 있는 것 같지는 않습니다. 그도 그럴것이 타인의 post를 수정하다니, 아주 Technical한 분야나, 수학, 과학등 Solution 또는 객관적 Information의 성격을 지닌 분야에서나 적용이 가능하겠지요.
응용한 기획을 생각해 볼 수도 있겠다는 생각이 들게하는 꽤 재미있는 경험이었습니다.
#결론으로 아직 원하는 solution은 못찾았습니다.
___
이상.
Tuesday, June 30, 2009
[정보공유]「log4sql」의 소개
[정보공유]
[산소]로부터의 정보공유입니다.
java의 DAO계층에서 Statement로 쿼리를 부르는 경우, 정확히 어떤 쿼리가 전송되는지 로그를 남기도록 driver를 proxying하는 driver, 「log4sql」의 소개입니다.
http://log4sql.sourceforge.net/index_kr.html
한글, 일어의 페이지가 있습니다.(만, 일어페이지는 좀 깨져있군요)
비슷한 것으로 p6spy가 있습니다. p6spy가 더 많은 기능을 탑재하고 있다고 생각합니다만, 라이브러리 평가페이지 jars.developer.com에서 Top 25% Rated의 평가를 받고 있네요.
살펴볼만한 가치가 있다고 생각합니다.
이상.
[산소]로부터의 정보공유입니다.
java의 DAO계층에서 Statement로 쿼리를 부르는 경우, 정확히 어떤 쿼리가 전송되는지 로그를 남기도록 driver를 proxying하는 driver, 「log4sql」의 소개입니다.
http://log4sql.sourceforge.net/index_kr.html
한글, 일어의 페이지가 있습니다.(만, 일어페이지는 좀 깨져있군요)
비슷한 것으로 p6spy가 있습니다. p6spy가 더 많은 기능을 탑재하고 있다고 생각합니다만, 라이브러리 평가페이지 jars.developer.com에서 Top 25% Rated의 평가를 받고 있네요.
살펴볼만한 가치가 있다고 생각합니다.
이상.
Sunday, June 28, 2009
best practice of designing DAO
best practice of designing DAO
지금까지의 경험을 정리하는 것입니다만, DAO의 구축에 대해 한 번 알고 있는 모든 것을 동원해 "어떻게 하는 것이 좋은 지"에대해 한 번 생각해 보고자 합니다.
Database를 이용하는 우선 설계의 방식에는 여러가지가 존재할 수 있습니다. 각각 모두, 요구되는 '기록과 열람'이라는 내용은 만족합니다. 그러나 어떤 것이 왜 좋은지 알 지 못한다면 곤란합니다.
우선은 기본적인 Data의 설계는 각 프로젝트별로 맡기고, 여기에서는 공통적으로 다루어야 할 issue에 대해서만 촛점을 둡니다만, DB의 모델링에 대해서는 다양한 시스템에 대한 설계의 경험을 쌓아야 합니다.
각 프로젝트별로 필요한 필드의 추출, 추출방식은 도메인 모델을 기준으로 하던지, use case를 기준으로 해도 문제가 되지 않습니다. 또한 generalizing과 degeneralizing도 어느쪽에 비중을 더 크게 두더라도 틀린 것은 아닙니다. 오히려 어느쪽에 비중을 더 두었는 지를 보고, 어떤 기능이 들어가는지 기획을 짐작할 수 있습니다.
리소스에 여유가 있다면, Fetch용 Database와 DML용 Database를 따로 두는 것도 가능합니다. 이런 경우의 Database의 설계는 일반적인 경우와 많이 다른데, 일반적인 경우만 다루어본 사람이 이러한 구조를 알지 못한 채, 이런 ERD를 만나면, "DB를 잘 알지 못하는 사람이 작성했나보군"하고 생각할 지도 모릅니다.
공통적으로 다루어야할 Database의 설계에 대한 Issue로 여기고 있는 것은 다음과 같습니다. 안전한 Data의 취급이 무시되어야 하는 시스템은 없을 것입니다.
다음에 적는 것들은 없어도 기록의 출입을 구성하기에는 문제가 없습니다만, 고려해 보아야 할 내용들입니다.
1) Optimistic Lock
2) Trigger를 이용한 Update Delete시의 Transaction Table에의 기록.
3) Procedure를 이용한 DML(plus DML query의 실행제한)
Optimistic Lock은 시스템의 구성에 따라 꼭 필요하기도 하고, 없어도 상관없는 경우가 있습니다. Transaction의 기Term이 긴 시스템이라면 반드시 필요합니다. 구현은 프로시저를 사용하지 않고 코드에서 구현한다면, 상당한 작업량이 될 수 있습니다. 만일 프로시저를 사용할 수 없다라면, OR-Map의 도입도 고려해 보는 것도 좋다라고 생각합니다.
Trigger를 이용한 Transaction을 Table에 기록하는 것은 고객의 동작을 기록해 놓는 것으로 , 안전성의 의미가 큽니다.
Procedure를 이용한 DML은 parameter check도 코드에서 하는 것이 아니라 procedure에서 하겠다는 얘기입니다. Data기록의 로직은 Database의 Procedure에 두겠다는 것은 한 가지 언어 이외에도 복수의 언어로 구성된 시스템에서 동일한 기록의 동작을 보장합니다.
이것은 DB에 매우 큰 로드를 걸지 않는 한, 매우 바람직합니다라고 생각됩니다만, 실제로 많이 사용되는 경우는 보기 어려웠습니다. 특히 Procedure를 사용하지 않고, Application서버가 여러대로 분산되어 있을 경우 부하를 DB보다는 Application서버에 두려 하는 경우, 또 OR-Mapper를 더 선호해서 이를 통한 DML 작업을 하는 경우가 이유로 많이 제시되곤 했습니다.
그러나 잘 생각해보면, Hibernate등의 OR-Mapper를 사용한다고 하더라도 Select에 대한 작업은 Cache Provider등을 사용해 이득을 볼 수 있지만, Insert Update Delete에 대한 작업이 그리 많이 이득을 볼 수 있는 시스템이라고 확실히 얘기할 수 있는 시스템은 많지 않은 것 같습니다.
Hibernate등을 선호하는 케이스라면, 시스템이 허용하는 한, 사용해도 좋다고 생각합니다.
이런 경우라면 insert update delete 명령어를 금지하면 안되겠지만, DBA계정이 아닌, Application이 사용하는 계정이라면 금지를 생각해보는 것도 가능할 지 모릅니다.(실제 그렇게 운영해 본 적은 없습니다만...)
아아.. 오늘은 이만 해야겠습니다.
이 문서는 완전한 것이 아니므로 추가될 것입니다.
지금까지의 경험을 정리하는 것입니다만, DAO의 구축에 대해 한 번 알고 있는 모든 것을 동원해 "어떻게 하는 것이 좋은 지"에대해 한 번 생각해 보고자 합니다.
Database를 이용하는 우선 설계의 방식에는 여러가지가 존재할 수 있습니다. 각각 모두, 요구되는 '기록과 열람'이라는 내용은 만족합니다. 그러나 어떤 것이 왜 좋은지 알 지 못한다면 곤란합니다.
우선은 기본적인 Data의 설계는 각 프로젝트별로 맡기고, 여기에서는 공통적으로 다루어야 할 issue에 대해서만 촛점을 둡니다만, DB의 모델링에 대해서는 다양한 시스템에 대한 설계의 경험을 쌓아야 합니다.
각 프로젝트별로 필요한 필드의 추출, 추출방식은 도메인 모델을 기준으로 하던지, use case를 기준으로 해도 문제가 되지 않습니다. 또한 generalizing과 degeneralizing도 어느쪽에 비중을 더 크게 두더라도 틀린 것은 아닙니다. 오히려 어느쪽에 비중을 더 두었는 지를 보고, 어떤 기능이 들어가는지 기획을 짐작할 수 있습니다.
리소스에 여유가 있다면, Fetch용 Database와 DML용 Database를 따로 두는 것도 가능합니다. 이런 경우의 Database의 설계는 일반적인 경우와 많이 다른데, 일반적인 경우만 다루어본 사람이 이러한 구조를 알지 못한 채, 이런 ERD를 만나면, "DB를 잘 알지 못하는 사람이 작성했나보군"하고 생각할 지도 모릅니다.
공통적으로 다루어야할 Database의 설계에 대한 Issue로 여기고 있는 것은 다음과 같습니다. 안전한 Data의 취급이 무시되어야 하는 시스템은 없을 것입니다.
다음에 적는 것들은 없어도 기록의 출입을 구성하기에는 문제가 없습니다만, 고려해 보아야 할 내용들입니다.
1) Optimistic Lock
2) Trigger를 이용한 Update Delete시의 Transaction Table에의 기록.
3) Procedure를 이용한 DML(plus DML query의 실행제한)
Optimistic Lock은 시스템의 구성에 따라 꼭 필요하기도 하고, 없어도 상관없는 경우가 있습니다. Transaction의 기Term이 긴 시스템이라면 반드시 필요합니다. 구현은 프로시저를 사용하지 않고 코드에서 구현한다면, 상당한 작업량이 될 수 있습니다. 만일 프로시저를 사용할 수 없다라면, OR-Map의 도입도 고려해 보는 것도 좋다라고 생각합니다.
Trigger를 이용한 Transaction을 Table에 기록하는 것은 고객의 동작을 기록해 놓는 것으로 , 안전성의 의미가 큽니다.
Procedure를 이용한 DML은 parameter check도 코드에서 하는 것이 아니라 procedure에서 하겠다는 얘기입니다. Data기록의 로직은 Database의 Procedure에 두겠다는 것은 한 가지 언어 이외에도 복수의 언어로 구성된 시스템에서 동일한 기록의 동작을 보장합니다.
이것은 DB에 매우 큰 로드를 걸지 않는 한, 매우 바람직합니다라고 생각됩니다만, 실제로 많이 사용되는 경우는 보기 어려웠습니다. 특히 Procedure를 사용하지 않고, Application서버가 여러대로 분산되어 있을 경우 부하를 DB보다는 Application서버에 두려 하는 경우, 또 OR-Mapper를 더 선호해서 이를 통한 DML 작업을 하는 경우가 이유로 많이 제시되곤 했습니다.
그러나 잘 생각해보면, Hibernate등의 OR-Mapper를 사용한다고 하더라도 Select에 대한 작업은 Cache Provider등을 사용해 이득을 볼 수 있지만, Insert Update Delete에 대한 작업이 그리 많이 이득을 볼 수 있는 시스템이라고 확실히 얘기할 수 있는 시스템은 많지 않은 것 같습니다.
Hibernate등을 선호하는 케이스라면, 시스템이 허용하는 한, 사용해도 좋다고 생각합니다.
이런 경우라면 insert update delete 명령어를 금지하면 안되겠지만, DBA계정이 아닌, Application이 사용하는 계정이라면 금지를 생각해보는 것도 가능할 지 모릅니다.(실제 그렇게 운영해 본 적은 없습니다만...)
아아.. 오늘은 이만 해야겠습니다.
이 문서는 완전한 것이 아니므로 추가될 것입니다.
Saturday, June 20, 2009
Today, I kicked a small project off for me.
오늘 부터 작은 실험을 시작하려고 합니다.
어떤 실험인가 하면, 가끔 적는 이 블로그에, 한글은 물론, 일본어와 영어로 적어보려고 합니다.
제가 적는 블로그는 회사의 업무시간 가운데에 적는 것이 많습니다.(그래서 매우 단편적이면서, 깊지 않은 내용들이 많습니다.)
그렇기 때문에 처음에는 하나의 언어로만 적어두었다가 나중에 나머지 언어의 내용을 추가해 적는 경우도 있을 것입니다.
이상한 문장도 많이 쓰고, 뜻이 잘 못 전달 되는 경우도 있을 것입니다.
하지만 몇 년 꾸준히 계속하면 큰 공부가 될 것으로 기대합니다.
방문해 주시는 분께는 한가지 부탁으로, 잘 못된 문장을 지적해 주시면 제게는 큰 공부가 될 것입니다.
아무쪼록 잘 부탁드립니다.
====
今日から自分のためにひとつの小さい実験を始めようと思います。
どんな実験なのかというと、たまに書くこのブログに、ハングルは勿論、日本語と英語も一緒に書いて見ようと思います。
私の書くブログは会社の業務時間の中に書くことが多いです。(それで非常に断片的だし、深くない内容が多いです。)
そうだから初めには一つの言語でだけ書き留めてから後で残り言語の内容を追加して書く場合もあるでしょう。
変な文章もたくさん書いてしまい、意味がよく伝えられない場合もあるでしょう。
しかし何年弛まず続けば大きい勉強になることで期待します。
訪問していただいた方にはひとつお願いがありまして、間違った文章を指摘していただければ、私には大きい勉強になると信じています。
なにとぞよろしくお願いいたします。
====
Today, I kicked a small project off for me.
to say what it is, it is writing my blog posts with Hangul (of course!), japanese and english at once.
I usually write my posts in working time( that's why they are piecemeal and outline-like)
so I might publish posts written with one language and add other languages later.
sentences will be wrong and ridiculous.
but I will hang on it for years and it will be a good study
to visitors, please leave your comment for me.
your little advice for my wrong english is great help
thank you.
어떤 실험인가 하면, 가끔 적는 이 블로그에, 한글은 물론, 일본어와 영어로 적어보려고 합니다.
제가 적는 블로그는 회사의 업무시간 가운데에 적는 것이 많습니다.(그래서 매우 단편적이면서, 깊지 않은 내용들이 많습니다.)
그렇기 때문에 처음에는 하나의 언어로만 적어두었다가 나중에 나머지 언어의 내용을 추가해 적는 경우도 있을 것입니다.
이상한 문장도 많이 쓰고, 뜻이 잘 못 전달 되는 경우도 있을 것입니다.
하지만 몇 년 꾸준히 계속하면 큰 공부가 될 것으로 기대합니다.
방문해 주시는 분께는 한가지 부탁으로, 잘 못된 문장을 지적해 주시면 제게는 큰 공부가 될 것입니다.
아무쪼록 잘 부탁드립니다.
====
今日から自分のためにひとつの小さい実験を始めようと思います。
どんな実験なのかというと、たまに書くこのブログに、ハングルは勿論、日本語と英語も一緒に書いて見ようと思います。
私の書くブログは会社の業務時間の中に書くことが多いです。(それで非常に断片的だし、深くない内容が多いです。)
そうだから初めには一つの言語でだけ書き留めてから後で残り言語の内容を追加して書く場合もあるでしょう。
変な文章もたくさん書いてしまい、意味がよく伝えられない場合もあるでしょう。
しかし何年弛まず続けば大きい勉強になることで期待します。
訪問していただいた方にはひとつお願いがありまして、間違った文章を指摘していただければ、私には大きい勉強になると信じています。
なにとぞよろしくお願いいたします。
====
Today, I kicked a small project off for me.
to say what it is, it is writing my blog posts with Hangul (of course!), japanese and english at once.
I usually write my posts in working time( that's why they are piecemeal and outline-like)
so I might publish posts written with one language and add other languages later.
sentences will be wrong and ridiculous.
but I will hang on it for years and it will be a good study
to visitors, please leave your comment for me.
your little advice for my wrong english is great help
thank you.
Friday, June 19, 2009
groovy cgi
groovy파일을 cgi로 이용해 사용하는 장난(?)을 하다가, parameter를 받는 작업을 하던중, 제대로 처리하게 하지 못해서 애를 좀 먹었습니다.
한글이나 일본어가 깨지는 현상때문이었는데요. 파일도 utf-8(without BOM), 그리고 groovy.exe의 실행옵션에서 도움말에 있는 --encoding UTF-8 이나 -c UTF-8을 아무리 주어도 제대로 표시되지 않았습니다. 아파치의 설정이 잘못된 것인지도 보고, 옵션이 먹지 않는지 레지스트리의 .groovy파일 실행할 때 디폴트 옵션을 줘보기도 했습니다만, 해결은 다른 방법으로 되었습니다. 옵션에 -Dfile.encoding=UTF-8 을 주고 실행하는 것이었습니다.
아마도, 스펙대로라면 -Dfile.encoding=UTF-8 이 없어도 잘 표시되어야 할 것 같은데...., 잘 되지 않았습니다.
html 태그가 있어 본문에 에러가 있다고 하니 일본어의 전각 괄호로 바꾸었습니다.
그리고 아래가 실행 내용입니다.
한글이나 일본어가 깨지는 현상때문이었는데요. 파일도 utf-8(without BOM), 그리고 groovy.exe의 실행옵션에서 도움말에 있는 --encoding UTF-8 이나 -c UTF-8을 아무리 주어도 제대로 표시되지 않았습니다. 아파치의 설정이 잘못된 것인지도 보고, 옵션이 먹지 않는지 레지스트리의 .groovy파일 실행할 때 디폴트 옵션을 줘보기도 했습니다만, 해결은 다른 방법으로 되었습니다. 옵션에 -Dfile.encoding=UTF-8 을 주고 실행하는 것이었습니다.
아마도, 스펙대로라면 -Dfile.encoding=UTF-8 이 없어도 잘 표시되어야 할 것 같은데...., 잘 되지 않았습니다.
#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe -Dfile.encoding=UTF-8
//C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe -c utf-8 -D file.encoding=UTF-8
import java.net.URLDecoder;
def decoder = URLDecoder;
print "Content-type: text/html\n\n"
print "＜html＞＜head＞＜meta content='text/html; charset=utf-8' http-equiv='Content-Type'/＞＜/head＞＜body＞"
def name='World'; println "Hello $name!"
/* == to show all env variables
def env = System.getenv()
for(k in env){
println(k)
} */
def __form = [:]
def arrykeyvalue
def strQueryString = System.getenv()['QUERY_STRING']
if (strQueryString != null) {
def arryForm = strQueryString.split('&')
arryForm.each {
arrykeyvalue = it.split('=')
__form.put(arrykeyvalue[0], arrykeyvalue[1])
}
}
__form.each {
print (it.key + ' = ' + it.value+ '＜br＞')
}
__form.each {
print (it.key + ' = ' + decoder.decode(it.value, "UTF8") + '＜br＞')
}
print "日本語 ＜br＞ "
print "한국어 ＜br＞ "
print "＜/body＞＜/html＞"
html 태그가 있어 본문에 에러가 있다고 하니 일본어의 전각 괄호로 바꾸었습니다.
그리고 아래가 실행 내용입니다.
Wednesday, June 17, 2009
[정보공유] 윈도우즈환경에서 groovy로 cgi하기
최근에는 perl 프로젝트를 하고 있는 영향도 있지만, cgi의 재발견이랄까 재미를 느끼고 있는 것은 사실입니다.
도메인이니, 모델이니, DAO니 BL이니 하는 라이브러리를 만들고 난 뒤 여러 복잡한 프레임웍의 설정과 웹어플리케이션의 설정을 하고 나서야 페이지 하나를 볼 수 있는 엔터프라이즈급의 개발은 분명 가벼운 마음으로 할 수 있는 것은 아닙니다.
작은 프로그래밍을 가벼운 마음으로 해보기 부담스러운 것은 grails, gsp도 마찬가지에요. 그런의미에서 cgi는 상대적으로 부담이 적기 때문에 작은 프로그래밍을 해보기에는 적합합니다.
groovy로 cgi를 하는 방법은 전에도 한번 시도해보았었습니다만, 윈도우즈환경은 리눅스와 달리 groovy.bat 파일로 실행되는 결과를 output으로 보내기에는 적합하지 못했습니다. 왜냐하면 아파치 프로세스가 cgi용 파일을 만나면 그 파일을 열어 Shebang #! 을 보고 어떤 명령을 실행해서 값을 구할 지 처리하는 과정에서, cgi용 파일에 groovy.bat로 해석하라고 전달하게 되는데 ,
아파치 process가 groovy.bat test.goory 명령을 실행하면, 그 프로세스에 output이 return되어 지는 것이 아니라, bat파일을 해석하기 위해 %comspec%가 실행된 다음 그 프로세스안에서 다시 jre를 실행한 뒤 결과값인 output이 나오기 때문에, bat를 실행시킨 process에서는 output을 구할 수 없기 때문입니다.
Shebang을 사용하지 않고 AddHandler나 Registry에 Associated Application을 설정한 경우에도 잘 되지 못했습니다.
이야기가 길어졌습니다만, 결론은, 윈도우에서 제대로 groovy파일을 cgi로 사용하지 못했다. 라는 이야기 입니다.
반면 아마도 리눅스 환경에서는 -시도해 본 일은 없습니다만 - 아파치프로세스가 groovy 쉘 스크립트를 실행하여 output을 얻는 것은 특별히 문제가 되지 않을 것 같다는 생각이고, 또 그렇게 했다는 블로그를 본 적도 있습니다.
=============
그런데 최근 잠깐 살펴보니 Native Launcher 라는 것이 등장해 있었군요.
http://groovy.codehaus.org/Native+Launcher
groovy.exe를 바로 다운받을 수 있는 링크도 있습니다.
왜 groovy.exe를 사용해야 하는지 적어놓은 부분도 있습니다만, 여기에는 cgi 이야기는 없군요. (원래 할 수 있는 것을 제가 못해낸 건지도 모르겠습니다.)
어쨌든, 이 groovy.exe로 cgi설정을 해보았습니다. (apache와 groovy까지는 설치되어 있다고 가정합니다.)
groovy.bat 파일을 groovy.bat.old 로 옮기고,
httpd.conf 안에 LoadModule이 끝나는 곳에 다음 한 줄 추가
setEnv GROOVY_HOME c:\Progra~1\Java\groovy-1.6.0
(또는 PassEnv GROOVY_HOME 해도 되나요. 확인해 보지 않았습니다.)
그리고 .groovy파일 더블클릭하면 groovy.exe파일이 실행되도록 설정해 놓고. AddHandler는 특별히 추가하지 않았습니다.
그리고 다음과 같이 test.groovy cgi를 하나 만들고
#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"
def name='World'; println "Hello $name!"
실행해 보았습니다.
-_-)=b
HtmlBuilder까지 사용하는 것은 무난할 것 같습니다.
#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"
def writer = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(writer)
builder.html(){
head(){
title("Groov'n with Builders"){}
}
body(){
p("""Welcome to Builders 101. As you can see
this Groovlet is fairly simple.""")
}
}
println writer.toString()
하지만 servlet이 아니므로 request나 response등의 객체는 사용할 수 없습니다. (사용하게 하려면 매번 web.xml을 읽어 ServletConfig를 new 하고, Servlet을 new하고... 해야 할 것 같습니다.)
앞으로 CGI방식으로 %ENV%에서 값을 받아오는 Method나 Class를 만들어보죠.
도메인이니, 모델이니, DAO니 BL이니 하는 라이브러리를 만들고 난 뒤 여러 복잡한 프레임웍의 설정과 웹어플리케이션의 설정을 하고 나서야 페이지 하나를 볼 수 있는 엔터프라이즈급의 개발은 분명 가벼운 마음으로 할 수 있는 것은 아닙니다.
작은 프로그래밍을 가벼운 마음으로 해보기 부담스러운 것은 grails, gsp도 마찬가지에요. 그런의미에서 cgi는 상대적으로 부담이 적기 때문에 작은 프로그래밍을 해보기에는 적합합니다.
groovy로 cgi를 하는 방법은 전에도 한번 시도해보았었습니다만, 윈도우즈환경은 리눅스와 달리 groovy.bat 파일로 실행되는 결과를 output으로 보내기에는 적합하지 못했습니다. 왜냐하면 아파치 프로세스가 cgi용 파일을 만나면 그 파일을 열어 Shebang #! 을 보고 어떤 명령을 실행해서 값을 구할 지 처리하는 과정에서, cgi용 파일에 groovy.bat로 해석하라고 전달하게 되는데 ,
아파치 process가 groovy.bat test.goory 명령을 실행하면, 그 프로세스에 output이 return되어 지는 것이 아니라, bat파일을 해석하기 위해 %comspec%가 실행된 다음 그 프로세스안에서 다시 jre를 실행한 뒤 결과값인 output이 나오기 때문에, bat를 실행시킨 process에서는 output을 구할 수 없기 때문입니다.
Shebang을 사용하지 않고 AddHandler나 Registry에 Associated Application을 설정한 경우에도 잘 되지 못했습니다.
이야기가 길어졌습니다만, 결론은, 윈도우에서 제대로 groovy파일을 cgi로 사용하지 못했다. 라는 이야기 입니다.
반면 아마도 리눅스 환경에서는 -시도해 본 일은 없습니다만 - 아파치프로세스가 groovy 쉘 스크립트를 실행하여 output을 얻는 것은 특별히 문제가 되지 않을 것 같다는 생각이고, 또 그렇게 했다는 블로그를 본 적도 있습니다.
=============
그런데 최근 잠깐 살펴보니 Native Launcher 라는 것이 등장해 있었군요.
http://groovy.codehaus.org/Native+Launcher
groovy.exe를 바로 다운받을 수 있는 링크도 있습니다.
왜 groovy.exe를 사용해야 하는지 적어놓은 부분도 있습니다만, 여기에는 cgi 이야기는 없군요. (원래 할 수 있는 것을 제가 못해낸 건지도 모르겠습니다.)
어쨌든, 이 groovy.exe로 cgi설정을 해보았습니다. (apache와 groovy까지는 설치되어 있다고 가정합니다.)
groovy.bat 파일을 groovy.bat.old 로 옮기고,
httpd.conf 안에 LoadModule이 끝나는 곳에 다음 한 줄 추가
setEnv GROOVY_HOME c:\Progra~1\Java\groovy-1.6.0
(또는 PassEnv GROOVY_HOME 해도 되나요. 확인해 보지 않았습니다.)
그리고 .groovy파일 더블클릭하면 groovy.exe파일이 실행되도록 설정해 놓고. AddHandler는 특별히 추가하지 않았습니다.
그리고 다음과 같이 test.groovy cgi를 하나 만들고
#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"
def name='World'; println "Hello $name!"
실행해 보았습니다.
-_-)=b
HtmlBuilder까지 사용하는 것은 무난할 것 같습니다.
#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"
def writer = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(writer)
builder.html(){
head(){
title("Groov'n with Builders"){}
}
body(){
p("""Welcome to Builders 101. As you can see
this Groovlet is fairly simple.""")
}
}
println writer.toString()
하지만 servlet이 아니므로 request나 response등의 객체는 사용할 수 없습니다. (사용하게 하려면 매번 web.xml을 읽어 ServletConfig를 new 하고, Servlet을 new하고... 해야 할 것 같습니다.)
앞으로 CGI방식으로 %ENV%에서 값을 받아오는 Method나 Class를 만들어보죠.
Monday, June 15, 2009
「폰더씨의 실천하는 하루」에서
「폰더씨의 실천하는 하루」에서
함께 어울리는 사람을 선택하는 과정에서 한 가지 염두에 둘 게 있다.
친구를 선택할 때에는 신중해야 한다는 것이다. 나는 사람들에게 종종 "당신이 생각하는 진정한 친구는 어떤 사람입니까?"라고 묻는다. 80퍼센트 이상의 사람이 "진정한 친구란 있는 그대로의 내 모습을 받아들이는 사람"이라고 답한다. 세상에! 이건 정말 위험한 발상이다. 동네 페스트푸드 식당의 아르바이트생은 있는 그대로의 내 모습을 받아들인다. 왜냐면 그는 나와 아무 관련이 없기 때문이다.
진정한 친구란 '나를 보다 높은 수준으로 끌어올려 주는 사람'이다. 그가 내 곁에 있음으로써 내가 보다 나은 사람이 될 수 있게 하는 존재다.
「폰더씨의 실천하는 하루」 Chapter "동료의 힘", 한글판 78페이지.
그리고 나는 여기에 매우 동의합니다.
김동현.
함께 어울리는 사람을 선택하는 과정에서 한 가지 염두에 둘 게 있다.
친구를 선택할 때에는 신중해야 한다는 것이다. 나는 사람들에게 종종 "당신이 생각하는 진정한 친구는 어떤 사람입니까?"라고 묻는다. 80퍼센트 이상의 사람이 "진정한 친구란 있는 그대로의 내 모습을 받아들이는 사람"이라고 답한다. 세상에! 이건 정말 위험한 발상이다. 동네 페스트푸드 식당의 아르바이트생은 있는 그대로의 내 모습을 받아들인다. 왜냐면 그는 나와 아무 관련이 없기 때문이다.
진정한 친구란 '나를 보다 높은 수준으로 끌어올려 주는 사람'이다. 그가 내 곁에 있음으로써 내가 보다 나은 사람이 될 수 있게 하는 존재다.
「폰더씨의 실천하는 하루」 Chapter "동료의 힘", 한글판 78페이지.
그리고 나는 여기에 매우 동의합니다.
김동현.
Sunday, June 14, 2009
[세상에 이런일이] 회의중 만들어낸 명령어
[세상에 이런일이]
금요일 회의중에 시스템 엔지니어 郷古상이 잠깐 기다려 보라며, 만들어낸 리눅스 명령행
for aln in `vzctl exec 200 "chkconfig --list | cut -f1 | sort | uniq | grep -v ":" | egrep -v '^$'"`;do vzctl exec 200 service $aln status > /dev/null 2>&1;ret=$? ;echo "$aln: $ret";done
한줄 명령이며 이 안에 외부 커맨드는 7개가 들어가 있습니다.
그리고 완벽하게 잘 실행되었습니다.
그는 이런 명령어를 그자리에서 만들어서 보여준, 내가 만난 두 번째 일본인입니다.
-_-)=b
금요일 회의중에 시스템 엔지니어 郷古상이 잠깐 기다려 보라며, 만들어낸 리눅스 명령행
for aln in `vzctl exec 200 "chkconfig --list | cut -f1 | sort | uniq | grep -v ":" | egrep -v '^$'"`;do vzctl exec 200 service $aln status > /dev/null 2>&1;ret=$? ;echo "$aln: $ret";done
한줄 명령이며 이 안에 외부 커맨드는 7개가 들어가 있습니다.
그리고 완벽하게 잘 실행되었습니다.
그는 이런 명령어를 그자리에서 만들어서 보여준, 내가 만난 두 번째 일본인입니다.
-_-)=b
Monday, June 8, 2009
어떤 방법(또는 어떤 라이브러리)이 좋은지 결정할 때.(git vs svn)
최근 git이 많이 쓰이고 있는데, svn과 비교해 어떤 장점이 있는지 궁금한 적이 있었습니다.
물론 공식 페이지도 열람은 해둡니다만 이 두가지에 대한 사용자의 경험을 보고 싶을 때가 있습니다.
이런 경우 나는 (앤드류가 자주 사용했던 방법을 따라서 하는데) A vs B 라고 하는 검색을 많이 합니다.
google의 search keyword입력창에서는 A vs ... 라고만 입력해도, 자동완성기능으로 비교가 되는 것들을 표시해 줍니다.
주의해서 봐야 할 점은, 대게의 경우 양쪽 모두 advantage와 disadvantage를 가지고 있을 텐데, 한쪽에만 치우쳐서 얘기하는 것은 그다지 참고가 되지 않습니다.
다음은 가장 도움이 되었다고 생각하는 git과 svn의 비교 post입니다.
====
Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos.
Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures)
Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows.
You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other.
I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)
====
플러스, 최근에는 tortoisegit 이 나와 있습니다.
아. 결론으로는 지금은 svn, git은 좀 더 나중에... 라는 입장을 취하게 되었습니다.
물론 공식 페이지도 열람은 해둡니다만 이 두가지에 대한 사용자의 경험을 보고 싶을 때가 있습니다.
이런 경우 나는 (앤드류가 자주 사용했던 방법을 따라서 하는데) A vs B 라고 하는 검색을 많이 합니다.
google의 search keyword입력창에서는 A vs ... 라고만 입력해도, 자동완성기능으로 비교가 되는 것들을 표시해 줍니다.
주의해서 봐야 할 점은, 대게의 경우 양쪽 모두 advantage와 disadvantage를 가지고 있을 텐데, 한쪽에만 치우쳐서 얘기하는 것은 그다지 참고가 되지 않습니다.다음은 가장 도움이 되었다고 생각하는 git과 svn의 비교 post입니다.
====
Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos.
Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures)
Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows.
You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other.
I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)
====
플러스, 최근에는 tortoisegit 이 나와 있습니다.
아. 결론으로는 지금은 svn, git은 좀 더 나중에... 라는 입장을 취하게 되었습니다.
groovy로 jude api를 이용하기
일본에서 java엔지니어에게 UML의 다이어그램을 그리라고 하면, jude-community를 꼽는 사람들이 많습니다. (윈도우즈 계열의 엔지니어라면 역시 visio를 사용하는 것 같습니다.)
jude-community는 무료이고, reverse engineering이 됩니다.
더 많은 기능을 지원하는 jude-professional도 있습니다만, 30일 평가판이후 라이센스 등록을 요구합니다.(그러나 실행하기 전에 시스템의 날짜를 평가판 사용기간의 날짜로 바꾸어 실행하는 것정도는 할 수 있네요)
자체로 몰론 GUI의 어플리케이션입니다만, 이 둘다 api를 제공하고 있습니다. 이 API로, save한 .jude파일을 읽거나 edit하는 것이 가능합니다. api는 jar의 형태로 제공하고 있습니다.
이를 사용해서 java로 save한 jude파일을 제어할 수 있습니다만, 이러한 작업이라면 역시 groovy를 사용하는 쪽이 더 매력적이라고 생각합니다.
다음은 groovy를 사용하여 jude의 api에 접근하는 방법을 나타냅니다.
우선 groovy를 실행할 때, API를 함께 load하도록 합니다.
>edit c:\Program Files\Java\groovy\conf\groovy-starter.conf
해서 다음을 추가
load /Progra~1/JUDE-P~1/*.jar
그리고 이하는 groovy script 소스입니다
class_listup.groovy
제가 이 방법에 관심을 가지는 이유는, 바퀴를 재발명하지 않고, 잘 정의된 jude의 api를 이용하여, gui가 아닌 text 형태의 방식으로 쉽게 여러 아이디어를 구조화 하는데 도움이 될 수 있겠다고 생각해서 입니다. 아마 emeditor의 macro가 하나 더 증가 할 것 같군요. :)
jude-community는 무료이고, reverse engineering이 됩니다.
더 많은 기능을 지원하는 jude-professional도 있습니다만, 30일 평가판이후 라이센스 등록을 요구합니다.(그러나 실행하기 전에 시스템의 날짜를 평가판 사용기간의 날짜로 바꾸어 실행하는 것정도는 할 수 있네요)
자체로 몰론 GUI의 어플리케이션입니다만, 이 둘다 api를 제공하고 있습니다. 이 API로, save한 .jude파일을 읽거나 edit하는 것이 가능합니다. api는 jar의 형태로 제공하고 있습니다.
이를 사용해서 java로 save한 jude파일을 제어할 수 있습니다만, 이러한 작업이라면 역시 groovy를 사용하는 쪽이 더 매력적이라고 생각합니다.
다음은 groovy를 사용하여 jude의 api에 접근하는 방법을 나타냅니다.
우선 groovy를 실행할 때, API를 함께 load하도록 합니다.
>edit c:\Program Files\Java\groovy\conf\groovy-starter.conf
해서 다음을 추가
load /Progra~1/JUDE-P~1/*.jar
그리고 이하는 groovy script 소스입니다
class_listup.groovy
import com.change_vision.jude.api.inf.project.*
import com.change_vision.jude.api.inf.model.*
scriptName = System.getProperty("script.name")
if (args.length < 1) {
println "groovy ${scriptName} [jude fileName]"
return
}
def printClasses(packageObj) {
packageObj.ownedElements.each {
if (it instanceof IClass) {
println it.name
}
else if(it instanceof IPackage) {
printClasses(it)
}
}
}
def pro = ProjectAccessorFactory.projectAccessor
pro.open(args[0])
printClasses(pro.project)
pro.close()
제가 이 방법에 관심을 가지는 이유는, 바퀴를 재발명하지 않고, 잘 정의된 jude의 api를 이용하여, gui가 아닌 text 형태의 방식으로 쉽게 여러 아이디어를 구조화 하는데 도움이 될 수 있겠다고 생각해서 입니다. 아마 emeditor의 macro가 하나 더 증가 할 것 같군요. :)
Sunday, June 7, 2009
[정보공유] MySql의 Transaction의 주의점
[정보공유]
MSSql이나 Oracle은 Begin Transaction이 Stack처럼 움직이는 반면.
MySql의 Start Transaction은 Stack처럼 움직이는 것이 아니라 Flag가 서 있는 것처럼 움직이므로 중첩되지 않음.
다음과 같은 쿼리에서 주의할 것.
UpdateSomeTable set AField = 0;
Start Transaction;
UpdateSomeTable set AField = 1;
call usp_AProcedure /* <-- 이 안에서 커밋 */
RollBack;
이때 마지막의 RollBack해도 AField의 값은 0으로 돌아오지 않음.
MSSql이나 Oracle은 Begin Transaction이 Stack처럼 움직이는 반면.
MySql의 Start Transaction은 Stack처럼 움직이는 것이 아니라 Flag가 서 있는 것처럼 움직이므로 중첩되지 않음.
다음과 같은 쿼리에서 주의할 것.
UpdateSomeTable set AField = 0;
Start Transaction;
UpdateSomeTable set AField = 1;
call usp_AProcedure /* <-- 이 안에서 커밋 */
RollBack;
이때 마지막의 RollBack해도 AField의 값은 0으로 돌아오지 않음.
Wednesday, June 3, 2009
[정보공유]Windows에서 80포트를 IIS와 Apache가 동시 사용하는 방법
[정보공유]Windows에서 80포트를 IIS와 Apache가 동시 사용하는 방법
80Port를 IIS와 Apache가 동시에 사용하려면 다음의 툴을 사용합니다.
Windows Server 2003 Service Pack1 32-bit Support Tools
http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
실행은
c:\Program Files\Support Tooles>httpcfg.exe set iplisten -i 192.168.xx.xx<엔터>
HttpSetServiceConfiguration completed with 0.
2003용이지만 XP에서도 사용이 가능합니다.
이상.
80Port를 IIS와 Apache가 동시에 사용하려면 다음의 툴을 사용합니다.
Windows Server 2003 Service Pack1 32-bit Support Tools
http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
실행은
c:\Program Files\Support Tooles>httpcfg.exe set iplisten -i 192.168.xx.xx<엔터>
HttpSetServiceConfiguration completed with 0.
2003용이지만 XP에서도 사용이 가능합니다.
이상.
Tuesday, June 2, 2009
오늘 utf8을 지원하는 윈도우즈용 그래픽 콘솔을 발견했습니다.
오늘 utf8을 지원하는 윈도우즈용 그래픽 콘솔을 찾았읍니다. 현재로서는 이것이 무료로 사용할 수 있는 유일한 방법인 것 같습니다.
이 콘솔은 다름아닌 Windows PowerShell V2 Community Technology Preview 3 (CTP3) 입니다.
test4.pl의 소스는 다음과 같습니다.
print "한국어\n";
print "日本語\n";
인코딩은 utf-8 without BOM
이를 인스톨하기 위해 전에 설치했던 Powershell 1.0을 Uninstall해야 했는데요. appwiz.cpl에서 보아도 uninstall을 찾을 수 없었습니다만, 다음의 커맨드로 해결했습니다.
powershell 1.0 삭제하기
%windir%\\$NtUninstallKB926139$\spuninst\spuninst.exe /quiet /passive
폰트를 바꾸거나 하는 것은 어떻게 하는지 아직 모릅니다만, 그런대로 만족합니다. :)
아. 사용할 때 chcp 65001을 해주셔야 합니다.
이 콘솔은 다름아닌 Windows PowerShell V2 Community Technology Preview 3 (CTP3) 입니다.
test4.pl의 소스는 다음과 같습니다.
print "한국어\n";
print "日本語\n";
인코딩은 utf-8 without BOM
이를 인스톨하기 위해 전에 설치했던 Powershell 1.0을 Uninstall해야 했는데요. appwiz.cpl에서 보아도 uninstall을 찾을 수 없었습니다만, 다음의 커맨드로 해결했습니다.
powershell 1.0 삭제하기
%windir%\\$NtUninstallKB926139$\spuninst\spuninst.exe /quiet /passive
폰트를 바꾸거나 하는 것은 어떻게 하는지 아직 모릅니다만, 그런대로 만족합니다. :)
아. 사용할 때 chcp 65001을 해주셔야 합니다.
[정보공유] 온라인 한글 맞춤법 검사기
[정보공유]
온라인 한글 맞춤법 검사기
http://164.125.36.47/urimal-spellcheck.html
블로그를 쓰면서 혹시 맞춤법이 신경쓰여 찾아보게 되었음.
혹시 자녀가 있다면, 아이에게 바른 한글을 가르칠 때도 도움이 될 것 같음.
이상.
woo_김택우 says:
http://lab.naver.com/
woo_김택우 says:
이거 알지??
（Dev） Kim tonghyun says:
오- 몰랐어
woo_김택우 says:
음 써봐 재미있어
온라인 한글 맞춤법 검사기
http://164.125.36.47/urimal-spellcheck.html
블로그를 쓰면서 혹시 맞춤법이 신경쓰여 찾아보게 되었음.
혹시 자녀가 있다면, 아이에게 바른 한글을 가르칠 때도 도움이 될 것 같음.
이상.
woo_김택우 says:
http://lab.naver.com/
woo_김택우 says:
이거 알지??
（Dev） Kim tonghyun says:
오- 몰랐어
woo_김택우 says:
음 써봐 재미있어
이성식의 [앞서가는 소수-짧은이야기]에서 소개받은 팃포탯(Tit for Tat) 전략
저는 이성식의 [앞서가는 소수-짧은이야기]를 메일링 리스트로 받아보고 있습니다.
삼성경제연구소(www.seri.org)의 포럼 "앞서가는소수/IT,기획,전략,조직관리,역량,리더쉽,CMM,PM,CRM,CIO"에 등록되어 있습니다.
매번 좋은 기사로 신세를 지고 있습니다만, 어제 팃포탯이라고 가상게임에서 승리한 전략프로그램의 로직을 소개하는 메일링 리스트의 메일이 도착해 있었습니다.
내용을 소개하면
====
팃포탯 전략
프로그램간의 가상게임에서 승리한 전략프로그램의 로직.
"내가 먼저 상대에게 협력하는 자세를 보인다.
그리고 그 협력하는 자세에 대해 상대가 협력 자세로 대응하면 다시 나 또한 협력하고,
상대가 배신하는 자세로 대응하면 나 또한 배신하는 자세로 대응한다."
도움과 배신이라는 상황에서 우리가 가장 많이 들어왔던 전략은 '눈에는 눈,이에는 이'다.
곧, 도움에는 도움으로, 배신에는 배신으로 응해 주는 것이다.
팃포탯 전략이 이와 다른 것은, 먼저 도움을 준다는 사실이다.
중국 철학자 증자는 말했다.
"남이 나를 소중히 여기기를 바란다면, 내가 먼저 남을 수중하게 여겨야 한다."
====
구글에서 검색한 또다른 기사의 팃포탯입니다.
<미국 미시간대 정치학자 로버트 액설로드는 1980년 게임이론 전문가들을 토너먼트 게임에 초대했다.
참가자들은 컴퓨터를 이용해 각각의 최상의 전략으로 상대와 게임을 벌였다.
이 게임 승자는 캐나다 토론토 대학의 아나톨 라포포트가 만든 ‘티포탯(Tit for Tat=맞받아 응수하기)’ 프로그램이었다.
참가자들은 이 결과에 입을 다물지 못했다.
‘이에는 이, 눈에는 눈’이라는 이 티포탯 전략이 너무나 단순했기 때문이다. 이 전략의 시작은 협조다.
그 뒤에는 상대방이 하는 것을 따라한다.
상대가 협조하면 협조하고, 속이면 똑같은 방법으로 보복을 한다. 그러면서 때때로 용서를 한다.>
====
가끔, 이미 아는, 단순한 사실로부터 다시 그 가치를 느끼는 일이 있습니다.
(몸으로 실천하지 않으면, 알고 있는 것이 아니라, '들은 적이 있는 것'이겠지요.)
이 기사로도 느낀 점은 많지만, 그것을 한마디로 정리하긴 어렵네요.
한가지 지금 분명히 말 할 수 있는 것은, "협조하는 사람을 더 잘 챙겨야겠다" 입니다.
삼성경제연구소(www.seri.org)의 포럼 "앞서가는소수/IT,기획,전략,조직관리,역량,리더쉽,CMM,PM,CRM,CIO"에 등록되어 있습니다.
매번 좋은 기사로 신세를 지고 있습니다만, 어제 팃포탯이라고 가상게임에서 승리한 전략프로그램의 로직을 소개하는 메일링 리스트의 메일이 도착해 있었습니다.
내용을 소개하면
====
팃포탯 전략
프로그램간의 가상게임에서 승리한 전략프로그램의 로직.
"내가 먼저 상대에게 협력하는 자세를 보인다.
그리고 그 협력하는 자세에 대해 상대가 협력 자세로 대응하면 다시 나 또한 협력하고,
상대가 배신하는 자세로 대응하면 나 또한 배신하는 자세로 대응한다."
도움과 배신이라는 상황에서 우리가 가장 많이 들어왔던 전략은 '눈에는 눈,이에는 이'다.
곧, 도움에는 도움으로, 배신에는 배신으로 응해 주는 것이다.
팃포탯 전략이 이와 다른 것은, 먼저 도움을 준다는 사실이다.
중국 철학자 증자는 말했다.
"남이 나를 소중히 여기기를 바란다면, 내가 먼저 남을 수중하게 여겨야 한다."
====
구글에서 검색한 또다른 기사의 팃포탯입니다.
<미국 미시간대 정치학자 로버트 액설로드는 1980년 게임이론 전문가들을 토너먼트 게임에 초대했다.
참가자들은 컴퓨터를 이용해 각각의 최상의 전략으로 상대와 게임을 벌였다.
이 게임 승자는 캐나다 토론토 대학의 아나톨 라포포트가 만든 ‘티포탯(Tit for Tat=맞받아 응수하기)’ 프로그램이었다.
참가자들은 이 결과에 입을 다물지 못했다.
‘이에는 이, 눈에는 눈’이라는 이 티포탯 전략이 너무나 단순했기 때문이다. 이 전략의 시작은 협조다.
그 뒤에는 상대방이 하는 것을 따라한다.
상대가 협조하면 협조하고, 속이면 똑같은 방법으로 보복을 한다. 그러면서 때때로 용서를 한다.>
====
가끔, 이미 아는, 단순한 사실로부터 다시 그 가치를 느끼는 일이 있습니다.
(몸으로 실천하지 않으면, 알고 있는 것이 아니라, '들은 적이 있는 것'이겠지요.)
이 기사로도 느낀 점은 많지만, 그것을 한마디로 정리하긴 어렵네요.
한가지 지금 분명히 말 할 수 있는 것은, "협조하는 사람을 더 잘 챙겨야겠다" 입니다.
Tuesday, May 26, 2009
[정보공유] Perl DBI / CGI 에서 DBI의 에러처리
Perl DBI / CGI 에서 DBI의 에러처리
아무리 eval{} 로 감쌌어도 $@가 나오지 않았습니다.
다만, 로그파일에는 에러가 제대로 적혀 있었습니다.
이건, DBI의 에러가 warning이 되어 출력되고 있는 것이었습니다.
connect할 때, RaiseError를 사용하는 것을 깜빡하고 있었습니다.
my $dbh = DBI->connect(
'DBI:mysql:dbname', 'user', 'password',
{AutoCommit => 0, RaiseError => 1, PrintError => 0}
) || die;
이것으로 재대로 $@를 catch할 수 있었습니다.
아무리 eval{} 로 감쌌어도 $@가 나오지 않았습니다.
다만, 로그파일에는 에러가 제대로 적혀 있었습니다.
이건, DBI의 에러가 warning이 되어 출력되고 있는 것이었습니다.
connect할 때, RaiseError를 사용하는 것을 깜빡하고 있었습니다.
my $dbh = DBI->connect(
'DBI:mysql:dbname', 'user', 'password',
{AutoCommit => 0, RaiseError => 1, PrintError => 0}
) || die;
이것으로 재대로 $@를 catch할 수 있었습니다.
Friday, May 22, 2009
perl로 만드는 win util / tts.pl
보물 하나더,
제 컴퓨터에는 Microsoft SAPI (Speach API)가 설치되어 있고, Voice가 영어, 일본어가 설치되어 있습니다. (중국어는 설치했다가 삭제했습니다만.)
주로 emeditor에서 파일 편집작업을 많이 하는데 emeditor에서 TTS speech하도록 한 매크로가 있습니다만, 음성 출력이 완료되기까지 Editing작업을 할 수 없어 만들어 놓고 그다지 사용하고 있지 않았습니다.
콘솔용으로 만들 수 없는 건 아니지만, 콘솔용으로 만들었을 때, 그 프로그램에 출력하는 문장을 전달하는 것이 좀 만족스럽지 않아서 보류하고 있었습니다만,
다음의 Perl Package의 예제를 발견했습니다.
Perl로 하면, speech할 본문을 URL에서 가져온다던지, 어제 발견한 MSNd로부터 입력받은 내용을 speech하게 한다던지, 훨씬 쓰임새가 있어보입니다.
다음에는 인터넷의 자동번역하는 페이지에 post해 일본어<->한글 하는 코드를 javascript로 만들어 둔 것이 있는데 perl로 옮겨두어야 겠습니다.
제 컴퓨터에는 Microsoft SAPI (Speach API)가 설치되어 있고, Voice가 영어, 일본어가 설치되어 있습니다. (중국어는 설치했다가 삭제했습니다만.)
주로 emeditor에서 파일 편집작업을 많이 하는데 emeditor에서 TTS speech하도록 한 매크로가 있습니다만, 음성 출력이 완료되기까지 Editing작업을 할 수 없어 만들어 놓고 그다지 사용하고 있지 않았습니다.
콘솔용으로 만들 수 없는 건 아니지만, 콘솔용으로 만들었을 때, 그 프로그램에 출력하는 문장을 전달하는 것이 좀 만족스럽지 않아서 보류하고 있었습니다만,
다음의 Perl Package의 예제를 발견했습니다.
use Win32::OLE qw( EVENTS );
our $myTTS = new Win32::OLE( "Sapi.SpVoice" );
get_text();
sub get_text{
$output_speech =;
chomp($output_speech);
if($output_speech eq ":jp"){
$myTTS->{voice} = $myTTS->GetVoices("Name=VW Misaki", "Language=932")->Item(0);
}
elsif($output_speech eq ":en"){
$myTTS->{voice} = $myTTS->GetVoices("Name=VW Kate", "Language=409")->Item(0);
}
if($output_speech ne ":q"){
say_this();
get_text();
}
}
sub say_this{
$myTTS->Speak( "$output_speech" );
while( $myTTS->{Speaking} )
{
Win32::OLE->SpinMessageLoop();
Win32::Sleep( 100 );
}
}
Perl로 하면, speech할 본문을 URL에서 가져온다던지, 어제 발견한 MSNd로부터 입력받은 내용을 speech하게 한다던지, 훨씬 쓰임새가 있어보입니다.
다음에는 인터넷의 자동번역하는 페이지에 post해 일본어<->한글 하는 코드를 javascript로 만들어 둔 것이 있는데 perl로 옮겨두어야 겠습니다.
perl로 만드는 win util / msnd.pl
perl로 만드는 win util / msnd.pl
일본에서 일하든 대부분의 동료들과는 달리 저는 9시 출근입니다.
10시가 되면, 하나 둘 씩 로그인을 하지요. 그럼 저는 "오하요오" 메시지를 보냅니다.
간혹, 이런 메시지를 보내는 것이. 규칙적었는지, 혹시 로그인하면 자동으로 메시지를 보내는 프로그램을 만들어서 하고 있는 것으로 생각하는 사람들이 있었습니다. (그래서 매일 메시지를 조금씩 내용을 바꿉니다. ^^)
그런데 이런 프로그램을 만들려면 어떻게 할까요. 오늘 보물을 발견했습니다.
혹시 심심이라고 하는 MSNBot을 알고 계시다면,
그리고 예전에 있었던, 자동번역 Bot을 알고 계신다면, 그것을 제로부터 직접 만드는 것은 꽤 까다로운 작업입니다만, 아래의 MSN Package를 사용하면 그렇게 어렵지 않게 구현할 수 있습니다.
#!/usr/bin/perl
use lib qw(./MSN/lib);
use strict;
use MSN;
my $msn = MSN->new(Handle => 'youraccont@hotmail.co.jp',
Password => 'password');
$msn->setHandler(Message => \&handler_message);
$msn->connect();
while(1) {
$msn->do_one_loop
}
sub handler_message {
my ($self, $username, $name, $message, %style ) = @_;
print "Msg recv.\n";
$self->sendMessage("hello!");
}
전에 잠시 서버관리를 위해, 뭔가 Notification해야 할 일이 생긴다면 실시간으로 메시지로 받을 수 있도록 Microsoft Alert Service를 사용할까 한 적이 있었습니다.
이 패키지를 발견한 뒤로는, 필요 없을 것 같습니다. 무얼 만들까요.
Source Repository에 업데이트 되면 메시지를 보내는 어플?
CI build 가 깨지면 메시지를 보내는 어플?
다양한 방법으로 사용할 수 있을 것 같습니다. :)
일본에서 일하든 대부분의 동료들과는 달리 저는 9시 출근입니다.
10시가 되면, 하나 둘 씩 로그인을 하지요. 그럼 저는 "오하요오" 메시지를 보냅니다.
간혹, 이런 메시지를 보내는 것이. 규칙적었는지, 혹시 로그인하면 자동으로 메시지를 보내는 프로그램을 만들어서 하고 있는 것으로 생각하는 사람들이 있었습니다. (그래서 매일 메시지를 조금씩 내용을 바꿉니다. ^^)
그런데 이런 프로그램을 만들려면 어떻게 할까요. 오늘 보물을 발견했습니다.
혹시 심심이라고 하는 MSNBot을 알고 계시다면,
그리고 예전에 있었던, 자동번역 Bot을 알고 계신다면, 그것을 제로부터 직접 만드는 것은 꽤 까다로운 작업입니다만, 아래의 MSN Package를 사용하면 그렇게 어렵지 않게 구현할 수 있습니다.
#!/usr/bin/perl
use lib qw(./MSN/lib);
use strict;
use MSN;
my $msn = MSN->new(Handle => 'youraccont@hotmail.co.jp',
Password => 'password');
$msn->setHandler(Message => \&handler_message);
$msn->connect();
while(1) {
$msn->do_one_loop
}
sub handler_message {
my ($self, $username, $name, $message, %style ) = @_;
print "Msg recv.\n";
$self->sendMessage("hello!");
}
전에 잠시 서버관리를 위해, 뭔가 Notification해야 할 일이 생긴다면 실시간으로 메시지로 받을 수 있도록 Microsoft Alert Service를 사용할까 한 적이 있었습니다.
이 패키지를 발견한 뒤로는, 필요 없을 것 같습니다. 무얼 만들까요.
Source Repository에 업데이트 되면 메시지를 보내는 어플?
CI build 가 깨지면 메시지를 보내는 어플?
다양한 방법으로 사용할 수 있을 것 같습니다. :)
Thursday, May 21, 2009
[정보공유] 최근, 도코모에서 구글의 Android를 탑재한 폰이 공개됨
최근, 도코모에서 구글의 Android를 탑재한 폰이 공개됨
http://k-tai.impress.co.jp/cda/article/news_toppage/45367.html
Iphone에서는 Flash를 보는 것이 불가능한 반면,
이 Android폰에서는 웹에서 플래쉬보는 것이 가능함.
>woo_김택우 says:
>iphone에서 youtube볼수 있어?? youtube전용 어플리케이션이 있음
>（Dev） Kim tonghyun says:
>아하
>woo_김택우 says:
>현재는iPhone의Safari에서 플래쉬를 지원 안하니까
>woo_김택우 says:
>웹사이트에 들어가서는 못보는 상황이지
>（Dev） Kim tonghyun says:
>나루호도네
Iphone에서는 ObjectC로만 개발가능한 반면
Android폰 에서는 당연히 java나 perl, python등을 지원하므로 다른 언어의 개발자가 접근하기 용이함. ActionScripter도 당연히 자기가 Flash를 만들어 올리는 것이 가능
사업적인 측면으로 개발자로서 볼 때 IPhone의 AppStore보다는 접근하기 더 쉽지 않을까 하는 생각이 듬.
>woo_김택우 says:
>내년까지 스마트폰이 이본에서만 300만데 시장으로 성장 할꺼야
>woo_김택우 says:
>아마 반이상이 안드로이드가 들어가겠지
>（Dev） Kim tonghyun says:
>나루호도-
>woo_김택우 says:
>음 아무레도 자바가 쉽겠지
>woo_김택우 says:
>서비스나 브랜드만 만들면, 개발언어는 선택이지
>woo_김택우 says:
>시장이 있으면 진입하면되고
>woo_김택우 says:
>일본에 전화기가 1억7천만데 사용하고 있는데, 300만이면 아직 멀었지만, 배수로 성장한다고봐
이상. 정보공유 끝.
http://k-tai.impress.co.jp/cda/article/news_toppage/45367.html
Iphone에서는 Flash를 보는 것이 불가능한 반면,
이 Android폰에서는 웹에서 플래쉬보는 것이 가능함.
>woo_김택우 says:
>iphone에서 youtube볼수 있어?? youtube전용 어플리케이션이 있음
>（Dev） Kim tonghyun says:
>아하
>woo_김택우 says:
>현재는iPhone의Safari에서 플래쉬를 지원 안하니까
>woo_김택우 says:
>웹사이트에 들어가서는 못보는 상황이지
>（Dev） Kim tonghyun says:
>나루호도네
Iphone에서는 ObjectC로만 개발가능한 반면
Android폰 에서는 당연히 java나 perl, python등을 지원하므로 다른 언어의 개발자가 접근하기 용이함. ActionScripter도 당연히 자기가 Flash를 만들어 올리는 것이 가능
사업적인 측면으로 개발자로서 볼 때 IPhone의 AppStore보다는 접근하기 더 쉽지 않을까 하는 생각이 듬.
>woo_김택우 says:
>내년까지 스마트폰이 이본에서만 300만데 시장으로 성장 할꺼야
>woo_김택우 says:
>아마 반이상이 안드로이드가 들어가겠지
>（Dev） Kim tonghyun says:
>나루호도-
>woo_김택우 says:
>음 아무레도 자바가 쉽겠지
>woo_김택우 says:
>서비스나 브랜드만 만들면, 개발언어는 선택이지
>woo_김택우 says:
>시장이 있으면 진입하면되고
>woo_김택우 says:
>일본에 전화기가 1억7천만데 사용하고 있는데, 300만이면 아직 멀었지만, 배수로 성장한다고봐
이상. 정보공유 끝.
Monday, May 18, 2009
[정보공유] FireFox의 BookMark 기능을 이용하여 일본어페이지 바로 번역해 보기
원리를 지금까지 설명하지 않았는데
안에 %s 는 파이어폭스가 뒤에 파라메터로 받아서 자동으로 바꾸어서 URL을 Query함
북마크 등록정보
Name : google translate web japanese->korean
Location : http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=%s&sl=ja&tl=ko&history_state0=
keyword : jako
테스트용 페이지 : http://www.wowkorea.jp
어제 와이프가 구약소 유치원 지원금 페이지를 보느라 애쓰는 걸 보고 생각해냄.
일본어 페이지를 보고 주소창에 앞에 'jako '라고 덧붙여 주면 됨.
[추가 정보공유] 다음과 같이 등록하면 중국어 페이지도 금방 번역해 볼 수 있음.
Name : google translate web chinese->korean
Location : http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=%s&sl=zh-CN&tl=ko&history_state0=
keyword : chko
테스트용 페이지 : http://baike.baidu.com/view/29.htm
이상.
안에 %s 는 파이어폭스가 뒤에 파라메터로 받아서 자동으로 바꾸어서 URL을 Query함
북마크 등록정보
Name : google translate web japanese->korean
Location : http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=%s&sl=ja&tl=ko&history_state0=
keyword : jako
테스트용 페이지 : http://www.wowkorea.jp
어제 와이프가 구약소 유치원 지원금 페이지를 보느라 애쓰는 걸 보고 생각해냄.
일본어 페이지를 보고 주소창에 앞에 'jako '라고 덧붙여 주면 됨.
[추가 정보공유] 다음과 같이 등록하면 중국어 페이지도 금방 번역해 볼 수 있음.
Name : google translate web chinese->korean
Location : http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=%s&sl=zh-CN&tl=ko&history_state0=
keyword : chko
테스트용 페이지 : http://baike.baidu.com/view/29.htm
이상.
[정보공유] FireFox의 BookMark 기능을 이용하여 영어사전 바로보기
Name : Google Dictionary : %s in Korean
Location : http://www.google.com/dictionary?aq=f&langpair=ko%7Cen&q=%s&hl=en
Keyword : eng
이후 FireFox의 Address 입력창에 다음과 같이 입력하면 해당 단어가 번역되어 나옴.
eng school
eng 학교
이상.
Location : http://www.google.com/dictionary?aq=f&langpair=ko%7Cen&q=%s&hl=en
Keyword : eng
이후 FireFox의 Address 입력창에 다음과 같이 입력하면 해당 단어가 번역되어 나옴.
eng school
eng 학교
이상.
[정보공유] 파일업로드 하는 폼을 강제로 파일아닌 일반데이타만 전송하게 하고 싶을 때의 enctype 지정
[정보공유] 파일업로드 하는 폼을 강제로 파일아닌 일반데이타만 전송하게 하고 싶을 때의 enctype 지정
다 알고 있겠지만, 찾으려면 또 까먹어서 -_-;
파일업로드하는 form이어서
ENCTYPE = "multipart/form-data" 했는데,
자바스크립트로 일반데이타 전송하도록 하게 할 때.
ENCTYPE = "application/x-www-form-urlencoded"
로 강제 enctype 지정
http://www.htmlcodetutorial.com/forms/_FORM_ENCTYPE.html
이상.
다 알고 있겠지만, 찾으려면 또 까먹어서 -_-;
파일업로드하는 form이어서
ENCTYPE = "multipart/form-data" 했는데,
자바스크립트로 일반데이타 전송하도록 하게 할 때.
ENCTYPE = "application/x-www-form-urlencoded"
로 강제 enctype 지정
http://www.htmlcodetutorial.com/forms/_FORM_ENCTYPE.html
이상.
Sunday, May 17, 2009
[정보공유] FireFox의 BookMark 기능을 이용하여 JDK API 바로보기
FireFox의 BookMark 기능을 이용하여 JDK API 바로보기..
Name : api doc(Java Platform SE 6)
Location : http://www.google.co.kr/search?complete=1&hl=ko&q=site%3Ajava.sun.com%2Fjavase%2F6%2Fdocs%2Fapi+%s&btnI=I%27m+Feeling+Lucky&lr=&aq=f
Keyword : jdk6
이렇게 하고 FireFox의 Address 입력창에
jdk6 Socket
이라고 하면 Socket의 API가 뜸.
원리는
구글의 site: 옵션으로 검색 URL을 제한하고
구글의 I'm Feeling Lucky를 이용해 제일 첫 검색URL을 바로 보게 하는 것
이상.
Name : api doc(Java Platform SE 6)
Location : http://www.google.co.kr/search?complete=1&hl=ko&q=site%3Ajava.sun.com%2Fjavase%2F6%2Fdocs%2Fapi+%s&btnI=I%27m+Feeling+Lucky&lr=&aq=f
Keyword : jdk6
이렇게 하고 FireFox의 Address 입력창에
jdk6 Socket
이라고 하면 Socket의 API가 뜸.
원리는
구글의 site: 옵션으로 검색 URL을 제한하고
구글의 I'm Feeling Lucky를 이용해 제일 첫 검색URL을 바로 보게 하는 것
이상.
Saturday, May 16, 2009
perl로 만드는 win util / wget.pl
■ wget.pl
#!/usr/bin/perl -w
use LWP::Simple;
@ARGV == 2
? (getstore($ARGV[0], $ARGV[1]) || die "Cant Download File: $!\n" )
: print "wget.pl to get html";
print @! unless @!;
사용방법은 다음과 같습니다.
C:\>wget.pl http://www.wowkorea.jp/images/logo_wowkorea.gif wowkorea.gif
■ 그러나 저는 wget.pl을 사용하지 않습니다.
리눅스계열 터미널 작업하다가 갑자기 윈도우즈 콘솔에 서 "ls" 라고 명령을 내린 경험이 있으세요?
닷넷 컴파일러 "csc.exe"가 어디에 있는지, "dir /s"로 찾아본 경험이 있으세요?
저는 리눅스 명령어를 win32로 컴파일한 유틸리티를 설치하여 사용하고 있습니다.
cygwin도 사용한 적이 있으나, 자주 사용하는 명령어만 설치하면 되므로 다음의 페이지에서 자주 사용하는 적당한 유틸리티를 다운받아 사용하고 있습니다.
http://gnuwin32.sourceforge.net/packages.html
저는 수동설치를 하지 않고, 자동설치로, 설치되는 곳은 c:\usr\local 로 해서 사용하고 있습니다.
그리고 Path에 c:\usr\local\bin를 등록해 두면 편리합니다.
그러면
C:\usr\local>ls -la 와 같은 명령을 내릴 수 있습니다.
우선은 CoreUtils 과 which, grep(egrep은 grep -E로 사용합니다.) 정도는 설치해 사용하고 있습니다.
그외에도 win32용 vim (지금은 거의 잘 사용하지 않습니다. emeditor를 사용합니다.), apache, tomcat, perl, python, mysql,등은 이쪽 디렉토리에 설치해 사용하고 있습니다.
더 좋은 방법, 정보공유 하시고 싶은 분은 가벼운 마음으로 코멘트 부탁합니다.
m(__)m
#!/usr/bin/perl -w
use LWP::Simple;
@ARGV == 2
? (getstore($ARGV[0], $ARGV[1]) || die "Cant Download File: $!\n" )
: print "wget.pl
print @! unless @!;
사용방법은 다음과 같습니다.
■ 그러나 저는 wget.pl을 사용하지 않습니다.
리눅스계열 터미널 작업하다가 갑자기 윈도우즈 콘솔에
닷넷 컴파일러 "csc.exe"가 어디에 있는지, "dir /s"로 찾아본 경험이 있으세요?
저는 리눅스 명령어를 win32로 컴파일한 유틸리티를 설치하여 사용하고 있습니다.
cygwin도 사용한 적이 있으나, 자주 사용하는 명령어만 설치하면 되므로 다음의 페이지에서 자주 사용하는 적당한 유틸리티를 다운받아 사용하고 있습니다.
http://gnuwin32.sourceforge.net/packages.html
그리고 Path에 c:\usr\local\bin를 등록해 두면 편리합니다.
그러면
C:\usr\local>ls -la 와 같은 명령을 내릴 수 있습니다.
우선은 CoreUtils 과 which, grep(egrep은 grep -E로 사용합니다.) 정도는 설치해 사용하고 있습니다.
그외에도 win32용 vim (지금은 거의 잘 사용하지 않습니다. emeditor를 사용합니다.), apache, tomcat, perl, python, mysql,등은 이쪽 디렉토리에 설치해 사용하고 있습니다.
더 좋은 방법, 정보공유 하시고 싶은 분은 가벼운 마음으로 코멘트 부탁합니다.
m(__)m
perl로 만드는 win util / gdkdoc.pl
perl에는 perldoc이라고 하는 프로그램을 자체로 가지고 있기 때문에 이를 이용하면 콘솔에서 도움말을 볼 수 있습니다.
이 함수는 어떻게 쓰는 거지, 이 패키지는 어떤 함수를 가지고 있지 할 때, 간단하게 살펴볼 수 있으니 매우 편리합니다.
저는 가끔 groovy를 작성합니다. 특별히 프로젝트로 하는 것도 아니지만, 이 groovy, 뭔가 물건이 될 것 같거든요. 작성할 때는 일반 에디터(emeditor)를 사용합니다. eclipse나, IDEA를 사용해서 작성하려면 너무 무거운 느낌이에요. 웹에서 발견한 어떤 샘플을 돌려보는데, 자바프로젝트를 진행하고 있지도 않으니 eclipse라던 지를 실행시키는 데만도 시간이 걸리죠. 그래서 간단히 작성하는, 늘 띄워져 있는 emeditor로 작성합니다.
도움말은 브라우저를 사용하죠. 그런데 perldoc처럼 콘솔에서 볼 수 있는 도움말이 있으면 좋겠다고 생각해 봤습니다. 그래서 작성해 봤습니다.
아이디어는 한번에 도움말 페이지를 가져오도록 site: 옵션을 주어 google의 검색에서 사이트를 groovy.codehaus.org%2Fgroovy-jdk 로 하고, 아마도(!) 가장 위에 있는 아이템이 api 도움말일 것이라고 생각해 구글의 "I'm feeling lucky"으로 바로 열도록 했습니다.
이때 조금 헤맸는데, 코딩해 실행해보니 403을 리턴한다고 하는 것입니다. telnet으로 get으로 request를 보내면 제대로 302 redirect가 받아지는데 말이죠.
해결한 방법은 UserAgent의 설정이었습니다. 소스를 보시죠.
#!perl
use LWP::UserAgent;
use Win32::Console::ANSI;
use Term::ANSIColor;
my $browser = LWP::UserAgent->new;
$browser->agent( 'Mozilla/4.0 (compatible; MSIE 5.12; Mac_PowerPC)' );
my $URL='http://www.google.co.kr/search?complete=1&hl=ko&q=site%3Agroovy.codehaus.org%2Fgroovy-jdk+' . $ARGV[0] . '&btnI=I%27m+Feeling+Lucky&lr=&aq=f';
my $request = HTTP::Request->new;
my $response = $browser->get($URL);
die "Can't get $url -- ", $response->status_line unless $response->is_success;
my $result = $response->content;
$result =~ s/\<[^\>]*\>//g;
$result =~ s/^\s*$>//g;
$result =~ s/\n\n/\n/gm;
$result =~ s/\n\n/\n/gm;
$result =~ s/\n\n/\n/gm;
$result =~ s/(^\(.*\)$)//g;
foreach $line (split "\n", $result) {
if ($line =~ /\(.*\)/) {
print colored( $line, "bold yellow"), "\n";
}
else {
print $line, "\n";
}
}
__END__
Win32::Console::ANSI 는 default가 아니니 인스톨해줘야해요.
보시면 아시겠지만, 괄호가 들어간 라인은 함수의 설명이라고 생각해 노란색으로 표시하게 했습니다. (너무 길어서 "| more"로 보시면 ANSI color값은 없어져 버립니다.)
약 30줄 정도 되는 지저분한 코드입니다만, 그럭저럭 쓸만할 것 같습니다. 좀 더 뼈와 살을 붙이면, 제대로 된 툴이 될 것 같아요. 예를 들면 parameter가 없으면, 클래스 리스트를 보여준다던 지, 리눅스 환경이면 리눅스용 패키지를 use하게 한다던 지 말이죠.
아마 이런 종류의 여러 아류작을 만들 것 같습니다.
이 함수는 어떻게 쓰는 거지, 이 패키지는 어떤 함수를 가지고 있지 할 때, 간단하게 살펴볼 수 있으니 매우 편리합니다.
저는 가끔 groovy를 작성합니다. 특별히 프로젝트로 하는 것도 아니지만, 이 groovy, 뭔가 물건이 될 것 같거든요. 작성할 때는 일반 에디터(emeditor)를 사용합니다. eclipse나, IDEA를 사용해서 작성하려면 너무 무거운 느낌이에요. 웹에서 발견한 어떤 샘플을 돌려보는데, 자바프로젝트를 진행하고 있지도 않으니 eclipse라던 지를 실행시키는 데만도 시간이 걸리죠. 그래서 간단히 작성하는, 늘 띄워져 있는 emeditor로 작성합니다.
도움말은 브라우저를 사용하죠. 그런데 perldoc처럼 콘솔에서 볼 수 있는 도움말이 있으면 좋겠다고 생각해 봤습니다. 그래서 작성해 봤습니다.
아이디어는 한번에 도움말 페이지를 가져오도록 site: 옵션을 주어 google의 검색에서 사이트를 groovy.codehaus.org%2Fgroovy-jdk 로 하고, 아마도(!) 가장 위에 있는 아이템이 api 도움말일 것이라고 생각해 구글의 "I'm feeling lucky"으로 바로 열도록 했습니다.
이때 조금 헤맸는데, 코딩해 실행해보니 403을 리턴한다고 하는 것입니다. telnet으로 get으로 request를 보내면 제대로 302 redirect가 받아지는데 말이죠.
해결한 방법은 UserAgent의 설정이었습니다. 소스를 보시죠.
#!perl
use LWP::UserAgent;
use Win32::Console::ANSI;
use Term::ANSIColor;
my $browser = LWP::UserAgent->new;
$browser->agent( 'Mozilla/4.0 (compatible; MSIE 5.12; Mac_PowerPC)' );
my $URL='http://www.google.co.kr/search?complete=1&hl=ko&q=site%3Agroovy.codehaus.org%2Fgroovy-jdk+' . $ARGV[0] . '&btnI=I%27m+Feeling+Lucky&lr=&aq=f';
my $request = HTTP::Request->new;
my $response = $browser->get($URL);
die "Can't get $url -- ", $response->status_line unless $response->is_success;
my $result = $response->content;
$result =~ s/\<[^\>]*\>//g;
$result =~ s/^\s*$>//g;
$result =~ s/\n\n/\n/gm;
$result =~ s/\n\n/\n/gm;
$result =~ s/\n\n/\n/gm;
$result =~ s/(^\(.*\)$)//g;
foreach $line (split "\n", $result) {
if ($line =~ /\(.*\)/) {
print colored( $line, "bold yellow"), "\n";
}
else {
print $line, "\n";
}
}
__END__
Win32::Console::ANSI 는 default가 아니니 인스톨해줘야해요.
보시면 아시겠지만, 괄호가 들어간 라인은 함수의 설명이라고 생각해 노란색으로 표시하게 했습니다. (너무 길어서 "| more"로 보시면 ANSI color값은 없어져 버립니다.)
약 30줄 정도 되는 지저분한 코드입니다만, 그럭저럭 쓸만할 것 같습니다. 좀 더 뼈와 살을 붙이면, 제대로 된 툴이 될 것 같아요. 예를 들면 parameter가 없으면, 클래스 리스트를 보여준다던 지, 리눅스 환경이면 리눅스용 패키지를 use하게 한다던 지 말이죠.
아마 이런 종류의 여러 아류작을 만들 것 같습니다.
Friday, May 15, 2009
perl로 만드는 win util / getprint.pl
최근 Perl을 사용한 작업을 다시하면서, 여러가지 유틸리티를 만들면 좋겠다 라는 아이디어가 떠올라 공유할까 합니다.
굉장히 적은 코드로도 꽤 쓸만한 동작을 하는 유틸리티를 작성할 수 있을 것 같기 때문입니다.
■ perl 실행의 기본.
(1) perl 파일의 실행
activeperl이 설치되어 있다면, 커맨드 프롬프트에서 pl 파일 이름만 써도 바로 실행할 수 있습니다.
예를 들어 다음과 같습니다.
C:\>type test.pl
print "hello";
C:\>test.pl
hello
C:\>
(2) 확장명을 쓰지않고 실행하기
그런데 .pl 까지 쓰지 않고 test 만 입력해서 실행하면 안될까요?
환경변수에 그 내용이 적혀 있습니다.
다음 명령중 하나를 커맨드 프롬프트에서 실행해 보면, 바로 실행할 수 있는 확장자를 볼 수 있습니다.
C:\>set | find "PATHEXT"
C:\>set | find /i "pathext"
C:\>set | find /n /i "pathext"
C:\>set | find "PATHEXT"
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.py;.pyw
여기에 다음과 같이 입력하여 확장자가 .pl인 것도 이름만 입력하여도 실행할 수 있게 합니다.
C:\>set PATHEXT=%PATHEXT%;.PL
C:\>test
hello
이때 주의해야할 점은 2가지 인 것 같습니다.
- 실행의 우선순위는 cmd.exe의 내부명령어, 그리고 PATHEXT에 정의된 순서입니다. 만일 dir.pl이 있다면 dir명령은 cmd의 dir명령이 실행됩니다. dir.pl을 실행하려면 확장명까지 다 써줘야 dir.pl이 실행될 것입니다. 또 test.com이 있다면 test.com이 우선권을 가지므로 test.com이 실행될 것입니다.
- 확장명을 떼고 입력해도 실행하게 하는 것은 cmd.exe라는 쉘이 실행할 때 뿐입니다. 만일 totalcmd와 같은 tool에서 바로 test만 실행해서 test.pl을 실행하고 싶다면 그러한 기능을 tool이 지원하지 않는 한, 실행되지 않을 것입니다. (tool이 cmd.exe를 통해서 실행하게 하는 방법은 있습니다.)
(3) 파라메터를 주는 법
기본적인 파라메터를 주는 방법은 다 알고 계실 것입니다. 스페이스로 구분하죠.
그런데 파라메터안에 스페이스를 포함해야하는 경우는 특정 문자로 묶어서 하나의 parameter로 인식하게 해야합니다.
윈도우즈계열에서 이 묶는 문자는 리눅스계열의 것과 약간 다른데,
리눅스계열은 작은따옴표든, 큰따옴표든, 제일 바깥의 것을 pair로 해 parameter로 인식하는 반면,
윈도우계열은 큰 따옴표만을 parameter로 인식합니다.
윈도우즈에서 만일 큰따옴표 안의 parameter안에 큰따옴표를 써야 한다면 역슬래쉬를 붙여 escape화 해주면 됩니다.
이 방법은 리눅스에서도 동일합니다. 즉. 리눅스의 커맨드로 다음과 같은 명령을 본 적이 있다면
perl -MLWP::Simple -e 'getprint "http://www.yaplog.jp"'
윈도우즈에서 실행해보면 다음과 같이 Annoying합니다.
C:\>perl -MLWP::Simple -e 'getprint "http://www.yaplog.jp"'
Can't find string terminator "'" anywhere before EOF at -e line 1.
그래서 윈도우즈에서는 다음과 같이 고쳐서 사용합니다.
C:\>perl -MLWP::Simple -e "getprint \"http://www.yaplog.jp\""
그리고 위 명령은 리눅스계열에서도 잘 동작합니다.
■ getprint.pl
바로 위의 명령을 파일로 해서 간단히 유틸리티를 만들어 두었습니다.
함수명을 파일명과 동일하게 해서 c:\usr\local\bin\getprint.pl 로 저장해 두었습니다.
#!/usr/bin/perl -w
use LWP::Simple;
@ARGV >0 ? getprint $ARGV[0] : print "getprint <url> to get html";
사용방법은 다음과 같습니다.
C:\>getprint http://www.wowkorea.jp
C:\>getprint file:///c:/test.pl
그동안 브라우저를 사용할 수 없는 터미널 환경에서 서버의 작동을 확인할 때
telnet localhost 80
GET / HTTP/1.0<엔터><엔터>
와 같은 방식으로 테스트 했었다면, 이 작은 유틸리티가 쓸모가 있을 것 같습니다.
Tip입니다만, lynx를 사용할 수 있는 환경이면, 다음의 명령도 쓸만합니다.
lynx -dump http://www.wowkorea.jp
lynx -dump -head http://www.wowkorea.jp
■ 혹시 groovy를 사용하세요?
다음 명령을 실행해 보세요
C:\>groovy -e "print \"http://www.wowkorea.jp\".toURL().getText()"
굉장히 적은 코드로도 꽤 쓸만한 동작을 하는 유틸리티를 작성할 수 있을 것 같기 때문입니다.
■ perl 실행의 기본.
(1) perl 파일의 실행
activeperl이 설치되어 있다면, 커맨드 프롬프트에서 pl 파일 이름만 써도 바로 실행할 수 있습니다.
예를 들어 다음과 같습니다.
C:\>type test.pl
print "hello";
C:\>test.pl
hello
C:\>
(2) 확장명을 쓰지않고 실행하기
그런데 .pl 까지 쓰지 않고 test 만 입력해서 실행하면 안될까요?
환경변수에 그 내용이 적혀 있습니다.
다음 명령중 하나를 커맨드 프롬프트에서 실행해 보면, 바로 실행할 수 있는 확장자를 볼 수 있습니다.
C:\>set | find "PATHEXT"
C:\>set | find /i "pathext"
C:\>set | find /n /i "pathext"
C:\>set | find "PATHEXT"
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.py;.pyw
여기에 다음과 같이 입력하여 확장자가 .pl인 것도 이름만 입력하여도 실행할 수 있게 합니다.
C:\>set PATHEXT=%PATHEXT%;.PL
C:\>test
hello
이때 주의해야할 점은 2가지 인 것 같습니다.
- 실행의 우선순위는 cmd.exe의 내부명령어, 그리고 PATHEXT에 정의된 순서입니다. 만일 dir.pl이 있다면 dir명령은 cmd의 dir명령이 실행됩니다. dir.pl을 실행하려면 확장명까지 다 써줘야 dir.pl이 실행될 것입니다. 또 test.com이 있다면 test.com이 우선권을 가지므로 test.com이 실행될 것입니다.
- 확장명을 떼고 입력해도 실행하게 하는 것은 cmd.exe라는 쉘이 실행할 때 뿐입니다. 만일 totalcmd와 같은 tool에서 바로 test만 실행해서 test.pl을 실행하고 싶다면 그러한 기능을 tool이 지원하지 않는 한, 실행되지 않을 것입니다. (tool이 cmd.exe를 통해서 실행하게 하는 방법은 있습니다.)
(3) 파라메터를 주는 법
기본적인 파라메터를 주는 방법은 다 알고 계실 것입니다. 스페이스로 구분하죠.
그런데 파라메터안에 스페이스를 포함해야하는 경우는 특정 문자로 묶어서 하나의 parameter로 인식하게 해야합니다.
윈도우즈계열에서 이 묶는 문자는 리눅스계열의 것과 약간 다른데,
리눅스계열은 작은따옴표든, 큰따옴표든, 제일 바깥의 것을 pair로 해 parameter로 인식하는 반면,
윈도우계열은 큰 따옴표만을 parameter로 인식합니다.
윈도우즈에서 만일 큰따옴표 안의 parameter안에 큰따옴표를 써야 한다면 역슬래쉬를 붙여 escape화 해주면 됩니다.
이 방법은 리눅스에서도 동일합니다. 즉. 리눅스의 커맨드로 다음과 같은 명령을 본 적이 있다면
perl -MLWP::Simple -e 'getprint "http://www.yaplog.jp"'
윈도우즈에서 실행해보면 다음과 같이 Annoying합니다.
C:\>perl -MLWP::Simple -e 'getprint "http://www.yaplog.jp"'
Can't find string terminator "'" anywhere before EOF at -e line 1.
그래서 윈도우즈에서는 다음과 같이 고쳐서 사용합니다.
C:\>perl -MLWP::Simple -e "getprint \"http://www.yaplog.jp\""
그리고 위 명령은 리눅스계열에서도 잘 동작합니다.
■ getprint.pl
바로 위의 명령을 파일로 해서 간단히 유틸리티를 만들어 두었습니다.
함수명을 파일명과 동일하게 해서 c:\usr\local\bin\getprint.pl 로 저장해 두었습니다.
#!/usr/bin/perl -w
use LWP::Simple;
@ARGV >0 ? getprint $ARGV[0] : print "getprint <url> to get html";
사용방법은 다음과 같습니다.
C:\>getprint http://www.wowkorea.jp
C:\>getprint file:///c:/test.pl
그동안 브라우저를 사용할 수 없는 터미널 환경에서 서버의 작동을 확인할 때
telnet localhost 80
GET / HTTP/1.0<엔터><엔터>
와 같은 방식으로 테스트 했었다면, 이 작은 유틸리티가 쓸모가 있을 것 같습니다.
Tip입니다만, lynx를 사용할 수 있는 환경이면, 다음의 명령도 쓸만합니다.
lynx -dump http://www.wowkorea.jp
lynx -dump -head http://www.wowkorea.jp
■ 혹시 groovy를 사용하세요?
다음 명령을 실행해 보세요
C:\>groovy -e "print \"http://www.wowkorea.jp\".toURL().getText()"
Thursday, May 14, 2009
"\u82a0"식의 출력을 perl로 "あ"로 변환하기
저는 메신저로, 제 메신저에 등록된 한국사람들에게 "[정보공유]" 메시지를 가끔 보냅니다.
[정보공유] 타이틀이 붙은 메시지의 내용은 대상자의 professional과 관련된 것입니다.
예를 들면, 기획과 관련된 것은 기획자나, 관련자, 또는 관심을 가지고 있는 사람에게, 개발에 관계된 것이면, 관련 개발자에게 보냅니다.
일과 관련된 것이면, 팀원에게도 [정보공유] 타이틀의 메신저를 보내죠.
전에는 java나 c#으로 작업할 때는 많이 보냈습니다만, 최근에는 리눅스 작업인데, 해당자는 그리 많지 않은 것 같아 제가 보내는 것도 뜸합니다.
단방향 정보송신이기 때문에 특별히 답변을 하지 않아도 괜찮다는 의미로, 이런 종류의 메시지의 끝에는 "이상." 이라고 붙입니다.(간혹 "이상."이라고 붙이는 것을 잊어먹기도 합니다만, 특별히 답변이 안오는 경우가 많고 저도 기대하진 않습니다.)
그러면서 가끔. 저도 이런식의 정보를 받기를 바란다는 메시지를 전달합니다.
예를 들어, java에 관련된 작업을 하는 사람이면, 일하면서 뭔가 새로운 라이브러리를 발견했다던가, 조금 시간이 걸리는 어려운 문제를 만나 이렇게 해결했다던가 하는 내용을 저도 받기를 원합니다.
그런데 아직까지 한번도 받아본 적이 없는 것 같습니다.
제가 모르고 있는 것을 정보공유해준다면 저는 공짜로 하나를 알게 되는 것이니 정말 고마운 일이고,
제가 알고 있는 것이라도 [정보공유]의 메시지를 보내 준다면, 동감하거나, 또는 더 나은 방법을 알고 있다면 제가 comment해 줄 수도 있을 것입니다.
그런데 한번도 받아보지 못하고 있는 건 좀 아쉽습니다.
아주 가끔은 제가 질문을 날립니다. 금방 해결이 안됐다거나, 더 좋은 방법을 알고 있는 사람이 있을까 해서입니다.
그런데 이 경우도 답변이 오지 않습니다.. 너무 난이도가 있는 걸 물어봐서 였을까요..
결국 오늘도 스스로 해결하고 자답을 [정보공유]로 날렸습니다.
오늘 질문했던 내용은 이것입니다.
python의 tool을 사용하는 perl이 있는데, tool의 output중에 파이선의 유니코드 표현방식인 \u82a0 과 같이 표현된 문자열이 있었습니다.
이를 적절히 해당 ShiftJis코드인 "あ"로 치환하고자 하는 것인데, perl에서의 unicode표현방식이 달라 바로 치환할 수는 없고 \x{82}\x{a0}와 같이 바꿔서 치환하는 것이었습니다.
이를 정규표현식으로 "\x82\xa0"치환하는 건 하겠는데, "\x{82}\x{a0}"는 어떻게 "あ"로 치환하지? 하는 문제였습니다.
그리고 자답으로 낸 해결책은 이것이었습니다. 답을 보면 간단합니다.
(1) python의 tool을 사용하는 명령을 내리기 전에 "export LANG=C;"명령을 앞에 써주어 영어로만 출력되게 한다.
우선은 (1)로써 작업을 진행하다가, 돌아오는 전철에서 생각난 것은
(2) eval을 이용한다
였습니다.
그리고 집에와서 테스트 코드를 작성해 보았습니다.
#!perl
$text = '\u82a0aaaあああbbb\u82a2';
$text =~ s/\\u(\w{2})(\w{2})/\\x\{$1\}\\x\{$2\}/g;
eval "\$text = \"$text\"";
print $text, "\n";
__END__
あ unicode 0x3042 shiftjis, cp932 0x82a0
ぃ unicode 0x3043 shiftjis, cp932 0x82a1
い unicode 0x3044 shiftjis, cp932 0x82a2
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
결과는
c:\temp>perl test2.pl
あaaaあああbbbい
eval을 사용하는 것은 대부분의 스크립트 언어에 존재하기 때문에 비슷하게 써먹을 수 있을 것입니다. (groovy에도 eval이 있나??)
이 결과를 질문했던 사람들에게 [정보공유]로 전달해 주었습니다만, 어째 좀 아쉬운 느낌입니다.
메신저에 없는 사람이라도, 가볍게 물어볼 수 있는 곳이 있으면 좋겠습니다.
어째 KDLP등의 유명 개발자 커뮤니티에 올리면 너무 많은 사용자가 보고 많은 댓글이 달리기 때문에 부담스럽운건 저만 그럴까요. ^^;
[정보공유] 타이틀이 붙은 메시지의 내용은 대상자의 professional과 관련된 것입니다.
예를 들면, 기획과 관련된 것은 기획자나, 관련자, 또는 관심을 가지고 있는 사람에게, 개발에 관계된 것이면, 관련 개발자에게 보냅니다.
일과 관련된 것이면, 팀원에게도 [정보공유] 타이틀의 메신저를 보내죠.
전에는 java나 c#으로 작업할 때는 많이 보냈습니다만, 최근에는 리눅스 작업인데, 해당자는 그리 많지 않은 것 같아 제가 보내는 것도 뜸합니다.
단방향 정보송신이기 때문에 특별히 답변을 하지 않아도 괜찮다는 의미로, 이런 종류의 메시지의 끝에는 "이상." 이라고 붙입니다.(간혹 "이상."이라고 붙이는 것을 잊어먹기도 합니다만, 특별히 답변이 안오는 경우가 많고 저도 기대하진 않습니다.)
그러면서 가끔. 저도 이런식의 정보를 받기를 바란다는 메시지를 전달합니다.
예를 들어, java에 관련된 작업을 하는 사람이면, 일하면서 뭔가 새로운 라이브러리를 발견했다던가, 조금 시간이 걸리는 어려운 문제를 만나 이렇게 해결했다던가 하는 내용을 저도 받기를 원합니다.
그런데 아직까지 한번도 받아본 적이 없는 것 같습니다.
제가 모르고 있는 것을 정보공유해준다면 저는 공짜로 하나를 알게 되는 것이니 정말 고마운 일이고,
제가 알고 있는 것이라도 [정보공유]의 메시지를 보내 준다면, 동감하거나, 또는 더 나은 방법을 알고 있다면 제가 comment해 줄 수도 있을 것입니다.
그런데 한번도 받아보지 못하고 있는 건 좀 아쉽습니다.
아주 가끔은 제가 질문을 날립니다. 금방 해결이 안됐다거나, 더 좋은 방법을 알고 있는 사람이 있을까 해서입니다.
그런데 이 경우도 답변이 오지 않습니다.. 너무 난이도가 있는 걸 물어봐서 였을까요..
결국 오늘도 스스로 해결하고 자답을 [정보공유]로 날렸습니다.
오늘 질문했던 내용은 이것입니다.
python의 tool을 사용하는 perl이 있는데, tool의 output중에 파이선의 유니코드 표현방식인 \u82a0 과 같이 표현된 문자열이 있었습니다.
이를 적절히 해당 ShiftJis코드인 "あ"로 치환하고자 하는 것인데, perl에서의 unicode표현방식이 달라 바로 치환할 수는 없고 \x{82}\x{a0}와 같이 바꿔서 치환하는 것이었습니다.
이를 정규표현식으로 "\x82\xa0"치환하는 건 하겠는데, "\x{82}\x{a0}"는 어떻게 "あ"로 치환하지? 하는 문제였습니다.
그리고 자답으로 낸 해결책은 이것이었습니다. 답을 보면 간단합니다.
(1) python의 tool을 사용하는 명령을 내리기 전에 "export LANG=C;"명령을 앞에 써주어 영어로만 출력되게 한다.
우선은 (1)로써 작업을 진행하다가, 돌아오는 전철에서 생각난 것은
(2) eval을 이용한다
였습니다.
그리고 집에와서 테스트 코드를 작성해 보았습니다.
#!perl
$text = '\u82a0aaaあああbbb\u82a2';
$text =~ s/\\u(\w{2})(\w{2})/\\x\{$1\}\\x\{$2\}/g;
eval "\$text = \"$text\"";
print $text, "\n";
__END__
あ unicode 0x3042 shiftjis, cp932 0x82a0
ぃ unicode 0x3043 shiftjis, cp932 0x82a1
い unicode 0x3044 shiftjis, cp932 0x82a2
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
결과는
c:\temp>perl test2.pl
あaaaあああbbbい
eval을 사용하는 것은 대부분의 스크립트 언어에 존재하기 때문에 비슷하게 써먹을 수 있을 것입니다. (groovy에도 eval이 있나??)
이 결과를 질문했던 사람들에게 [정보공유]로 전달해 주었습니다만, 어째 좀 아쉬운 느낌입니다.
메신저에 없는 사람이라도, 가볍게 물어볼 수 있는 곳이 있으면 좋겠습니다.
어째 KDLP등의 유명 개발자 커뮤니티에 올리면 너무 많은 사용자가 보고 많은 댓글이 달리기 때문에 부담스럽운건 저만 그럴까요. ^^;
Wednesday, May 13, 2009
미야시타상의 Punc
최근 Func(https://fedorahosted.org/func/)로 작업을 하고 있는데,
이와 비슷한 Punc(http://coderepos.org/share/wiki/Punc)라는 프로젝트가 있습니다..
coderepos에 올라간지 14개월 밖에 안되는 프로젝트인데, 이 저자는 우리 그룹의 회사중의 하나인 Paper & boys co.에 근무하는 미야시타 고-스케라는 분이 진행하고 있습니다..
분명히 Paper & boys co.에도 호스팅사업을 하고 있고 꽤 실적을 내고 있기 때문에 비슷한 내용의 작업을 많이 할 것이라고는 생각했지만, 이런 정도의 활약을 하고 있는 사람이 있다고는 생각하지 못했네요.
아직 Punc는 프로토타입인데, 호스팅업계에서 Killer App로 성장하게 될 지도 모르겠습니다.
미야시타상의 블로그를 잠깐 보았는데, 재미있는 코드들이 있습니다.
예를 들면, 믹시에 post하는 perl코드.. 마지막 update가 3년전이네요.
http://trac.mizzy.org/public/browser/mixi/trunk/post_blog_to_mixi.pl
그동안 블로그에 기술적인 강좌식의 글을 적는 것을 쓸데없이 정보를 재생산하는 것 같아 좋아하지 않았는데 블로그를 Trac으로 쓰고 있는 것은. 자기가 진행하고 있는 프로젝트를 함께 보게하는 것으로 좋은 방법인 것 같다고 생각이 듭니다.
그런데 조-금. 느린 것 같은 느낌은 있습니다.
이와 비슷한 Punc(http://coderepos.org/share/wiki/Punc)라는 프로젝트가 있습니다..
coderepos에 올라간지 14개월 밖에 안되는 프로젝트인데, 이 저자는 우리 그룹의 회사중의 하나인 Paper & boys co.에 근무하는 미야시타 고-스케라는 분이 진행하고 있습니다..
분명히 Paper & boys co.에도 호스팅사업을 하고 있고 꽤 실적을 내고 있기 때문에 비슷한 내용의 작업을 많이 할 것이라고는 생각했지만, 이런 정도의 활약을 하고 있는 사람이 있다고는 생각하지 못했네요.
아직 Punc는 프로토타입인데, 호스팅업계에서 Killer App로 성장하게 될 지도 모르겠습니다.
미야시타상의 블로그를 잠깐 보았는데, 재미있는 코드들이 있습니다.
예를 들면, 믹시에 post하는 perl코드.. 마지막 update가 3년전이네요.
http://trac.mizzy.org/public/browser/mixi/trunk/post_blog_to_mixi.pl
그동안 블로그에 기술적인 강좌식의 글을 적는 것을 쓸데없이 정보를 재생산하는 것 같아 좋아하지 않았는데 블로그를 Trac으로 쓰고 있는 것은. 자기가 진행하고 있는 프로젝트를 함께 보게하는 것으로 좋은 방법인 것 같다고 생각이 듭니다.
그런데 조-금. 느린 것 같은 느낌은 있습니다.
Friday, May 8, 2009
잠을 못이루고 일어나, 컴퓨터를 켜고
잠을 청하려고 누웠다가 잠을 못이루고, 일어났습니다.
할 일이 없어서 컴퓨터를 켜고, 회사의 컴퓨터와 Synchronize한 뒤, 로컬에 개발환경을 만듭니다.
예전에는 한참 코딩을 하고 돌아가겠지 하고 돌려보면 한번에는 안돌아가지만, 몇번 수정을 가하고 돌아가게끔 한뒤에 코딩을 계속 진행했지만,
요즘은 test를 만들지 않으면 프로젝트가 진행이 안됩니다.(테스트가 몸에 배어서.. 라고 말하고 싶지만, 전체를 쫙 풀어놓고 갈만큼 충분히 이해를 하고 있지 못하거나, 머리가 나빠져서인 것 같습니다.)
노래는 주현미 재생목록을 youtube로 자동재생하게 해놓았습니다.(가끔 현숙님 노래도 나오네요)
오늘은 토비님이 쓰신 ROO의 소개로 잠 못주무시는 분들이 많은 것 같습니다.
여러분의 블로그가 새벽에 post되고 있습니다.
나도 해보려고 맘먹고 있었지만, 우선 회사일로 나중으로 미룹니다.
꽤 cron으로 자주 실행될 스크립트를 Perl로 작성하고 있습니다.
perl이 빠르다고는 하지만, 매번 컴파일되어 실행해야하므로 속도를 고려해서 작게 만들어야 합니다. 이부분에서는 java가 그렇게 light-weight하다며 자랑하는 것이 이해가 갑니다. daemon타입으로 작성하면 빠르겠지요. 하지만 이 프로젝트는 Maintenance는 system admin이 하므로 perl + python으로 작성해 주어야 합니다.
로컬에 BerkeleyDB를 install했습니다. 혼방이야 페도라지만, 로컬에서의 개발은 activePerl을 사용하니 ppm으로 인스톨한 perl의 BerkeleyDB package 3.3이 최신인 BerkeleyDB 4.7을 사용못하더군요. Uninstall하고 4.5로 다시 설치했습니다.
처음에 설계가 Domain Model, BL, DAO로 머리가 돌아가는 것이, perl을 이렇게 짜면 혼날 것 같아서 Facade로 Model + Manager 정도로 고쳐 디자인했습니다. 이마저도 월요일 Review에서 빵꾸 먹을지 몰라요. 가급적이면 Class로 하지 말아달라고 했거든요. 이정도는 통용되겠지 하고 진행하고 있습니다만, 월요일 봐야 알 것 같습니다.
오늘 회사에서 속상했거든요. 1분기 평가 결과가 오늘 나왔습니다.
java하다가(그것도 struts Action에서 query만들어 날리는 스파게티프로젝트에 참여), VB.Net하다가(그것도 try catch안쓰고 모든 method는 성공여부를 리턴하는 비쥬얼베이직식으로 된, Page초기화 할 때, DB에쿼리 날리는 식으로된 프로젝트에 참여), Perl과 Python할 줄 아는 사람이 없어, 다시 운영부 지원으로 나가게 되어... 전문성을 키우지 못하고, 평가도 만족스럽지 못한 상태여서 입니다. 이번 분기뿐 아니라 여러번 겪었습니다.
nmake test해가며 작업해가고 있는데, 이제는 어느 개발이든 콘솔은 필수로 사용하게 된 것 같습니다. 운영부 애들이 하던 말이 떠오르네요 "got a big raise!".
새벽에 컴퓨터켜고 운영부 지원프로젝트 로컬에 세팅하는 제가 밉습니다. 영어공부나 할것이지..(사실 자려들기전에 좀 했습니다만..)
이런거 블로그에 쓰면 안되는데- 하면서도 적는 건,
이야기할 사람이 적은 일본회사안에서의 한국인이어서라고 너그러이 양해부탁드립니다.
할 일이 없어서 컴퓨터를 켜고, 회사의 컴퓨터와 Synchronize한 뒤, 로컬에 개발환경을 만듭니다.
예전에는 한참 코딩을 하고 돌아가겠지 하고 돌려보면 한번에는 안돌아가지만, 몇번 수정을 가하고 돌아가게끔 한뒤에 코딩을 계속 진행했지만,
요즘은 test를 만들지 않으면 프로젝트가 진행이 안됩니다.(테스트가 몸에 배어서.. 라고 말하고 싶지만, 전체를 쫙 풀어놓고 갈만큼 충분히 이해를 하고 있지 못하거나, 머리가 나빠져서인 것 같습니다.)
노래는 주현미 재생목록을 youtube로 자동재생하게 해놓았습니다.(가끔 현숙님 노래도 나오네요)
오늘은 토비님이 쓰신 ROO의 소개로 잠 못주무시는 분들이 많은 것 같습니다.
여러분의 블로그가 새벽에 post되고 있습니다.
나도 해보려고 맘먹고 있었지만, 우선 회사일로 나중으로 미룹니다.
꽤 cron으로 자주 실행될 스크립트를 Perl로 작성하고 있습니다.
perl이 빠르다고는 하지만, 매번 컴파일되어 실행해야하므로 속도를 고려해서 작게 만들어야 합니다. 이부분에서는 java가 그렇게 light-weight하다며 자랑하는 것이 이해가 갑니다. daemon타입으로 작성하면 빠르겠지요. 하지만 이 프로젝트는 Maintenance는 system admin이 하므로 perl + python으로 작성해 주어야 합니다.
로컬에 BerkeleyDB를 install했습니다. 혼방이야 페도라지만, 로컬에서의 개발은 activePerl을 사용하니 ppm으로 인스톨한 perl의 BerkeleyDB package 3.3이 최신인 BerkeleyDB 4.7을 사용못하더군요. Uninstall하고 4.5로 다시 설치했습니다.
처음에 설계가 Domain Model, BL, DAO로 머리가 돌아가는 것이, perl을 이렇게 짜면 혼날 것 같아서 Facade로 Model + Manager 정도로 고쳐 디자인했습니다. 이마저도 월요일 Review에서 빵꾸 먹을지 몰라요. 가급적이면 Class로 하지 말아달라고 했거든요. 이정도는 통용되겠지 하고 진행하고 있습니다만, 월요일 봐야 알 것 같습니다.
오늘 회사에서 속상했거든요. 1분기 평가 결과가 오늘 나왔습니다.
java하다가(그것도 struts Action에서 query만들어 날리는 스파게티프로젝트에 참여), VB.Net하다가(그것도 try catch안쓰고 모든 method는 성공여부를 리턴하는 비쥬얼베이직식으로 된, Page초기화 할 때, DB에쿼리 날리는 식으로된 프로젝트에 참여), Perl과 Python할 줄 아는 사람이 없어, 다시 운영부 지원으로 나가게 되어... 전문성을 키우지 못하고, 평가도 만족스럽지 못한 상태여서 입니다. 이번 분기뿐 아니라 여러번 겪었습니다.
nmake test해가며 작업해가고 있는데, 이제는 어느 개발이든 콘솔은 필수로 사용하게 된 것 같습니다. 운영부 애들이 하던 말이 떠오르네요 "got a big raise!".
새벽에 컴퓨터켜고 운영부 지원프로젝트 로컬에 세팅하는 제가 밉습니다. 영어공부나 할것이지..(사실 자려들기전에 좀 했습니다만..)
이런거 블로그에 쓰면 안되는데- 하면서도 적는 건,
이야기할 사람이 적은 일본회사안에서의 한국인이어서라고 너그러이 양해부탁드립니다.
Sunday, May 3, 2009
어떤 언어를 선택할 것인가에서 어떤 솔루션을 선택할 것인가
최근 일련의 경험으로 프로그래밍 언어에 대해 여러가지를 생각하게 됩니다.
회사에서 Perl작업을 하면서 있었던 일입니다만, 시스템본부 운영부의 admin들은 perl에서 class를 사용하는 것은 아무래도 느리기 때문에 하지 말아주길 바라더군요. fast-cgi나 mod_perl이라던지 compile해둔 코드를 관리해 실행하게 하는 방식은, 만일 하나의 스크립트가 잘못되어 halt되면 전체를 망가트릴 수 있고, 만일 CGI방식으로 작동하는 스크립트면, halt되었을 때, 해당 프로세스만 kill하면 되기 때문에 CGI방식으로 작업을 하길 원했습니다. 그렇기 때문에 더더욱 객체로 감싸서 작업하는 것은 곤란하겠지요.
최근 Scala이라고 하는 언어를 알게 되었습니다. Martin Ordersky이 만든 자바 컴파일러입니다.
Perl6 VM과 마찬가지로 Static Typing을 지원하고 groovy와 마찬가지로 java의 객체들을 불러 쓸 수 있고, perl과 비슷한 절차적 언어와 비슷한 문법을 가지고 있습니다. javac을 사용하지 않고 자체 컴파일러를 가지고 있습니다. groovy처럼 자바의 Scripting Engine의 Implementation이 아니라, 독자적인 컴파일러로 자바 IL로 컴파일합니다. 장점과 단점 모두 가질 수 있겠네요.
플러스, 닷넷의 CRL도 지원한다고 합니다만, 이에 대한 언급은 매우 작았습니다.
이미 여러 IDE의 플러그인이 개발되어 나와 있더군요. Twitter의 Message Queue는 Scala로 개발되었다고 합니다.
이번의 프로젝트에는 Python으로 해야하는 개발도 있습니다.
Python도 공부해보면 훌륭한 언어입니다. 특히 시스템관리 스크립트로는 제격인 것 같습니다. 기능과 performance간의 trade off을 잘 조정한 것 같은 느낌입니다. Tab으로 syntax를 조절하는 방식때문에 혐오하는 사람들도 꽤 있더군요. vim을 사용한다면 그럴 것 같다는 생각도 듭니다.
최근에는 여러가지 복잡한(?) 라이브러리를 사용한 j2ee솔루션과 php와의 비교도 있었습니다.
보통은, 어떤 솔루션을 구현하는데는 여러가지 언어로도 가능하며(오히려 가능하지 않은 언어를 찾기 어려운 경우가 많으며), 선택한 언어가운데에서도 많은 Variation으로 구현할 수 있습니다.
그런데 보통 하나의 개발팀은 하나의 언어만 사용하는 경우가 많은 것 같습니다. 그도 그럴 것이, 한가지 언어에 -어느 정도- 능통해지기 까지도 굉장히 많은 시간과 경험을 필요로 합니다.(정말 그럴까요? 나는 몇몇 사람들로 부터 반드시 그렇지 않다는 것을 경험합니다. 우선은 그렇다고 해두죠.) 프로젝트를 진행하면서 얻은 노하우와 스킬은 그 다음 프로젝트에서 오류가 적고 좋은 품질의 솔루션을 만들기 위해 언어를 선택할 때, 매우 큰 Advantage입니다. 반면 새로운 언어를 선택하는 것은 조직에게 있어서 엄청난 Pain일 수 있습니다. 새로운 프로젝트에서도 같은 언어를 선택하는 것은 조직으로서는 타당한 결정일 경우가 많습니다.
하지만 시스템(솔루션)으로서 생각해보면, 각각의 언어는 다른 언어와 구별되는 특징을 가지고 있으며, 이는 어떤 솔루션에 있어서는 큰 advantage 인 경우가 있습니다.
예를 들면, 어떤 CI tool을 선택할까하고 살펴본 CI tool Matrix에는 java나 c#의 implementation이 압도적으로 많습니다. 이는 어떤 종류의 소프트웨어에는 어떤 특성을 가지는 언어가 적합하다고 생각하는 경우가 많다는 것이겠지요.
아직 나로서는 결정을 내리기 어렵습니다. 어쩌면 이 글도 뭔가 일련의 생각들을 정리하기 위해 적는 것일지도 모릅니다. (날을 새서 두서없이 적는 것인지도 모르겠습니다. Issue가 무엇인지 제대로 얘기하는 것 같지 않습니다.)
그러나 인터넷에는 어떤 언어를 정해놓고 많은 솔루션의 토의가 있는 것처럼,
언어를 정해놓지 않고(또는 터놓고) 솔루션에 대한 토의도 많이 있어야 할 것 같습니다.
회사에서 Perl작업을 하면서 있었던 일입니다만, 시스템본부 운영부의 admin들은 perl에서 class를 사용하는 것은 아무래도 느리기 때문에 하지 말아주길 바라더군요. fast-cgi나 mod_perl이라던지 compile해둔 코드를 관리해 실행하게 하는 방식은, 만일 하나의 스크립트가 잘못되어 halt되면 전체를 망가트릴 수 있고, 만일 CGI방식으로 작동하는 스크립트면, halt되었을 때, 해당 프로세스만 kill하면 되기 때문에 CGI방식으로 작업을 하길 원했습니다. 그렇기 때문에 더더욱 객체로 감싸서 작업하는 것은 곤란하겠지요.
최근 Scala이라고 하는 언어를 알게 되었습니다. Martin Ordersky이 만든 자바 컴파일러입니다.
Perl6 VM과 마찬가지로 Static Typing을 지원하고 groovy와 마찬가지로 java의 객체들을 불러 쓸 수 있고, perl과 비슷한 절차적 언어와 비슷한 문법을 가지고 있습니다. javac을 사용하지 않고 자체 컴파일러를 가지고 있습니다. groovy처럼 자바의 Scripting Engine의 Implementation이 아니라, 독자적인 컴파일러로 자바 IL로 컴파일합니다. 장점과 단점 모두 가질 수 있겠네요.
플러스, 닷넷의 CRL도 지원한다고 합니다만, 이에 대한 언급은 매우 작았습니다.
이미 여러 IDE의 플러그인이 개발되어 나와 있더군요. Twitter의 Message Queue는 Scala로 개발되었다고 합니다.
이번의 프로젝트에는 Python으로 해야하는 개발도 있습니다.
Python도 공부해보면 훌륭한 언어입니다. 특히 시스템관리 스크립트로는 제격인 것 같습니다. 기능과 performance간의 trade off을 잘 조정한 것 같은 느낌입니다. Tab으로 syntax를 조절하는 방식때문에 혐오하는 사람들도 꽤 있더군요. vim을 사용한다면 그럴 것 같다는 생각도 듭니다.
최근에는 여러가지 복잡한(?) 라이브러리를 사용한 j2ee솔루션과 php와의 비교도 있었습니다.
보통은, 어떤 솔루션을 구현하는데는 여러가지 언어로도 가능하며(오히려 가능하지 않은 언어를 찾기 어려운 경우가 많으며), 선택한 언어가운데에서도 많은 Variation으로 구현할 수 있습니다.
그런데 보통 하나의 개발팀은 하나의 언어만 사용하는 경우가 많은 것 같습니다. 그도 그럴 것이, 한가지 언어에 -어느 정도- 능통해지기 까지도 굉장히 많은 시간과 경험을 필요로 합니다.(정말 그럴까요? 나는 몇몇 사람들로 부터 반드시 그렇지 않다는 것을 경험합니다. 우선은 그렇다고 해두죠.) 프로젝트를 진행하면서 얻은 노하우와 스킬은 그 다음 프로젝트에서 오류가 적고 좋은 품질의 솔루션을 만들기 위해 언어를 선택할 때, 매우 큰 Advantage입니다. 반면 새로운 언어를 선택하는 것은 조직에게 있어서 엄청난 Pain일 수 있습니다. 새로운 프로젝트에서도 같은 언어를 선택하는 것은 조직으로서는 타당한 결정일 경우가 많습니다.
하지만 시스템(솔루션)으로서 생각해보면, 각각의 언어는 다른 언어와 구별되는 특징을 가지고 있으며, 이는 어떤 솔루션에 있어서는 큰 advantage 인 경우가 있습니다.
예를 들면, 어떤 CI tool을 선택할까하고 살펴본 CI tool Matrix에는 java나 c#의 implementation이 압도적으로 많습니다. 이는 어떤 종류의 소프트웨어에는 어떤 특성을 가지는 언어가 적합하다고 생각하는 경우가 많다는 것이겠지요.
아직 나로서는 결정을 내리기 어렵습니다. 어쩌면 이 글도 뭔가 일련의 생각들을 정리하기 위해 적는 것일지도 모릅니다. (날을 새서 두서없이 적는 것인지도 모르겠습니다. Issue가 무엇인지 제대로 얘기하는 것 같지 않습니다.)
그러나 인터넷에는 어떤 언어를 정해놓고 많은 솔루션의 토의가 있는 것처럼,
언어를 정해놓지 않고(또는 터놓고) 솔루션에 대한 토의도 많이 있어야 할 것 같습니다.
Thursday, April 30, 2009
php와 jstl/sql은, 개발에 걸리는 시간이 비슷할 것 같다고 생각합니다.
작년에 아르바이트로 제작했던 프로젝트중에 Spring Context, Spring MVC, Hibernate Template with Transaction AOP, Sitemesh, Acegi, Eh cache를 사용해 DAO, BL로 잘 나눠 제작한 어플리케이션이 있습니다.
이 프로젝트는 1차와 2차로 나뉘어 진행되는데, 1차에서는 그렇게 많은 기능이 실장되지는 않아서, 설계에 치중해. 아주 딱 공부하기 좋은 샘플과 같은 모습을 하고 있습니다.
그런데 이 프로젝트의 2차를 제가 진행하지 않고, 어쩌면 다른 사람에게 갈 것 같습니다.
개발 담당으로 확정은 아닙니다만, 문서를 그리 잘 준비해두지 못해(사실은 config파일이 개발문서를 대신할 수 있다고 생각했습니다.) DB의 연결계정, 소스등을 주고(그는 Sun에서 주는 자격증을 가지고 있습니다.) 어떤 구성인지 살펴봐 달라고 얘기했습니다.
그리고 그 뒤, 2차 예정 개발자로 부터 이런 얘기를 들었습니다.
"거짓말아니고....PHP로 만들면 4일이면 똑같이 만들어놓을 자신있음"
-_ㅜ;
그런데 Symfony나 Smarty등의 잘 알려진 PHP용 프레임웍을 사용하는 것은 아니고 그냥 DB에서 읽어오는 방식을 사용하겠다는 군요.
그렇다면.
단순히 Resultset에서 Iteration하는 방식이라면, JSTL / SQL action을 고려해보라고 했습니다.
아마 개발에 걸리는 시간은 비슷하지 않을까라고 생각합니다. Pagenation등의 재활용 가능한 utility용 custom tag등을 만드는 데 걸리는 시간은, PHP에서도 필요한 function을 만드는 것과 비슷할테고. 오히려 performance라면 php의 컴파일 캐쉬등을 사용하지 않는다면, 컴파일된 class를 사용하는 java쪽이 더 좋은 performance를 내겠지요.
사실 2차 예정 개발자는 친동생이어서,
나름 공부하기에 딱 좋은 자료이니, 보고 익혔으면 했는데,
왠지 가슴이 아팠습니다.
이 프로젝트는 1차와 2차로 나뉘어 진행되는데, 1차에서는 그렇게 많은 기능이 실장되지는 않아서, 설계에 치중해. 아주 딱 공부하기 좋은 샘플과 같은 모습을 하고 있습니다.
그런데 이 프로젝트의 2차를 제가 진행하지 않고, 어쩌면 다른 사람에게 갈 것 같습니다.
개발 담당으로 확정은 아닙니다만, 문서를 그리 잘 준비해두지 못해(사실은 config파일이 개발문서를 대신할 수 있다고 생각했습니다.) DB의 연결계정, 소스등을 주고(그는 Sun에서 주는 자격증을 가지고 있습니다.) 어떤 구성인지 살펴봐 달라고 얘기했습니다.
그리고 그 뒤, 2차 예정 개발자로 부터 이런 얘기를 들었습니다.
"거짓말아니고....PHP로 만들면 4일이면 똑같이 만들어놓을 자신있음"
-_ㅜ;
그런데 Symfony나 Smarty등의 잘 알려진 PHP용 프레임웍을 사용하는 것은 아니고 그냥 DB에서 읽어오는 방식을 사용하겠다는 군요.
그렇다면.
단순히 Resultset에서 Iteration하는 방식이라면, JSTL / SQL action을 고려해보라고 했습니다.
아마 개발에 걸리는 시간은 비슷하지 않을까라고 생각합니다. Pagenation등의 재활용 가능한 utility용 custom tag등을 만드는 데 걸리는 시간은, PHP에서도 필요한 function을 만드는 것과 비슷할테고. 오히려 performance라면 php의 컴파일 캐쉬등을 사용하지 않는다면, 컴파일된 class를 사용하는 java쪽이 더 좋은 performance를 내겠지요.
사실 2차 예정 개발자는 친동생이어서,
나름 공부하기에 딱 좋은 자료이니, 보고 익혔으면 했는데,
왠지 가슴이 아팠습니다.
Subscribe to:
Posts (Atom)