저는 메신저로, 제 메신저에 등록된 한국사람들에게 "[정보공유]" 메시지를 가끔 보냅니다.
[정보공유] 타이틀이 붙은 메시지의 내용은 대상자의 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등의 유명 개발자 커뮤니티에 올리면 너무 많은 사용자가 보고 많은 댓글이 달리기 때문에 부담스럽운건 저만 그럴까요. ^^;
Thursday, May 14, 2009
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차 예정 개발자는 친동생이어서,
나름 공부하기에 딱 좋은 자료이니, 보고 익혔으면 했는데,
왠지 가슴이 아팠습니다.
Tuesday, April 28, 2009
웹 개발 팁 -브라우저 측에서 무얼 보내는지 로그를 보고 싶을 때
어제, 동료 한국인 개발자로부터, submit이 두 번일어나는 데, 어디서 그런 문제가 생기는 지 모르겠다고 하는 Help가 있었습니다.
"type=submit인 것에 onClick으로 javascript 걸어놓고, 다시 자바스크립트가 submit하게 되어 있는거 아냐??"
실제로 저런 경우라면 submit이 두 번 발생합니다.
그런데 테스트용으로 보내준 URL에는 그런 내용은 아니었습니다. 거기에다가 IE일 때는 괜찮은데, FireFox인 경우에만 발생한다고 합니다.(서버쪽의 로그까지 보내주어 두 번 기록되어 있는 것은 확인했습니다.)
FF를 보고 있을 때는 Refresh할 때의 Flash등도 없어, 한 번 submit하는 느낌이었습니다만, 이것 만으로 한 번 보내는 지 어떤 지 알 수 없었습니다.
이런 종류의 디버깅에 시간을 많이 뺏기는 것은 정말 속상합니다.
FireFox의 FireBug로 어떤 전송이 일어나는 지 보려고 시도했었습니다만, Net 탭에 있는 전송 히스토리는, 브라우저가 document를 다시 읽을 때 초기화되어버려, 이 경우에는 도움이 되지 못했습니다.
어쩌면 서버측에서 Redirection하고 있는 지 모르겠습니다만, 우선 클라이언트 측의 코드에서 문제가 없는 지 확인하고 넘어가야겠지요.
이런 경우 저는 지금까지 마이크로소프트의 네트웍 모니터를 사용했습니다. 패킷을 캡춰해서 볼 수 있는 유틸리티입니다. 다운로드는 여기
사용방법은 꽤 간단하므로, googling하면 자세히 소개하는 곳이 있을 터입니다.
그런데, 이런 경우라면, 브라우저측에서 전송하는 로그를 기록하는 것이 있다면 해결 할 수 있기 때문에, 파이어 폭스의 플러그인에 무언가 있지 않을까 하는 생각이 들어 검색을 해보고, Tamper Data라고 하는 것을 찾아 실행해봤습니다.
gmail이나, naver를 tamper data로 보고 있으면, 굉장히 열심히 백그라운드로 보내고 받고 하는 것을 볼 수 있습니다. 이정도면 도움이 될 것 같습니다. 오늘은 휴일이기 때문에 내일 회사에 가면 알려주어야겠네요.
외국에서 고생하는 한국인 엔지니어들, 모두 모두 감바레!
"type=submit인 것에 onClick으로 javascript 걸어놓고, 다시 자바스크립트가 submit하게 되어 있는거 아냐??"
실제로 저런 경우라면 submit이 두 번 발생합니다.
그런데 테스트용으로 보내준 URL에는 그런 내용은 아니었습니다. 거기에다가 IE일 때는 괜찮은데, FireFox인 경우에만 발생한다고 합니다.(서버쪽의 로그까지 보내주어 두 번 기록되어 있는 것은 확인했습니다.)
FF를 보고 있을 때는 Refresh할 때의 Flash등도 없어, 한 번 submit하는 느낌이었습니다만, 이것 만으로 한 번 보내는 지 어떤 지 알 수 없었습니다.
이런 종류의 디버깅에 시간을 많이 뺏기는 것은 정말 속상합니다.
FireFox의 FireBug로 어떤 전송이 일어나는 지 보려고 시도했었습니다만, Net 탭에 있는 전송 히스토리는, 브라우저가 document를 다시 읽을 때 초기화되어버려, 이 경우에는 도움이 되지 못했습니다.
어쩌면 서버측에서 Redirection하고 있는 지 모르겠습니다만, 우선 클라이언트 측의 코드에서 문제가 없는 지 확인하고 넘어가야겠지요.
이런 경우 저는 지금까지 마이크로소프트의 네트웍 모니터를 사용했습니다. 패킷을 캡춰해서 볼 수 있는 유틸리티입니다. 다운로드는 여기
사용방법은 꽤 간단하므로, googling하면 자세히 소개하는 곳이 있을 터입니다.
그런데, 이런 경우라면, 브라우저측에서 전송하는 로그를 기록하는 것이 있다면 해결 할 수 있기 때문에, 파이어 폭스의 플러그인에 무언가 있지 않을까 하는 생각이 들어 검색을 해보고, Tamper Data라고 하는 것을 찾아 실행해봤습니다.
gmail이나, naver를 tamper data로 보고 있으면, 굉장히 열심히 백그라운드로 보내고 받고 하는 것을 볼 수 있습니다. 이정도면 도움이 될 것 같습니다. 오늘은 휴일이기 때문에 내일 회사에 가면 알려주어야겠네요.
외국에서 고생하는 한국인 엔지니어들, 모두 모두 감바레!
Monday, April 27, 2009
자바개발자에게 자바를 누가 만들었는지 물었을 때.
오랫동안 자바로 개발을 해오던 어떤 이에게, 내가 최근 마틴 파울러의 twitter를 following하게되어 그의 twitter를 알려주었데,
"마틴 파울러가 누구야?"
라고 되묻길래, '설마 모를까'하고 장난으로 "그럼 자바는 누가 만들었는지 알아?" 하고 물었더니
"썬"
이라고 대답한 사람이 있었습니다.
'음? -_-;;;'
요새 자주 얘기하는 켄트 벡, 엉클 밥, 로드 존슨, 게빈 킹등은 모른다고 해도... 'java의 아버지'라고 불리우는 이를 몰라??
'혹시 그런걸 알아야 하는걸 당연하게 생각하는 내가 이상한 거야??'
한참 생각하게 하는 일이었습니다.
혹시 몰라서 다른 친구에게 자바를 누가 만들었는지 아느냐고 물어보았습니다.
（Dev） Kim tonghyun
혹시 자바를 누가 만들었는지 검색안하고 바로 말할 수 있엄??
[산소]
도리
（Dev） Kim tonghyun
그런가...
（Dev） Kim tonghyun
흠.
[산소]
델파이는 알아.. 헤즐버그
[산소]
C#도 헤즐버그
（Dev） Kim tonghyun
그런걸 당연히 알고 있어야 한다고 생각하는 내가 이상한가... 아. 원래 델파이 전문이지.
[산소]
응 나 델파이 좋아해 >_<
（Dev） Kim tonghyun
나중에 면접때 평가하기 위해 써먹으면
오히려 면접자가 나를 이상하게 보거나 하지 않을까??
[산소]
음... 100% 평가 기준이 되지는 못하겠지만..
[산소]
나름대로의 평가기준은 될거같은데?
[산소]
단순한 일이라서 하는건지.. 얼마나 즐기면서 하는건지..
[산소]
모른다고 할땐 그걸 물어야지..
[산소]
그럼 다른 존경하는 개발자가 있냐라던지..
（Dev） Kim tonghyun
나루호도
[산소]
꼭 그거 만든 사람을 알아야 될 이유는 없다고 봐
（Dev） Kim tonghyun
나는 C는 누가 만들었는지 몰라. 근데 Charlse Petzold는 알아.
（Dev） Kim tonghyun
Charlse Petzold의 Windows Programming
[산소]
Charlse Petzold는 잘 모르겠고 Windows Programming 는 알겠다
（Dev） Kim tonghyun
ㅎㅎ
뭔가 생각하게 하는 대화였습니다.
단순한 일이라서 하는건지.. 얼마나 즐기면서 하는건지..
...
"마틴 파울러가 누구야?"
라고 되묻길래, '설마 모를까'하고 장난으로 "그럼 자바는 누가 만들었는지 알아?" 하고 물었더니
"썬"
이라고 대답한 사람이 있었습니다.
'음? -_-;;;'
요새 자주 얘기하는 켄트 벡, 엉클 밥, 로드 존슨, 게빈 킹등은 모른다고 해도... 'java의 아버지'라고 불리우는 이를 몰라??
'혹시 그런걸 알아야 하는걸 당연하게 생각하는 내가 이상한 거야??'
한참 생각하게 하는 일이었습니다.
혹시 몰라서 다른 친구에게 자바를 누가 만들었는지 아느냐고 물어보았습니다.
（Dev） Kim tonghyun
혹시 자바를 누가 만들었는지 검색안하고 바로 말할 수 있엄??
[산소]
도리
（Dev） Kim tonghyun
그런가...
（Dev） Kim tonghyun
흠.
[산소]
델파이는 알아.. 헤즐버그
[산소]
C#도 헤즐버그
（Dev） Kim tonghyun
그런걸 당연히 알고 있어야 한다고 생각하는 내가 이상한가... 아. 원래 델파이 전문이지.
[산소]
응 나 델파이 좋아해 >_<
（Dev） Kim tonghyun
나중에 면접때 평가하기 위해 써먹으면
오히려 면접자가 나를 이상하게 보거나 하지 않을까??
[산소]
음... 100% 평가 기준이 되지는 못하겠지만..
[산소]
나름대로의 평가기준은 될거같은데?
[산소]
단순한 일이라서 하는건지.. 얼마나 즐기면서 하는건지..
[산소]
모른다고 할땐 그걸 물어야지..
[산소]
그럼 다른 존경하는 개발자가 있냐라던지..
（Dev） Kim tonghyun
나루호도
[산소]
꼭 그거 만든 사람을 알아야 될 이유는 없다고 봐
（Dev） Kim tonghyun
나는 C는 누가 만들었는지 몰라. 근데 Charlse Petzold는 알아.
（Dev） Kim tonghyun
Charlse Petzold의 Windows Programming
[산소]
Charlse Petzold는 잘 모르겠고 Windows Programming 는 알겠다
（Dev） Kim tonghyun
ㅎㅎ
뭔가 생각하게 하는 대화였습니다.
단순한 일이라서 하는건지.. 얼마나 즐기면서 하는건지..
...
Subscribe to:
Posts (Atom)