영화 "스카우트"에 나오는...ㅋ

비광 -서곤태-

나는 비광
섯다에는 끼지도 못하고
고스톱에서는 광대접 못 받는 미운오리새끼

나는 비광
광임에도 존재감 없는 비운의 광
차라리 내 막내 비쌍피가 더 인기 많아라

하지만 그대
이것 하나만 기억해주오
그대가 광박 위기를 맞을 때 지켜주는 것은 나 비광이요
그대의 오광 영광을 위해 꼭 필요한 것도 나 비광인 것을

나는 비광
없어봐야 소중함을 알게 되는
슬픈 광

HAL API는 단말API와 매칭되는 것을 사용함.

arm or gcc

3g에서는 pause, resume이 안 먹음

pSpace: 소스코드가 메모리에 올라가는 양, 리소스(사운드, 이미지) 포함 안된것.
static 변수, 배열

oSpace: startApp 이후 새로 생성하는 객체.

ktf c++ 위피 2.0 단말.

메인클래스: 패키지명.클래스

* 단말등록 옵션

최대 Thread 갯수
1개로 했을때 간혹 어플이 무한루프에 빠졌을때 실행이 안될 경우가 있음.

프리로드: 어플이 단말출시때 설치되어 나옴.

offrun: 폴더를 닫았을때 어플이 종료되지 않고 계속 구동.

압축 하면: 사이즈 줄어들고, 실행속도 줄어든다.
압축 안하면: 사이즈 늘고, 실행속도 빠름.

아이콘은 8, 16 비트로 작성.
24, 32일때 리부팅 되는 단말 있음.

컴파일 실패 요인.
1) .java 파일에 소스가 너무 길때(10,000 라인 정도)
2) 함수명이 길때.
3) 코드 오류...(사용 못하는 API 사용등)

시리얼 통한 디버깅 안될때 SIO 모두 달라서 그런것.

D:\oraclexe\app\oracle\product\10.2.0\server\RDBMS\ADMIN
scott.sql 실행

커맨드 창에서 저 폴더로 일단 들어가서
sqlplus / as sysdba 로 접속한 다음
SQL> @scott
실행시키면 만들어진다
아마 @scott 실행시키고 한 10~20초 소요

 / as 는 윈도우 계정인증으로~ dba로 접속하겠다는 뜻.

p.47
소프트웨어 내부의 버그는 잔디밭에서 자라는 잡초와 같아. 잡초가 자라면 약을 뿌려야지.
하지만 아무리 약을 뿌려도 잔디밭에 핀 잡초가 완전히 사라지지 않는 것처럼 아무리 노력해도
버그가 전혀 없는 소프트웨어는 만들 수 없어.

p.95
프로그래머로서 일하는데 있어서 중요한 것은 주어진 질문에 대한 정답을 찾는 능력이 아니라,
질문 자체를 정확하게 구성하는 힘이다.

p.129
프로그래밍 솜씨가 뛰어난 사람일수록 자신의 코드를 믿지 못하여 반복해서 테스트를 수행하고,
프로그래밍 솜씨가 떨어지는 사람일수록 자신의 코드가 완벽하다는 순진한 믿음을 갖는다.

p.140
지난 37년 동안 나는 하루에 14시간씩 연습을 했다. 그러고 났더니 사람들은 나를 천재라고 부르더라.
-파블로 드 사라사테

p.186
곰팡이가 그늘 속에서 습기를 먹고 자라는 것처럼
버그는 프로그래머의 게음름과 착각을 먹고 산다.

p.210
사용자는 일반적인 사람의 집합이 아니다.
1. 참을성이 없다.
2. 끝이 보이지 않는 요구를 가지고 있다.
3. 제로에 가까운 기억력을 가지고 있다.

감상문.
소설의 형식을 취하고 있지만, 필자의 오랜 개발 경험이 녹아 있어 마치 필자의 일기장을 읽고 있는 듯하다.
각 캐릭터의 성격을 빌려 개발자로서 가져야할 태도에 대해서 집중 조명하며, 앞으로 나아갈 방향을 제시해준다.

15 ~ 20 : 부모말 잘듣고, 체력 단련하고, 수능 잘보고
              * 수능 점수에 따라 직장 첫월급이 결정되는 확율이 95% 랍니다
              * 부모말 잘듣는 사람이 선생님과 직장 보스 말을 잘듣죠=>출세의 지름길

20 ~ 25 : 영어 잘하고, 여자 친구 잘 사귀고,술 잘마시고
              * 연애 잘하는 사람이 나중에 비지니스를 잘한답니다.
              * 술잘마시는 사람이 직장 보스 잘모시고요

25 ~ 30 : 직장 들어가서 시키는일 잘하고, 장가갈 준비하고
              * 시키는 일 잘해서 포지셔닝 하는게 중요 하져~

30 ~ 35 : 전문분야를 확보하고, 귀여운 자식 한둘 낫고
               * 전문분야가 있어야 평생 먹고 사는데 지장이 없죠

35 ~ 40 : PM,팀장 등의 역할
               *  남을 통해 일을 실현하는 리더쉽 키우고
              
40 ~ 45 : 조직을 위해 돈을 잘 벌어 오고
               * 이때는 엔지니어 보다, 영업이 유리하죠.
               * 나이 40 넘으면 기술은 버려야 됩니다. 후배들이 더 잘하니까.

45 ~ 50 : 자기만의 일을 만들어 내야 하고(신규사업 등), 인생 2모작 준비
               * 제2의 인생 준비하는데 적어도 5년은 투자 해야죠~

50 ~ 55 : 사회생활 마무리, 인생 2모작 착수
               * 인생 2모작은 중요합니다..좀 있으면 평균 년령이 90세를 넘기 때문에
                  뭐하고 시간 보내느냐가 너무 괴로운 일..

55 ~     : 무엇을 갖었느냐? (돈,명예,자식)
              * 이중에서 한개를 갖으면 성공
              * 두개를 갖으면 대성
              * 3개를 갖으면 불행이 찾아올걸?

p. 27
내가 일하는 시간의 절대량보다 능력을 최대한 발휘한 시간이 진정한 의미의 생산성이다.
명확한 목표가 있을 때 몰입할  가능성이 높다.

p. 39
왜 이 일을 꼭 이렇게 해야 하는지, 그리고 좀 더 나은 방법은 없는지를 생각하지 않고 일을 잘 할 수 없다.

p. 41
IT 프로젝트의 현실
프로젝트는 90% 달성될 때까지는 빨리 진행된다. 그런데 나머지 10%가 영원히 계속된다.

p. 51
개발자는 프로그래머보다 진보적인 개념으로 프로그램을 짜는 차원을 넘어서 소프트웨어 제품을 만드는 사람이다. 기술뿐아니라 커뮤니케

이션, 문제해결, 팀워크에 대한 능력을 가지고 있다.

p. 77
실패하는 프로젝트의 7가지 습관
프로젝트에 투입되는 인력의 자질에 따라 많게는 28배 이상의 생산성 차이를 나타낸다.

p. 84
프로젝트 관리의 핵심요소라고 할 수 있는 일정과 비용, 품질이 균형있게 잘 관리되어야 한다. 이 세 가지 요소는 서로 대립적인 관계가

아님을 명심하라. 그리고 가장 중요한 한 가지, 고객을 항상 염두에 두어라. 모든 비즈니스는 고객을 돕는 일이다. 프로젝ㅇ트도 마찬가

지다. 프로젝트는 내부 고객인 프로젝트 팀원과 시스템을 사용할 실제 고객을 만족시키는 활동이 지속적으로 이루어져야 하며 또 결과로

나타나야 한다. 이것이 누구나 프로젝트의 성공을 바라지만 실제 성공시키기는 어려운 가장 큰 이유다.

p. 97
실속있는 요구사항 개발을 위한 몇 가지 원칙
1. 요구사항 누락을 막아라.
2. 사용자층을 정확하게 식별하라.
3. 고객의 참여를 이끌어내라.
4. 요구사항의 가시성을 높혀라.
5. 우선순위를 부여하라.
6. 요구사항 검토 및 승인활동을 반드시 실시하라.
- 요구사항을 검토한다는 것은 충분한 대화를 나누라는 뜻이다.

p. 103
프로타이핑 퍼포먼스
일하는 방법을 이해한다 -> 관찰한다 -> 시각화 한다 -> 평가하고 다듬는다 -> 실천한다
시각화 한다 = 프로토타입을 만드는 과정

프로토타입 성공요소
- 프로토타입을 개발하고 평가하는 일정을 프로젝트 계획에 반영하라.
- 완벽한 사용자 인터페이스 프로토타입은 존자하지 않는다. 다양한 프로토타입을 개발하라.
- 요구사항에 대한 이해가 완벽한 경우에는 굳이 프로토타입을 만들 필요는 없다.
- 프로토타입에 사용할 데이터는 현실적이어야 한다. 검토자가 비현실적인 데이터에 관심을 두면 프로토타입의 본래 목적을 잃기 쉽다.
- 프로토타입으로 프로그램 명세서를 작성해서는 안 된다. 프로토타입은 화면의 항목에 대한 상세한 정의, 예외 처리 등에 대해 다루지 않는다.

p. 119
데이터베이스 모델링
완벽한 설계는 더 추가할 게 없을 때가 아니라 더 이상 뺄 것이 없을 때 완성된다.

p. 124
3차 정규화까지는 반드시 숙지할 것
3차 정규화는 데이터 중복을 제거하기 위한 데이터베이스 설계의 일반적인 목표이다.
1정규화: 모든 속성은 하나의 값을 가져야 한다.
2정규화: 모든 속성은 식별자(Unique Identifier) 전부에 종속되어야 한다.
3정규화: 식별자가 아닌 모든 속성들간에는 종속될 수 없다.

p. 137
똘레랑스(Tolerance) - 견딘다.
대충 절충해서 합일점을 찾는 타협이ㅏ 아니라 그보다 한 차원 높은 상태에서 서로 다른 상대방을 있는 그대로 받아들이고 그것을 견디어

내는 관용과 존중의 정신이다.

p. 268
소프트웨어 품질의 특성
기능성(Functionality): 소프트웨어가 주어진 조건하에서 사용될 때 명시적 혹은 묵시적 요구 기능을 제공하는 능력
신뢰성(Reliability): 소프트웨어가 주어진 조건하에서 사용될 때 정의한 일정 수준의 성능을 유지하는 능력
사용성(Usability): 소프트웨어가 명시한 조건하에서 운용 시 사용자가 쉽게 이해하고, 배우고, 활용하며, 친숙해질 수 있는 정도
효율성(Efficiency): 명시한 조건하에서 사용한 자원의 양을 기준으로 적절한 성능을 제공하는 능력
유지보수성(Maintainability): 소프트웨어의 수정요이성 정도. '수정'은 교정, 개선, 환경변화에 대한 적응을 포함
이식성(Portability): 소프트웨어를 다른 환경(조직, 하드웨어, 소프트웨어 환경)으로 이식할 수 있는 정도

p. 310
누가 적합한 사람인지의 여부는 전문 지식이나 배경, 기술 보다는 성격상의 특질이나 타고난 소양과 더 관련이 있다.

p. 319
슈메르체크가 - '정글세미나'

p. 331
- 전문지식: 어떤 사람이 적어도 하나의 특정 분야에 정통하다면, 다른 분야에도 정통할 수 있는 능력이 있다고 볼 수 있다. 전문지식은

일을 하기 위한 기본이다. 기술은 매우 빠르게 변하므로 스스로 연구할 수 있고 매우 복잡한 내용도 이해할 수 있는 능력이 필요하다.
- 프로젝트에 대한 헌신: 성실한 자세와 뜨거운 열정은 프로젝트에 긍정적이다. 팀의 사기를 복돋아준다. 지원 희망분야나 전직 사유 등

을 질문해 보라.
- 프로젝트 성공, 실패 사례: 과거에 수행했던 프로젝트 중에서 기억에 남는 성공, 실패 사례를 한 가지씩 이야기하게 한다. 그리고 왜

그랬는지? 원인을 분석하게 함으로써 가치관을 엿볼 수 있다.
- 팀워크: 프로젝트 성공의 핵심요소 중의 하나는 팀워크다. 팀워크가 잘 발휘되었던 멋진 사례, 아니면 반대의 사례를 이야기하게 하고

몇 가지 질문을 던져본다. 예를 들어 진척이 처진 동료를 도와준 사례가 있었는지, 왜 도와주었는지?
- 문서작성능력: 이력서와 자기소개서를 보면서 경험한 업무와 기술이력헤만 초점을 두지말고 글쓰기 능력을 살펴보라. 문서작성은 소프

트웨어 개발의 중요한 요소이다. 이력서와 자기소개서의 전개방식을 검토하라.
- 자신의 장, 단점: 끝으로 자신의 장점과 단점을 한 가지씩 언급하게 한다. 면접 중 관할한 것과 일치하는지 비교해 본다.

p. 339
IT 전문가의 조건
- 최고의 실력자가 되려는 전문성
- 평생 학습에 대한 욕구
- 스스로 배우려는 노력
- 뛰어난 문제해결 능력
- 명쾌한 커뮤니케이션 능력

p. 354
히로나카의 '학문의 즐거움'
어떤 문제에 부딪치면 나는 미리 남보다 시간을 두세 곱절 더 투자할 각오를 한다. 그것이야말로 평범한 두뇌를 가진 내가 할 수 있는 최

선의 방법이다.

p. 386
기술사 시험은 정해진 시간 안에 정해진 분량을 써내는 것이 기본이다. 품질은 그 다음이다.

p. 389
기술사 시험은 한 분야를 깊이있게 파기 보다는 전체적인 IT프레임워크에 대한 이해의 성격이 강하다.

p.22
요구분석 담당자
무엇을 만들지가 잘못 정의되어 있으면 애써 개발한 시스템도 아무런 소용이 없다. 프로젝트의 성공을 위해서는 옳은 계획과 방법을 찾고, 그것을 제대로 수행해야 한다. 여기서 옳은

계획과 방법이 무엇인지 결정하는 것이 요구분석 담당자의 중요한 역할이다.
- 요구사항 담당자는 '무엇을, 어떤 계획과 방법으로 만드는 것이 옳은가'를 결정한다.

p.23
인프라 담당자
성능(performance, 정지시간(downtime), 백업 같이 시스템이 직접 수행하는 기능이라고 보기 어려운 구조적이고 관리적인 요구사항, 즉 비기능 요구사항을 수집해서 정리하고 이것을 만

족시키는 인프라를 구축하기 위해서 어떤 제품을 써야 할지도 결정한다.
- 인프라 담당자는 개발 환경과 운용 환경을 정비한다.

p.25
프로그래머
프로그래밍이야말로 시스템 개발의 근간이라 할 수 있다.
프로그래머는 아키텍트가 작성한 아키텍처 설계서와 프레임워크에 대해 피드백하면서, 아키텍트의 업무를 배울 수도 있다.

p.27
운용 담당자
시스템을 개발할 때 운용 담당자는 일상 업무가 안정적이고 효율적으로 이뤄지도록 해야 할 뿐 아니라, 장애 발생에 따른 대책 역시 수립해야 하는 것이다.
여러분이 프로그래머임에도 운용 업무에 대해 폭 넓게 인식하고 있다면, 시스템 설정을 변경하거나, 부팅과 재부팅을 쉽게 하고, 장애가 발생할 경우 원인을 쉽게 판단할 수 있도록 로

그를 적절하게 출력하는 등, 운용 목적에 맞게 시스템을 개발할 수 있을 것이다. 또한 시스템을 보는 시야가 넓어지므로 적용 기술 역시 다양해질 것이다.
- 운용 담당자는 매일매일 시스템을 안정적으로 가동하는 업무를 담당한다.

p.29
아키텍트의 주요 업무
1.개발에 쓰일 다양한 템플릿을 만드는 일 (시스템 개발의 중심은 설계와 프로그래밍)
 용어나 개념의 이해는 개인에 따라 다르므로, 아키텍트가 템플릿을 정리해 제공한다.
2. 설계 지침 제공
사전에 설계와 구현 단계에서 개발자가 내려야 할 판단에 대한 지침을 제시한다. 예컨대 '비즈니스 로직 레이어는 무상태 세션빈(Stateless SessionBean) 으로 구현하고, 원격 메소드의

크기는 시스템 수준의 유스케이스(Use Cases) 단위로 한다. 클라이언트가 되는 웹 단의 컴포넌트는, Context나 Home 인터페이스를 캐시해 성능 향상을 도모한다. 리모트 호출에 따른 실

행 시 예외에 대해서 로그를 출력한다.

- 개발자마다 판단 기준이 다르지 않도록, 아키텍처로 지침을 제공한다.

아키텍처: 소프트웨어 전체에 영향을 미치는 여러 요소를 지침으로 정리한 것
아키텍트: 아키텍처를 결정하는 사람으로 소프트웨어 전체, 프로젝트 전체에 밀접하게 연관된 역할
프레임워크: 추상적인 지침인 아키텍처에 비해 더 실제적으로 개발자에게 도움이 되도록 구현해 제공하는 부분

아키텍트는 아키텍처와 프레임워크를 이용해서 기술 수준이나 경험이 제각각인 개발자들이 협조하여 일할 수 있도록 이끄는 역할을 한다.

- 추상적인 방침인 아키텍처의 핵심 기능 중 공통으로 이용할 수 있는 기능을 구현해 프레임워크로 제공한다.

p. 32
개발자로서 아키텍트
1. 아키텍트는 아키텍처와 프레임워크로 프로젝트를 이끄는 위치이므로 문제점의 근원을 해소한다.
2. 장래 계획으로 아키텍트라는 구체적인 모델을 그릴 수 있어 진로를 명확하게 할 수 있다.

p.37
요구사항 분석은 시스템이 어떠한 기능을 요구하는지 비즈니스 관점에서 파악하고 정리하는 것
명세 설계는 분석 결과로 나온 각종 요구 조건을 판단 근거로 삼아, 화면 설계와 데이터베이스 테이블 설계, 기능 요구사항, 성능과 장애에 대한 내구성과 같은 구조적이고 관리적인 요

구사항을 정리

p. 43
요구분석 단계에서는 예산의 범위나 투자 대비 효과 등 비즈니스상의 제약조건에 영향을 받는다. 그러므로 목표를 실현하기 위한 기술적인 아이디어를 내는 것이 중요하다. 아이디어를

내기 위해 요구분석 담당자와 아키텍트를 중심으로 브레인스토밍을 해보는 것이 좋은데, 최종적으로 그 아이디어를 이용하는 경우에 발생할 기술 제약에 대핸 검토하는 것도 잊지 말아

야 한다.
- 프로젝트 전반부의 담당자는 비즈니스 마인드로 프로젝트를 바라보는 능력이 있어야 하며, 그러한 능력은 아키텍트에게도 요구된다.
- 요구사항 정의 단계에서 아키텍트는 기술 전문가의 입장에서 조언한다.

p. 46
기술적인 위험요소는 간단한 것이라도 나중까지 남겨두지 않는 것이 중요하다. 설계를 변경하거나 요구사항을 조정하는 방식으로 해결하지 못한 경우에는, 위험요소의 원인이 되는 요구

사항을 개발 초기에 구현하고 검토하는 반복형 개발을 선택하여, 개발 후반부까지 위험요소가 남지 않도록 프로젝트 계획을 수정해야 한다.
- 기술 관련 위험요소는 개발 초기에 해결한다. 그것이 어렵다면 위험요소 해결을 위한 계획을 수립한다.

p. 48
- 비기능 요구사항은 최종사용자에게서 도출되는 것이 아니므로, 기술자가 적극적으로 제안한다.

p.49
아키텍트가 제안하는 명세는 개발하기 쉬운 쪽으로 치우치기 쉽다.
아키텍트는 실제 구현 상황을 우선하고, 사용자의 편의성을 그 다음으로 생각하는 경향이 있다. 아키텍트가 충분히 이해하지 못해서 실제 사용자에게는 매우 중요한 기능을 무시하는 경

우도 있다. 아키텍트는 구현단계에서도 그래야겠지만 분석, 설계 단계에서는 특히 사용자를 중심으로 상황을 인식하는 것이 바람직한다.

p. 59
아키텍처 정의: 애플리케이션 설계와 구현의 기본지침

p. 180
개발자가 납득할 수 없는 업무는 다른 사람들에게도 좋지 않으며 비즈니스에도 문제를 일으킬 가능성이 많다.
- 개발자가 납득할 수 없는 시스템은 비즈니스에도 문제가 된다.

P.185
시스템 개발 방정식
변수: 비용, 품질, 범위, 기간
(품질 * 범위) / 기간 = 비용

2. 프로젝트 리더(PL)의 이해 : 프로젝트 리더는 고객이 말한 것을 자세히 파악하지 못하고 일부분만 어렴풋이 이해한다(건물의 창문이 원래 9개에서 기다란 3개로 둔갑한다.).

3. 분석가의 설계 : 업무를 분석하고 설계한 결과는 전혀 연관성이 없고 실제구현되기 어렵게 디자인되어 있다(건물은 둘로 갈라져 있고 가분수의 모양을띠고 있다.).

4. 영업의 약속 : 고객에게 실현될 수 없는 장밋빛 공약을 남발하여 프로젝트를 더 힘들게 한다(세상에 대한민국에 안 되는 게 어디 있냐고 하지만 놀이기구처럼 환상적인 건물을 지을 수 있다고 허풍을 치다니…….).

5. 프로젝트 문서 : 프로젝트 산출물은 납기준수라는 미명하에 거의 흔적을 찾아볼수없다(철근구조물흔적만남아있을뿐이해하기는거의불가능하다.).

6. 고객 청구 금액 : 고객에게 청구하는 금액은 정확한 기준이 없이 들쭉날쭉하다(마치 건물 위로 도르래를 이용하여 왔다갔다 이동하는 운반기구처럼 거의 공짜로 해주겠다고 하다가 만만한 고객을 만나면 과다청구하기도 한다.).

7. 본사 지원 : 회사에서 지원 받은 것은 전혀 없다. 어떤 문제가 발생하더라도 프로젝트에서 알아서 잘 해결하라는 미션 임파서블이 프로젝트의 목표이다(지원을 받으면 프로젝트의 현실을 제대로 이해하지 못해 오히려 땅이 꺼질 정도로 역효과가 크다.).

8. 고객이 진짜 필요한 것 : 아뿔싸, 지붕이 있는 2층짜리 예쁜 건물이었다.

대학민국 개발자 희망 보고서...에서 발췌.

* SQL level backup of a table
SELECT ... INTO OUTFILE 또는 BACKUP TABLE

* SQL level load of a table
LOAD DATA INFILE 또는 RESTORE TABLE

다음은 사용 예입니다.
mysql> USE db1;
mysql> SELECT * INTO OUTFILE "data.txt" FROM test_table;

mysql> USE db1;
mysql> LOAD DATA INFILE "data.txt" INTO TABLE test_table;

mysql> BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'
mysql> RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'

1. select 결과 -> text 출력
sql> SELECT * INTO OUTFILE '출력파일.txt'  fields terminated by '|' lines terminated by '|\r\n'  FROM 테이블;

2. text ==> db
sql> load data infile '출력파일.txt' into table 테이블 fields terminated by '|' lines terminated by '\n';

mysqldump -u root -p ljk_test --no-data > testtest.sql

@echo off
for /f "tokens=*" %%i in ('cd') do set DoADP=%%i
for /f "tokens=1 delims=:" %%i in ('cd') do set DoADRIVE=%%i
for /f "tokens=2 delims=:" %%i in ('cd') do set DoAPATH=%%i

@echo on
echo %DoADP%
echo %DoADRIVE%
echo %DoAPATH%

SK-VM은 EUC-KR로 인코딩설정이 되어 있습니다. (J2SE와 동일하게)
그러므로 서버에서 ASCII나 EUC-KR바이트를 수신해서 바이트 배열에 저장되었을때

ASCII, EUC-KR ---> UNICODE
new String( byte[] byte ) 생성자를 사용하면,
SK-VM은 바이트 배열을 16bit 유니코드 문자열로 변환 합니다.
(MIDP API Ref 참조)

UNICODE ---> ASCII, EUC-KR
String.getBytes(byte[] byte) 메쏘드를 사용하시면
SK-VM이 유니코드를 ASCII또는 EUC-KR로 변경 합니다.
(MIDP API Ref 참조)

http://www.unicode.org

※ 설치순서.
eVT(eVC++ 3.0 hpc 및 ppc SDK 연속해서 설치됨) -> eVC++ 4.0 -> eVC4sp4 -> ppc 2003 sdk ->ppc 2002 sdk

※ Pocket PC 2003 SDK 설치 순서
1. Microsoft Pocket PC 2003 SDK.msi
2. Windows Mobile 2003 Second Edition Developer Resources.msi
3. Windows Mobile 2003 Second Edition Emulator Images for Pocket PC - WWE.msi
4. Windows Mobile 2003 Second Edition Emulator Images for Pocket PC - KOR.msi

위 순서로 했을때 별 문제 없었음. (설치일. 2007.5.10)

※ EVC 3.0
원인: 윈도우에서 한글 로그인명 사용해서 설치했을때...
증상: 빌드시 링크 에러 발생

에러메세지
"Linking...
CVTRES : fatal error CVT1102: out of memory; 40 bytes required
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
Error executing link.exe."

해결: 영문계정 또는 Administrator 계정으로 설치 할 것.

※ EVC 4.0
증상: Windows XP sp2 에뮬레이터 실행 안됨

에러메세지
"One or more files from the Emulator for Windows CE installation is missing.
Please reinstall Emulator for Windows CE and try again."

해결:
1. Click Start, click Run, type sysdm.cpl, and then click OK.
2. In the System Properties dialog box, click the Advanced tab.
3. Under Start and Recovery, click Settings.
4. In the Startup and Recovery dialog box, click Edit.
5. Disable PAE mode by removing the /pae option if it exists.
6. Remove the /noexecute option if it exists.
7. Add the /execute option.
8. On the File menu, click Save.
9. To exit Notepad, click Exit on the File menu.
10. To close System Properties, click OK two times.
11. Restart your computer.

boot.ini  파일을 수정하라는 말인데, boot.ini 파일의 원본은 다음과 같음.(파일 전체 내용이 아니라 수정할 부분만 발췌한 것)
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

원문 : http://support.microsoft.com/default.aspx?scid=kb;en-us;891667

RBMS(Rule Based Management System) 방법론

정의: 제어로직과 업무절차를 분리

Business Rule: 일을 수행하거나 처리하는 지식이나 규정, 규칙, 업무처리 방식
if ~ else 를 Rule 로 만들어 그 조건 설정을 현업이 쉽게 할 수 있게 하는 것.

Business Rule이 정형화되어 있지 않거나, 복잡한 경우에는 알고리즘 역시 복잡해지고, 이에 따라 프로그래밍의 난이도 역시 매우 높아져서, 일반적인 프로그램 방식으로 구현하기 어렵게 됩니다. 그리고 어렵사리 개발에 성공했다고 하더라도, 변경이 발생하면, 수정하기가 매우 어렵다.

BRE(Business Rule Engine)의 필요성이 여기에서 대두하게 됩니다. BRE는 말 그대로 Business Rule을 처리하기 위한 엔진입니다. 대부분의 BRE 솔루션은 Rule Base라고 하는 Business Rule을 저장하기 위한 별도의 저장소를 가지게 됩니다. 즉 Business Rule을 프로그램 소스에 업무로직으로서 구현하는 것이 아니라, 프로그램소스와는 별개로 독립된 저장소에 일괄 저장하는 것인데, 데이터를 어플리케이션의 소스 코드에 박아 두지 않고, 데이터베이스에 저장하는 것과 유사하다.

ex.)Blaze 소프트웨어사의 Blaze Advisor라는 개발도구

EHR(병원전자차트)
PACS(의료영상저장전송시스템)

u-병원 ex)휴대폰을 이용한 당뇨 체크 결과 전송

의료정보학(Medical Information)
XML - DB
Hospital1 ─── Hospital2
                 │
           데이터 교환

경북대학교 의료정보교실
polala@chol.com

oeminfo.ini
oemlogo.bmp
두 개의 파일을 생성 후 "c:\windows\system32" 폴더로 복사

①oeminfo.ini sample
[general]
Manufacturer=NH Information System
Model=Chief
[Support Information] 
Line1=농협정보시스템 개발사업부
Line2=e금융 모바일 뱅킹

※Support Information 은 지원 정보 버튼 누르면 나오는 정보

②oemlogo.bmp
※최대사이즈 200 x 120

참고URL:
http://www.dcinside.com/webdc/lecture/study_list.php?code1=20&code2=30&id=3833&s_mode=&s_que=

[HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft - Windows NT -  CurrentVersion]

RegisteredOrganization -> 회사 이름
RegisteredOwner -> 사용자 이름

프로그램 추가/제거'에서 'Windows 구성 요소 추가/제거' 탭
'MSN 메신저' 체크표시를 없애면 시작 메뉴의 프로그램 메뉴에서만 사라지고, 완벽하게 삭제X

완벽하게 삭제하려면, 내 컴퓨터에서 '폴더 옵션'에서 '숨김 파일 및 폴더 표시'를 활성화하고, C:\windows/inf/sysoc.inf 파일 오픈

"msmsgs=msgrocm.dll,OcEntry,msmsgs.inf,hide,7" 에서 "hide" 제거 'msmsgs=msgrocm.dll,OcEntry,msmsgs.inf,7'

이후 'Windows 구성 요소 추가/제거'에 메신저와 관계된 항목이 두 개 나타남.

이 두 가지를 함께 제거하면 시스템에서 MSN 메신저를 깨끗하게 삭제할 수 있음.

MERGE
No.36
No.42
This task can be done using the MERGE command. Correct syntax for the MERGE command
is MERGE INTO table1 USING table2 on (join_condition) WHEN MATCHED UPDATE
SET col1 = value WHEN NOT MATCHED INSERT (column_list) values (column_values).

Sub-Query
No.43

No.54
함수 사용법
SUBSTR, INITCAP, TRIM,

No.57
view - WITH CHECK OPTION -> INSERT or UPDATE 가능

No.64 BETWEEN 사용법
"WHERE deptno BETWEEN 10 AND 30"

애매모
No.71
No.73

No.77 Naming Rule

No.80
Nonequijoin

No.86
Constraint 사용법

No.89
equijoin

No.99 Outer Join

No.103
reuse the variable without prompting -> &&`

<Assertion>
assert (boolean expression) : assertion fails;
expression가 false일때 적용
assert 함수의 인자는 Local Variable을 쓸 수 없다

* public method의 argument check에는 사용할 수 없다. 단 non-public method의 경우는 가능
* Assert가 조건식이 false가 되면 이후 statement는 수행되지 않는다

assert 컴파일 옵션
>javac -java 1.4 $(FileName)
assert 실행 옵션
>java -ea $(FileNameNoExt)

Test King Dump 문제 풀이
A-9, 17, 23, 46, 53, 57, 69, 74

<AWT>
Frame
: DefaultLayout : BorderLayout

Panel
: Resing x
: 독자적 노출 x, 반드시 Frame에 부착되어 노출
: DefaultLayout : FlowLayout

DefaultLayout : Default로 센터
BorderLayout :

<Event Handling 하는 순서>
①GUI 구성
②Source(이벤트가 발생하는 곳)에 Listener를 부착
   button.addActionListener(☆);
③EventHandler를 구현

ActionEvent -> 감지 -> ActionListener(인터페이스)
MouseMotionEvent ->
WindowsEvent

Listener(=ReceptionDesk) -> 발생하는 이벤트 인지
actionPerformed(ActionEvent e); Listener에 의해 내부적인 호출

<IO>
키보드로 입력받은 데이타를 콘솔창으로 출력하는 Pattern
①입력스트림 생성.
InputStreamReader ir = new InputStreamReader(System.in);
BufferedReader br = new BufferedReader(ir);
②읽어들인다
String line = br.readLine();
③콘솔창으로 출력
System.out.println(line);

* 스트림은 가상 버퍼에 저장 했다가 한꺼번에 출력한다
* Auto Flush 기능

스트림을 close() 할때 자동으로 flush() 된다
출력이 잘려서 나오면 AutoFlash Enable과 flush() 호출 여부 확인할 것.

FileInputStream

Stream

ii)Server
①ServerSocket 생성 (ServerSocket은 클라이언트 Socket 접수 창구 역할)
ServerSocket server = new ServerSocket(port);
port range: 0 ~ 65534 (cf. 1 ~ 1024 reserved)
②client가 접속하면 socket을 리턴
Socket s = server.accept();

<차후과정>
SL-285 분산기술(DB연결)
SL-314 (HTTP를 이용한 분산 기술)
EJB(WAS 돌리는 분산 기술)

** 4일차 예정 교육

String/StringBuffer
<String>
"immutable 문자열 상수" - (변하지 않는)

==/equals()

  String s1 = new String("하바리");
①String s = new String("하바리");
  (s1.equals(s)) -> true 

②String s2 = "하바리";
  String s3 = "하바리";
  (s2 == s3) -> true 

System.out.println(5 + 5 + "하바리");
System.out.println("하바리" + 5 + 5);

※String 과 Non-Stinrg이 결합해서 String이 되는데, 숫자가 먼저오면 연산이 먼저 수행되고,
문자열이 먼저 오면 뒤에 연산이 수행되지 않는다.

<StringBuffer>
자주 변하는 문자열은 tring은 임시객체가 많이 생성되어 StringBuffer가 효율이 높다

** Test King Dump A 풀이
A-103. 135, 136, 137

<CommandLine>
public static void main(String[] args) {
 int grade = args[0];
 if (grade >= 90) System.out.println("A");
 if (grade >= 80 && grade < 90) System.out.println("B");
}
Run-Time에 인자를 받을 수 있도록 하는 메카니즘.
java Test args0 args1, ...
args[0] = args0;
args[1] = args1; 이다.

** Test King Dump 풀이
A-125, B-220

<Math>
바로바로 호출해서 쓰기 위해서 member method를 모두 static으로 선언
★★★
random() Method 호출
Math.random();

<Vector>
Vector v = new Vector(1, 50); // 초기 사이즈 : 1, 한번에 증가되는 사이즈 : 50
array와 다르게 resizing이 가능하다.
1. Object만 들어간다

<Wrapper class>
Primitive Data Type의 값들을 객체로 활용할 수 있도록 해줌.
byte -> Byte
sshort -> Short
int -> Integer
long -> Long
float -> Float
double -> Double
char -> Character
boolean -> Boolean

<Thread>
┌ Process : 실행중인 파일(~.class)
├ Thread : 하나의 Process 내에서 진행되는 세부적인 작업단위
│ ※Process와 Thread의 차이는 Data공유 여부
├ Multi-Tasking : Multi-Processing System(time-sliced방식) - 코드가 별도
└ Multi-Threading : Code, Data 공유(문제점 해결 -> 동기화)

Creating Thread
┌ ①class T extends Thread {
│ -> T t = new T();
└ ②class T implements Runnable {
 -> T t = new T();
    Thread tt = new Thread(t)
 -> public void run() {} 실행되는 Method

1. thread 객체 생성 Thread t = new Thread();
2. start를 P/G가 호출
3. 실행 가능 상태에서 run();을 받고 running 된다

의문점
1. who? JVM내의 Scheduler
2. why? 우선순위(1[low] ~ 5[default] ~ 10[high])에 의해서 호출됨

함수 정의에서 명시적으로 throws를 하는 것은 try ~ catch로 명시적인 처리를 해주면서 써야된다.

sleep : 자신 보다 우선순위가 낮은 쓰레드에게 양보
join : 특정 쓰레드가 수행될때 수행권을 보장받는 메쏘드. 다른 쓰레드가 끼어들지 못하도록...
InterruptedException 으로 감싸서 써야한다

public class MyStack {
 int idx = 0;
 char [] data = new char[6];
 public void push(char c) {
  data[idx] = c;
  idx++;
 }

 public char pop() {
  idx--;
  return data[idx];
 }
}

특정한 쓰레드가 수행을 다 끝내기전에 다른 쓰레드가 수행권을 가져감
->(Solution)동기화처리, Synchronized

i)synchronized(this) {lock을 걸려고 하는 bloack}
ii)return type 앞에 synchronized를 붙인다

<deadlock>
동기화 처리된 2개이상의 thread에서 발생
자신이 설정한 lock은 해제하지 않으면서 상대방이 lock을 해제하기만을 기다리는 영원한 교착상태

wait()
notify()
deadlock을 예방하기 위해서 동기화 처리된 쓰레드에서만 쓸 수 있다

Test King Dump 풀이
A-113, 114(?), 115, 116, 119

i)사용자정의 쓰레드 : ex. run() 함수
ii)데몬 쓰레드 : Demon 에서 호출되는 Thread, ex. main() 함수
setDaemon(true); // 이것을 만나면 main() method 호출함

** 내일 할 내용
<Assertion>

<Stream>

ch VII.
<Interface>
IS-A Relationship
<<interface>> ◁───── <<interface>>
※기능강화를 위해 사용

<Inner Class>
1. outer class 내부에서 선언
Inner i = new Inner();

2. outer class 바깥에서 선언
Outer o = new Outer();
Outer.Inner i = o.new Inner();

3. outer class 바깥에서 static 멤버 클래스 선언
Outer.Inner i = new Outer.Inner()

** Test King 덤프 A-82, 112 문제

ch IIX.
<Exception>
java.lang.Throwable
[Error(Serious한 손상), Exception(mild한 손상)]

* Throwable
    ┌ Error : Serious한 손상
    └ Exception : mild한 손상
        ┌ Runtime Exception: 컴파일 o, 실행 x(명시적처리x, 코드를 고치면 된다)
        │    ┌ ArithmeticException : 0으로 나눌때
        │    ├ NullPointerException : 생성되지 않은 객체 접근
        │    └ IndexOutOfBoundsException : 배열 범위 벗어날때
        └ IOException: 컴파일x(명시적처리o)

* Exception 처리 방법
①try ~ catch
try {
 // 예외 발생 가능 코드
} catch(IndexOutOfBoundsException e/* 발생한 Exception으로 잡는다*/) {
 // 예외가 잡혔을 때 필요한 코드
 e.printStackTrace();
} finally {
 //예외와 상관없이 무조건 실행할 코드
 // cf. 실행 안되는 경우
        i)System.exit(0);
        ii)Power Off
 iii)try ~ catch 실행 중 또 Exception 발생했을 때
}

sample.
i)예외발생x : try + finally
ii)예외발생o + 잘 잡았다 : catch + finally
iii)예외발생o + 못 잡았다 : finally
iV) return 했을떄 : finally

sample2.
try ~ catch 절 아래 statement가 수행 안될때.
i)못 잡았을때
ii)return될때

②throws
class A {
 public void go() throws ArithmeticException { // Exception을 던지니 go()를 호출한 곳에서 처리해라
  int i = 10, j = 0;                    // 원래 go()를 호출한 곳에서 명시적 처리를 해줘야 한다
  if (j == 0) throw new ArithmeticException();
 }
}

※ this("This is UserException..."); //this의 또 다른 기능 같은 클래스내에 또 다른 생성자 호출

** Exception에 관한 Test King 덤프 문제
A-12, 22, 29, 34(헷갈려 : try~catch 절 다음 statement 수행 여부), 38, 42 (throws 안쓴 예제), 56,
71(에러 발생시 try ~ catch절 무용지물, finally만 수행), 73(Exception 상속), 75(함정 문제),
88(이상), 90(중복 catch),

** Garbage에 관한 Test King 덤프 문제
35, 49, 76(객체 재생성)

<Collection Api> p.9-28
객체를 저장하는 방법론
* Collection : 가장 원시적인 방법으로 객체를 저장(순서x, 중복o)
       ┌ Set : "unique", 중복x, 순서x(기존에 있는 값은 저장x)
       │     ─ HashSet[class]:
       └ List : "ordered",순서o, 중복o(시작점과 끝점을 가지면서 환원형으로 자료 저장)
           ┌ Vector[class] :
           ├ ArrayList[class]
           └ LinkedList[class]

*Map : key - value 쌍으로 저장(순서x, key중복x)
    ─ HashTable[class]
        ─ Properties[class]

import java.util.*;
class SystemProperty {
 public static void main(String[] args) {
  Properties p = System.getProperties();
  Enumeration e = p.propertyNames();
  while (e.hasMoreElements())
  {
   String key = (String)e.nextElement();
   String value = p.getProperty(key);
   System.out.println(key + " : " + value);
  }
 }
}

ListIterator
+ hasPrevious()
+ previous()
양방향 검색

** 4일차 예정 교육

String
StringBuffer

*** 관련  Test King 덤프 문제
A-121(p.9-32)
B-244(natual order : 정렬된것 = SortedXXX), 245(???), 304, 305, 346

<Thread>

<Wrapper Class>

<Assertion>

<IO>

<AWT>

2일차

ch.V Arrays

<Array>
같은 데이터타입을 가지는 여러값들이 하나의 변수를 통해서 한방에 처리되는  것.

★★★ 3단계 문법
※syntax
①선언 -> int[] i; or int i[]; // "int[]" : 데이터 타입 "i": reference variable
 ★선언할때 사이즈를 명시하면 안된다
②생성 -> i = new int[3]; //
 ★ new 사용
 ★ new 다음 []에 size 명시
 new로 메모리 할당시 묵시적 초기화가 이루어진다.
 int[] i = new int[3];
 ★Memory 도식화

sample.
1. int 타입의 배열 생성(사이즈는 3)  -> int[] arr = new int[3];
2. 각각의 칸에 적당한 값으로 초기화   -> arr[0] = 1; arr[1] = 2; arr[2] = 3;
3. for 문을 이용해서 값들을 콘솔창에 출력 -> for (int i = 0; i < arr.length; i++) System.out.println("arr["+i+"]:"+arr[i]);

ch.VI Class Design
<Inheritance>
 [Sub, Child] class

1. Abstraction(추상화, 일반화)
다양한 Sub Class들 사이에서 공통적인 성질을 추출. 이 공통적인 성질을 일반적으로 갖는 독자적인 모듈을 윗단에 상정하는 것.
 [Super, Parent] Class

상속: 부모가 가진 모든것(member)이 자식에게 물려짐 + 자기자신만의 member 추가
  cf. Constructor는 member가 아니다

ex)
class Manager extends Employee{
 String dept;
}

class Engineer extends Employee {
 String tech;
}

<Polymophism> -> Method Overriding / Method Overloading
부모type으로 자식 객체 생성

Clothes 긴팔T = new Shirt(0, 0, 0);
부모type            자식객체

<Virtual Method Invocation의 원리>
1. Compile Time Type : 부모의 메모스를 호출
2. Runtime Type : 자식의 메소드가 실행
"상속관계의 오버라이딩된 메소드에서만 발생하는 원리"

<Method Overriding의 Rule> p.6-9
0. [전제조건] 반드시 상속관계의 두 클래스 사이에서 일어남
1. Method의 선언부는 모두 일치(리턴타입, 이름, 인자값)
2. More Modifier / Less Exception (부모 보다 자식의 Access Modifier가 More Modifier 이어야 한다)
3. 구현부는...{// } 반드시 달라야 한다
   > 즉 선언부는 같지만 Method의 기능이 달라졌기에 새로운 Method의 재탄생으로 봐야한다
   > "메소드 재정의"

<Overriding의 대표적인 사례>

Class Hierachy
<Object Class>
equals() - 객체가 같은지는 주소값으로 비교
toString() - 기본적으로 생략되어 있다, 그래서 주소값은 문자열로 출력된다

sample.
class 인어공주 extends 여자 implements 물고기

<Constructor> (마무리 - 상속관계에서의 생성자)

<Access Modifier>

<Exceoption>

<swich에 들어올 수 있는 자료형>
byte, short, int, char

<package>

ch.VII
<Interface>
기능중심
다중상속 지원
interface Flyer {
 [public] [static] [final] int x = 10; // public, static, final 기본적으로 생략되어 있음
 [public] [abstract] void fly();  // public, abstract 기본적으로 생략되어 있음
 void land();
 void fly();
}

추상적인 method들의 집합
interface를 상속받는 클래스는 모든 member method를 구현해주어야 한다
interface는 abstract의 set
abstract는 완전한 super 클래스로만 쓴다

구성요소
1. abstact Method
2. Constant

<static>
1. 객체를 생성하기 이전에 Memory에 올라간다
  -> 객체 생성하지않고 바로 사용해도 된다 ex) switchIt(4);  -> public static void switchIt(int x) { }
2. 생성된 객체들이 static Member를 공유
3. ex) static int j = 0; -> local로 선언될 수 없다
4. static Area 에서는 this 사용할 수 없다
5. final : "내가 마지막이야"
  final static 같이 쓴다(순서 바꿔서 static final도 가능) ex) final static int SIZE_MAX = 100; 상수를 지정하는 변수의 이름은 대문자로 한다
  final class : "상속 금지"
  final method : "overriding 금지"