[정보공유]
리눅스 터미널 로그인시 1-2분 걸리는 현상이 발생하고 있다면?
이전에도 몇 번 경험한 내용이었는데 해결방법을 몰랐다가 이번에 알게 되었음.
sshd에서 정방/역방 IP조회를 하고 있기 때문에 DNS 타임아웃이 발생하는 시간까지 걸리는 것일 듯.
DNS에 정방/역방 등록을 하지 않고서 해결하는 방법으로는.
(A) 우선 sshd설정(/etc/ssh/sshd_config)에서 useDNS를 no로 하는 방법과.
(B) 접속하는 곳이 고정이라면 서버측 /etc/hosts에 이름을 등록하는 방법.
이상 정보공유.
Wednesday, September 30, 2009
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개월 전부터 테스트팀을 조직해 진행한 결과입니다. 그 전까지는 개발부, 기술부, 자체 테스트였습니다. (이정도는 올려도 괜찮겠지....)
Subscribe to:
Posts (Atom)