달력

5

« 2024/5 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2009. 12. 30. 11:41

어떻게 질문을 하는 것이 좋을까? 메모2009. 12. 30. 11:41

HOWTO For Beginners


2. 어떻게 질문을 하는 것이 좋을까?

필자가 답변을 하면서, 질문에 다시 질문을 하는 경우가 많습니다. 이런 것은 어떻게
나옵니까? 즉, 미리 이런 것들을 적어 주시면 재 질문이 갈 필요가 없는데,

안되요
그럼 뭐가 안됩니까?
이게 안됩니다.
어떻게 안됩니까?
이렇게 안됩니다.
이건 어떤 상황인가요?
이런 상황입니다.

와 같이 무의미한 질답이 오가며 쓰레드만 길어지게 됩니다.



자신이 어떠한 상황인지를 정확하게 최대한 알려 주어야 답변하는 사람들도 가볍
게 답변을 할 수가 있습니다. ('가볍다'라는 말을 대충 이라는 말로 오인하지 말
기 바랍니다.) 그리고, 상황이 정확하고 많을 수록 답변도 그만큼 적중률이 높아
지게 되는 것입니다. 예를 들어 보겠습니다.

"메일을 보내면 local configuration error 가 발생하여 메일이 리턴됩니다."

라는 질문이 올라왔다고 가정을 하겠습니다. 그러면 답변자는

"local-host-names 에 해당 호스트 이름이 반영되어 있는지 확인해 보세요"

라는 답변을 달게 됩니다. 만약 local-host-names 에 이미 반영이 되어 있다면

"이미 반영이 되어 있습니다."

라는 답변이 오게 될 겁니다. 즉, 위의 과정은 sendmail 을 설정 함에 있어 기본
적인 셋팅을 하였는지를 다시 물어 보게되는 과정인데, 이 경우, 과정을 미리 해
놓았음에도 불구하고 리턴이 되는 것이라면, 오고갈 질답이 상당히 줄어들게 되
는 것입니다. 즉, 답변자의 입장에서는 그만큼 답변 수가 줄어들 수가 있다는 얘
기이며, 질문자도, 그만큼 빨리 정확한 답변을 받을 수 있다는 얘기가 됩니다.



자신의 상황을 자세히 알려 주시는 분들도 더러 있습니다. 하지만, ip address나
domain name 같은 것을 숨기시는 분들이 대부분입니다. 자신의 정보가 누출됨을
걱정 하시는 것이겠지만, DNS 질의시에는 이 정보가 답을 얻기 위한 굉장히 중요
한 정보가 될 수 있습니다.

질문을 하시는 사람의 입장은 분명히 절박한 상황일 것입니다. 하지만 답변을 하
는 입장에서는 그 절박함을 알 수가 없습니다. 왜냐면 답변을 하게 되는 사람도
나름대로 절박한 사정이 있을 것이고, 또한 남의 사정은 그리 급하게 느껴지지를
않기 때문입니다. 그런 상황에서 한번 꼬아서 질문을 하는 것은 답변을 하는 사
람이 그것을 다시 정리를 하거나 유추를 해야 하기 때문에 그냥 넘어가는 경우가
많습니다. 될 수 있으면, whois 같은 것을 하면 금방 드러나는 DNS 질문 같은 경
우에는 domain 이나 IP 정도는 제대로 주는 것이 좋습니다.

다시 DNS 예를 들면, 질문 시에 domain name 만 알아도 nslookup 이나, dig 같은
명령을 이용하여 방화벽 문제, 설정문제, 외부 문제 등이 유추가 되기 때문에 오
고갈 질답 수를 줄일 수 있으며, 답변을 쉽게 할 수 있는 것이기 때문입니다. 정
확한 정보가 없으면, 이것저것 체크해 보라는 질답 쓰레드가 길어질테니 미리 답
변을 포기하는 경우가 발생할 수 있는 것입니다.



답변자들은 글제목만 보고 답변을 할지를 결정하는 경우가 많습니다. 그 많은 질
문을 일일이 읽어 가면서 해 줄 여유는 없기 때문입니다. "급해요" 라는 질문은
답변자들에게 급한가 보다라는 의미 보다는 그냥 무시할 조건으로 밖에 여겨지지
않게 됩니다.



보통 error 의 경우는 수도 없이 많습니다. 어떻게 설정하고, 어떻게 셋팅하느냐
에 따라 수도없는 많은 종류의 에러 메세지가 발생하게 됩니다. 이런데도 불구하
고 안된다는 내용만의 질문은 정말 수도없이 많습니다. 에러 메세지나 error log
는 원인 을 찾는 열쇠인데, 열쇠는 주지 않고 문을 어떻게 열어요라는 식의 질문
은 절대 답변을 들을 수 없는 질문입니다.



보통 error 메세지는 아주 정확하게 원인을 알려줍니다. 하지만, 이런 간단한 한
줄짜리 영어 메세지를 두려워해서 질문을 하는 경우가 많습니다. 필자가 받은 제
일 간단한 에러 메세지는

File not found ..

였습니다. 이 것을 해석하지 못하는 또는 이해하지 못하는 사람은 없으리라 생각
됩니다.



4 번과 맥락을 좀 같이 합니다만 여기서 언급을 하는 것은 client 측의 에러메세
지는 거의 아무가치가 없다고 보시면 됩니다. 대부분의 client 측 메세지는 여려
경우를 묶어서 보내는 에러 메세지가 많습니다. 그러므로, client 측에서 나오는
에러 메세지로는 증상을 판단하기가 쉽지 않습니다. 가장 대표적인 것이 outlook
express 에서의 에러메세지입니다. 에러메세지나 에러로그를 보여 줄때는 server
측의 로그에서 해당 부분을 찾아서 보여 주시는 것이 좋습니다.



질문을 하기 전, site 를 잘 살펴 보기 바랍니다. 이 site 의 관리자가 요구하는
것이 무엇인지를 잘 알아두어야 한다는 것입니다. 관리자가 요구 하는 것을 무시
하면서 무언가를 얻을 수 있는 길은 절대 없습니다. 즉 자유 게시판에 질문 올리
는 것과 메일로 질문을 하지 말라는 것 같은 것이 대표적인 경우입니다. 질문은
질문 게시판, 잡담은 잡담 게시판 이런식으로 용도를 잘살펴 보고 질문을 하시면
됩니다.



답변을 하는 사람들은 3~4 줄의 답변을 하는데도 상당한 배려를 해야지만 가능할
정도로 바쁠 수 있습니다. 질문을 하는 사람들도 나름대로 사정이 있듯이 답변을
하 는 사람들도 나름대로의 일이 있기 마련입니다. 그런데

"메일로 답변을 주세요."
"이것 좀 만들어 주세요."
"이것 좀 해 주세요."

와 같은 식의 질문은 그냥 무시를 당하거나 DIY 라는 말을 들을 수 밖에 없게 됩
니다. 서로 기분이 나쁘게 되는 요소이므로 피하시는 것이 좋습니다.




요근래에 와서 인터넷 언어라는 새로운 용어가 생긴것 같습니다. 하지만 아직은
전세대가 공통적으로 사용하는 언어는 아니라는것이 중요합니다. 즉 질문자의 입
장에서 그런 언어를 사용하여 질문을 했을 경우 답변자가 해독이 필요한 말을 일
일이 해독 하면서 답변을 해 줄리는 없습니다.

또한 언어의 사용은 적절해야 한다고 생각됩니다. 가령 예를 들어 생활용어에 욕
이 섞여 있는 사람들이 꽤 될것입니다. (물론 필자도 그렇습니다.) 하지만, 입사
면접가서 면접볼때 생활용어들을 그대로 사용하는가를 생각해 보십시오. 즉 내가
아쉬운 것이 있을 경우 상대방의 입장에서 질문의 해야 한다는 것입니다. 상대방
의 기분이 좋을때 답변도 잘나온다는 것입니다.



정리을 하라는 말이 좀 이상할수도 있습니다. 요즘 필자의 게시판에는 필자가 하
도 땍땍거려서, 질문을 하시는 분들의 패턴이 필자가 원하는 형태로 변해가고 있
다는 점이 고맙기는 합니다. 하지만, 질문을 할때 에러 메세지를 적어 주시면서
그냥 copy 를 해서 게시판에 그냥 복사를 하고 등록을 하는 경우가 많습니다. 다
음의 예를 보도록 하겠습니다.

[oops@oops oops]$ ps uaxw
USER PID %CPU %MEM VSZ RSS TTY
STAT START TIME COMMAND
root 1 0.0 0.0 1120 476 ?
S Sep24 0:07 init [3]
root 2 0.0 0.0 0 0 ?
SW Sep24 0:00 [keventd]
root 3 0.0 0.0 0 0 ?
SWN Sep24 0:00 [ksoftirqd_CPU0]
root 4 0.0 0.0 0 0 ?
SW Sep24 0:00 [kswapd]
root 5 0.0 0.0 0 0 ?
SW Sep24 0:00 [bdflush]
root 6 0.0 0.0 0 0 ?
SW Sep24 0:19 [kupdated]
root 25 0.0 0.1 1140 516 ?
S Sep24 0:00 /sbin/devfsd /dev
root 213 0.0 0.0 0 0 ?
SW Sep24 0:04 [kreiserfsd]
root 460 0.0 0.1 1176 532 ?
S Sep24 0:02 syslogd -m 0

위와 같이 ps의 결과를 보여주는데 칸이 좁아서 아래로 한줄씩 밀려 버렸습니다.
답변을 하는 사람 입장이 아니라도 위의 메세지가 한눈에 들어 오는지 판단해 보
기를 바랍니다. 즉 이렇게 어지러운 정보를 일일히 편집해서 판단할수 있도록 수
정을 한 다음 답변을 해 주리라고 기대를 하는 것은 어불성설 입이다. 답변을 제
대로 잘 받기 위해서는 이런 사소한 것 까지 신경을 써야 합니다.

--

출처 : http://oops.org/

:
Posted by 하늘바램
2009. 12. 30. 11:40

초보자 들이 쉽게 범하는 오류 메모2009. 12. 30. 11:40

HOWTO For Beginners


제 3 판
Copyright (c) 2004, JoungKyun Kim <admin at oops.org>

이 문서는 수정, 배포, 인쇄 등에 자유롭게 사용할 수 있다. 단 이 문서를 사용함에
있어 이 문서가 사용되는 목적이 초보자를 계도함, 또는 홍보에 목적이 있다면 이 문
서의 일부분만 인용하는 것을 금하며 이 문서의 전체를 사용 하여야 한다. 이 문서의
사용이 계도에 있지 않을 경우 예를 들어 특수한 목적이 있는 문서에서 이 문서의 일
부분이 필요할 경우, 이 문서의 전체 의미를 오해하지 않도록 부연 설명을 충분히 해
야 하며, 오해의 소지가 발생하지 않도록 최선을 다해야 한다.

이 문서과 상황이 맞지 않는 경우에는, 해당 상황에 맞게끔 개작을 허락한다. 개작을
했을 경우에는 원저자의 저작권 표시를 해야 하며, 개작을 한 사람은 개작 표시를 별
도로 할 수 있다.

마지막으로 본 문서를 사용함에 있어 발생하는 피해는 본인이 책임질 수 없기에 사용
함에 충분한 고려를 하고 사용하기를 바란다.


글을 쓰면서..

필자의 홈페이지에서 질답 게시판을 운영을 하면서 beginner 즉 초보자들의 질문하는
방법에 대한 안타까움으로 인하여 이런 문서를 만들어 본다.

이 문서로 인하여 질문을 하는 사람이나 답변을 하는 사람들에게 어느정도 도움이 되
었으면 하는 바램이다.

1. 초보자 들이 쉽게 범하는 오류




필자가 답변을 하면서 질문자들이 가장 잘못 생각하시는 부분이라고 생각을 합니
다. 또한, 사이트에 질답란이 있으면, 질답란을 만들어 놓았으니, 관리자가 질답
에 책임을 져야 한다고 생각하시는 분들도 꽤 있다고 판단됩니다.

일단 중요한 것은, 고급 답변을 들을 수 있는 답변자일수록, 답변을 하기에 힘든
처지라고 판단하셔야 합니다. 고급 답변을 할 수 있는 사람의 경우에는 대부분이
super man 의 능력 (구인/구직란을 보시면 이해가 될 겁니다.) 을 보유하고 있다
고 보시면 되며, 회사에서의 super man 들의 업무는 거의 과부하라고 생각하시면
됩니다.

즉, 이런 사람들의 답변을 제대로 받고 싶으시다면, 이 글을 정말 주의깊게 읽어
보시고 질문을 하시면 도움이 될 것입니다.



보통 질답란이 있으면 강좌란도 같이 있는 경우가 많습니다. 질답란에서 자세한
설명을 원하시는 분들이 많은데, 실제로 강좌라는 것은 질답란에서 해결할 수 있
는 정도 이상의 것들이기 때문에, 따로 페이지가 구분되어 있다고 생각하면 됩니
다.

즉, 강좌 수준의 답변을 요구하는 질문은 쉽게 답변을 받을 수 있는 형태의 질문
은 아니기 때문에 최대한 빨리 정확한 답변을 받기 위해서는 세부적인 질문과 잘
정리된 형태의 질문을 하실 수 있도록 노력을 해야 합니다.

또한, 답변을 자세하게 해주는 사람들의 경우, 초보자 시절 짧은 답변에 분개(?)
를 하신 분들이나, 초보자 분들일 경우가 많습니다. 실력이 좋은 분들의 경우 업
무 역시 과중한 분들이 많기 때문에 (특히 superman 의 능력을 가지신 분들의 거
의 다 과중 업무에 시달리고 있다고 보시면 될 것 같습니다.) 질문의 맥만 짚어
주시는 경우가 많으나, 초보자들의 경우 이런 답변이 무슨 말인지 모르고 분개하
시는 경우가 많게 되는 것 입니다.



메일로 답변을 해 주는 것에 대하여 전혀 신경쓰지 않는 분들도 많다고 생각합니
다만, 이는 필자의 개인적인 생각과 다른 부분입니다.

게시판에 답변을 하는 것은 공유의 개념이 크다고 생각됩니다. 즉, 게시판에 답
변을 했을 경우에는, 다른 동일한 질문을 가지고 있는 분이 검색을 통해 찾아 볼
수가 있지만, 메일로 답변을 해 주었을 경우에는, 메일을 받은 단 한사람만이 혜
택을 받게 되는 것이기 때문입니다.

즉, 답변자의 입장에서는 중복된 질문에 의하여 스트레스를 받게 될 것이고 검색
을 통하여 답을 얻고자 하는 분들께는 그만큼 필요한 정보가 줄어들게 되는 것이
라 생각되기 때문입니다.

이런 문제는 답변자의 성향에 따라 반응이 굉장히 다르게 나타나게 됩니다. 그러
므로 답변자는 필히 자기가 답변을 하는 성향을 밝히는 것이, 질문자는 질문하기
전에 답변자의 성향을 알아 놓는 것이 굉장히 중요한 요소라고 판단이 됩니다.

또한, 질문자와 답변자 관계에서는 아쉬운 사람이 질문자 일 수 밖에 없습니다.
즉, 무언가를 요구하는 것이 아니라, 답변을 하기에 필요한 정보를 하나라도 더
적어 주시는 것이 원할한 답변을 얻는데 도움이 되기 마련입니다.



질문을 하시는 분들 중, 일부 분들은 답변을 의무처럼 강요하시는 분들이 있습니
다. 하지만, 수익모델의 질답란이 아니라면, 답변은 절대 의무가 이닙니다. 그저
좋아서, 또는 다른 분들께 받은 도움을 환원하기 위해서 일 뿐입니다. 그러다 보
니 답변은 처음에는 봉사였지만, 나중에는 댓가 없는 노동이 되는 것이 답변자의
입장이 됩니다.

또한, 답변자가 누가 될지 모르는 요소가 있습니다. 즉, 진짜 답변을 줄 수 있을
능력을 가진 사람이 될 수도 있고, 아무것도 모르면서 그냥 참견하기식의 의미없
는 답변을 하시는 분들도 있습니다. 후자의 경우 분개하는 thread 를 달 경우에
는, 해당 질문은 그저 불만을 위한 thread가 되어 버려 답변을 받지 못하게 되는
경우가 높으니, 이런 답변들은 그냥 무시하고 제대로 된 답변을 기다리시는 것이
현명한 것입니다. 또한, 왠만하면 잘못된 답변에는 지적을 위한 thread 가 붙을
확률이 높으니, 분개하지 말고 그냥 답변을 기다리는 것이 현명한 판단입니다.



답변이 없는 경우는 대체로 아래의 패턴이라고 생각시하면 됩니다.

1. 해당 질문에 대하여 아는 사람이 없다.
2. 답변을 하기에 난감한 질문이다.

대부분의 위의 경우에 속하기 때문에, 무시한다고 생각하실 필요는 없습니다. 그
러므로 답변이 없다고, 페이지가 넘어갔다고 반복적으로 계속 질문을 올리는 것
은 게시판의 도배처럼 되어 버리기 때문에 관리자에게 퇴출(?) 대상이 될수도 있
습니다.

더 문제는 2번의 경우입니다. 이 경우는 질문자 스스로 질문을 해 보셔야 합니다.
과연 답변을 줄 수 있을지 말이죠.



Do It Yourself. 쉽게 말하면 "알아서 하십시오" 라는 의미입니다. 하지만 이 말
이 나오는 이유는 쉽게 찾을 수 있는 내용을, 노력없이 답변만 얻기를 원하는 질
문에 많이 나오는 형태의 답변입니다. 이런 답변을 받으셨을 경우에는 질문에 대
하여 본인이 얼마나 노력을 했는지를 다시 생각해 보시는 것이 좋습니다.



필자는 급질문이라는 질문치고 정말 급하게 와 닿은 적이 없습니다. 이는 답변을
해 보신 분들은 모두 공감을 하리라 생각됩니다. 나름대로 급할지는 모르겠지만,
답변자들이 급한 문제는 아니기 때문이며 오히려 역효과를 볼 수도 있습니다. 이
런 경우에는 급질문이라는 3글자를 쓸 여유에, 좀 더 자세한 상황을 적어 주시는
것이 효과적입니다.



완전한 착오 입니다. 답변자의 경우에는, 자기의 기준에 부합하다고 판단되는 질
문에 답변을 하기 마련입니다. 즉, 재수 없으면 일주일 이상이 걸려도 답변을 받
지 못할 수도 있습니다.

또한, 필자가 공부를 시작한 시점과 비교하여, 현재는 엄청난 양의 국어 자료가
있으며, 지능형 검색기들의 발달로 인하여, 기다리는 시간에 에러 메세지를 검색
기에서 찾아 보는 것이 훨씬 더 빠릅니다.



질문 게시판, 자유 게시판이 있으면 사람들은 자유 게시판에 사람들이 더 많겠지
라는 생각에 질문 게시판의 용도를 무시하고 자유게시판에 질문을 하시는 분들이
있습니다. 이는 완전한 판단 착오입니다. 게시판 용도를 구분하는 이유는 효율적
으로 관리를 하기 위함인데, 이 용도를 무시하고 질답 게시판 외에 질문을 하고,
삭제 한다고 난리를 치는 것은 누워서 침뱉기라는 것을 명심 하셔야 합니다. 로
마에서는 로마법을 따르고, 해당 site 에서는 해당 site의 운영지침을 따라야 하
는 것 입니다.



질문을 하시기 전에 주의를 하셔야 하는 것은, 해당 사이트에 질답란이 있는지,
또는, 해당 글에 어디로 질문을 하라고 되어 있는지 여부를 확인 하셔야 합니다.
즉, 답변을 할 사람의 의견을 무시한 질문은 답변을 받을 수 없는 첫번째 요소가
되기 때문입니다.

또한, 대부분의 답변을 하시는 분들은 질문 메일이 spam 수준에 이르게 될 수도
있습니다. 즉, 처음에는 일일이 답변을 해 주다가 나중에는 그냥 spam 메일을 삭
제하듯 지우게 될 수도 있기 때문입니다.

즉, 메일로 질문을 한다고 하여 확실하게 답을 받을 수 있는 근거는 전혀 없으며
메일로의 질문은 메일 이외의 communication 이 힘들다는 판단을 하였을 경우 행
하셔야 합니다.



안되니까 질문을 하는 것에는 이해를 하겠지만 어떻게 안되는지에 대하여 언급이
없다면 답변은 받기 힘들다고 보시면 됩니다. "부팅이 안되요" 라는 질문에 어떠
한 답변이 최상일까 생각해 보십시오. 필자의 최상의 답변은 "새로 설치하세요"
입니다.



이런 답변들은 보통 고수(?)들에게 많이 나오는 답변 형태일 겁니다. 단순히 해
결만을 위한 질문자라면 이런 형태의 답변이 아주 고약(?)스러운 답변이지만, 공
부를 위한 질문을 하시는 분들에게는 필자의 견해로는 최선의 답변이라고 생각됩
니다.

답변을 하다 보면 답답할 경우가 많습니다. 답변을 해 주면 그 이상의 것은 절대
알아보려고 시도를 하지 않는 다는 것입니다. 즉 응용력을 기르지를 못한다는 것
이며, 이런 경우에는 유사한 질문이 계속 나오게 되기 때문입니다.

즉, 답변자의 입장에서는 어떡하든 질문자가 스스로 답변을 찾아 나갈 수 있도록
능력을 길러 주는 방향으로 답변을 해 주는 것이며, 이런 답변을 해 주었을 경우
질문자들의 능력이 향상되는 것을 볼 수가 있기 때문입니다.

그러므로, 초보자의 입장에서 이런 답변을 받았을 경우에는 짜증이 날 지도 모르
겠지만, 어느정도 실력이 높아지면 왜 이런 답변을 했는지 이해를 할 수 있게 될
것입니다.

이런 답변을 받게 된다면, 답변을 잘 읽어 보시고 답변이 유도하는 데로 검색을
해 보시고, 검색 결과에 대하여 다시 질문을 하시면 됩니다.


대충 12 가지 정도의 패턴을 적어 보았습니다. 이 글을 읽는 사람이 위의 패턴에 해
당되 는 것이 있는지 생각해 보기를 바랍니다. 이 패턴들은 필자가 답변을 하면서 답
답하고 안타까웠던 부분을 대충 정리해 본 것입니다.

--

출처 : http://oops.org/

:
Posted by 하늘바램
2009. 8. 19. 08:57

삼가 고인의 명복을 빕니다. 메모2009. 8. 19. 08:57

부디 편안히 잠드시길...

- 2009.08.19 13:43 김대중 전 대통령 서거.
:
Posted by 하늘바램
2009. 7. 3. 18:03

크리스탈 레포트 8.5에서 MAPI EXPORT 메모2009. 7. 3. 18:03



크리스탈 레포트 8.5에는 위와 같이 프린터가 아니라 다른 형태로 export를 할 수 있는 기능이 있다.
다른 버전도 물론 있겠지만 내가 지금 사용하고 있는건 8.5 버전이니까 8.5로 한다.

그런데 위에 보면 Microsft Mail이라고 보고서를 메일첨부파일로 보낼 수 있는 기능이 있는데
가끔씩 요게 안보이는 PC들이 있다.

그런경우에는 c:\windows 폴더에 있는 win.ini 파일을 확인해보자.

...
[files]
[Mail]
MAPI=1
CMCDLLNAME32=mapi32.dll
CMC=1
MAPIX=1
MAPIXVER=1.0.0.1
OLEMessaging=1
[MCI Extensions.BAK]
...

위에 빨간색 부분이 없을것이다.
이 부분을 추가해주면 보인다.

그런데 그럼에도 불구하고 응용프로그램에서 시도를 해보면 아웃룩과 연동이 되지 않고 에러가 나는
경우(MAPILogon Error)가 있는데 그런 경우에는



여기서 MAPI Client 프로그램을 아웃룩으로 설정해주면 된다.
:
Posted by 하늘바램
2009. 5. 19. 08:38

[JSP] PreparedStatement 메모2009. 5. 19. 08:38

JSP에서 쿼리문을 사용할 때 PreparedStatement를 사용하는 방법.

1. 객체생성
PreparedStatement pStmt = connect.prepareStateme("select id, name from table where id = ?");

2. ? 에 값 지정
setInt(1, id_value)
or
setString(1, id_value)

3. 실행
ResultSet rs = pStmt.executeQuery();
pStmt.close();
:
Posted by 하늘바램
2009. 5. 14. 09:03

JSP 몇가지 메모2009. 5. 14. 09:03

1. setProperty
JSP 페이지의 파라미터 이름과 자바빈 프로퍼티의 이름을 같게하면 다음과 같은 한 줄로 모든 파라미터를 한꺼번에 저장할 수 있다.
<jsp:setProperty property="*" name="BeanName" />

2. JSP의 DB 연결 순서.
- JDBC 드라이버 로드
    Class.forName("oracle.jdbc.driver.OracleDriver");
- Connection 생성
    Connection con = DriverManager.getConnection(url, uid, pwd);
    (oracle url : jdbc:oracle:thin:@localhost:1521:ORCL
     mysql url  : jdbc:mysql://localhost:3306/jdbc
     ms-sql url: jdbc:microsoft:sqlserver://localhost:1433)
- Statement 객체생성
    Statement st = con.createStatement();
- SQL 문 실행처리
    ResultSet rs = st.executeQuery("select * from table");
    (update, insert, delete 등의 쿼리문을 실행할 때는 executeUpdate 메소드를 사용한다)

3. ResultSet 값을 가져올때 컬럼명을 사용하는 것보다 인덱스번호를 사용하는 것이 속도면에서 더 빠르다. 하지만 소스가독성면에서는 현저히 떨어지기 때문에 주의해야 한다.
4. JSP에서 선언부( <%! ~ %> )는 첫 방문자에 의해서 단 한번만 수행된다.
5. <%~%> : 요걸 '스크립트릿(Scriptlet)' 이라고 부른다.
:
Posted by 하늘바램
2009. 5. 12. 08:32

JSP 한글처리 메모2009. 5. 12. 08:32

1. 웹페이지 :  지시자에서 캐릭터 셋을 euc-kr로 지정.
<%@ page language="java" contentType="text/html;charset=euc-kr">

2. post 방식 :  request 객체의 인코딩 방식을 euc-kr로 변경.
<% request.setCharacterEncoding("euc-kr") %>

3. get 방식 : String 클래스의 getBytes 메소드를 사용.

    수신시 : 영문을 한글로 변환(8859_1 -> euc-kr)
 String s_name = request.getParameter("name");
 s_name = new String(s_name.getBytes("8859_1"), "euc-kr");

    전달시 : 한글을 영문으로 변환(euc-kr -> 8859_1)
 String s_name = "한글변환";
 s_name = new String(s_name.getBytes("euc-kr"), "8859_1");
:
Posted by 하늘바램

getParameterValues 메소드를 사용하면 같은 이름을 가진 항목들의 값을
배열로 받을 수 있다.

String []item;
item = req.getParameterValues("item");

과 같은 방법으로 사용가능하다.

:
Posted by 하늘바램
2009. 4. 30. 07:32

JSP 한글처리 메모2009. 4. 30. 07:32

//한글처리 클래스
package myUtil;
import java.io.UnsupportedEncodingException;

public class HanConv {
 //8859_1 방식을 euc-kr 방식으로 변환하는 메소드 정의
 publick static String toKor(Sting str) {
  if(str==null || str.equals("") || str.equals("null")) {
   return str;
  }
  try{
   return new String(str.getBytes("8859_1"),"euc-kr");
  }catch(UnsupportedEncodingException uee) {
   uee.printStackTrace();
   return str;
  }
 }
 //uec-kr 방식을 8859_1방식으로 변환하는 메소드 정의
 public static String toEng(String str) {
  if(str==null || str.equals("") || str.equals("null")) {
   return str;
  }
  try{
   return new String(str.getBytes("euc-kr"),"8859_1");
  }catch(UnsupportedEncodingException uee) {
   uee.printStackTrace();
   return str;
  }
 }
}

import myUtil.HanConv;
문장을 사용해서 함수를 호출한다.

post방식에서 인코딩변경
req.setCharacterEncoding("euc-kr");

get방식에서 인코딩변경
String name=req.getParameter("name");
name = new String(name.getBytes("8859_1"), "euc-kr");

:
Posted by 하늘바램
2009. 2. 25. 14:14

2003서버 엑셀 문제 메모2009. 2. 25. 14:14

http://blog.eloitcube.co.kr/tag/Windows%202003%20Server

일단 급한대로 링크만
:
Posted by 하늘바램