[출처 : http://kr.blog.yahoo.com/comate119/44 ]
// 개발 분야 및 개발자의 분포 //
중소 규모의 벤처기업에서 펌웨어 제작을 위해 C나 어셈블리어, 퀵베이직등을 사용하여
프로그래밍을 하는 경우가 많았고, 특정 마이크로 칩을 사용한 프로그래밍에는
특정 회사의 PIC용 컴파일러를 사용되고 있다.
C++ 빌더와 VC++는 주로 하드웨어의 고속 제어용 프로그램을 개발하는 데, 사용되고 있다.
데이타 베이스 관련 사무용 프로그램에는 델파이, 파워빌더, 비쥬얼 베이직 등을 사용하여
구현한다. 비쥬얼 베이직 개발자가 많은 것은 툴 가격이 저렴한 영향이 크다.
델파이는 개발자 구룹에서 전문가 집단에서 사용하는 툴로 호평을 받고 있다.
필자가 구직하려고 보니, C언어쪽 개발자를 많이 찾게 된다는 사실을 알았다.
// 새내기의 개발 기업의 입사 후의 처세 //
기업내의 구성원 사이의 관계는 경쟁 관계이다. 자기의 스킬에 따라 승진, 급여,
구조조정 대상이 된다. 따라서, 동료직원 사이에는 수평선을 가지는 일정한
거리를 유지하는 것이 필요하다. 함부러 마음을 여는 것은 매우 위험한 생각이다.
대학내 동아리 처럼 선배가 인정으로 이끌어 주고 배우는 환상을 품어서는 안된다.
회사의 선배는 기업 이윤 획득이라는 공동 목표를 위해 필요한 만큼 조력을 받는 것
뿐이다. 내가 갖고 있는 각종 라이버러리를 회사 동료들에게 아낌 없이 공개한다고
해도 이러한 행위는 구조 조정시 아무 영향을 주지 않는다. 그 행위로 인사 담당자로부터
회사 기여도에 대한 평가를 받기는 무척이나 어려운 일이다. 그러나, CEO 주관으로
적극적인 지식정보시스템을 전사적으로 구축하려 할 때는 적당한 선에서 거기에
협조 할 필요가 있다. 모든 인간 관계가 그렇듯이 경쟁 관계에 있는 회사 동료라고
할 지라도 인간적인 관계를 맺는 것에 소홀이하지 않아야 한다.
구현 과정에서 적극적으로 회사 동료의 문제를 해결하여 주지 않더라도, 동료들과
어울리거나 대화하는 데 인색하지 않아야 한다.
인생 고민이나 자신의 약점을 의논 할 상대를 찾자면 동문 선배나, 회사 이외의
인생 선배나, 동호회 선배들로 부터 구하고 절대로 회사 동료들을 선택해서는 안된다.
필자가 개발자로서 비애를 느낀점은 프로젝트 때문이 아니라 자신의 개발 스킬을
위해 상대의 노하우를 다 빼냈다 싶으면 바로 해고 시켜버리는 악덕 업자들을 많이
보았다. 우리나라는 전체적으로 좁은 나라이며 개발자 간의 인맥도 매우 짧다.
따라서 특정 회사에서 깔끔한 일처리는 매우 중요하다. 나쁜 소문은 개발자 사회에
발을 딛지 못하는 결과를 가져온다.
개발자란 직업은 매우 고독한 직업이다. 그리고 잠이 부족한 직업이다. 이러한 이유는
프로젝트 메니저가 정확한 일정을 예측하지 못하고, 경영자는 개발기간 단축으로
인하여 인건비를 줄이려는 의도이다.
특정 툴과, 특정 분야에서 정통한 개발자라도 모든 개발 분야에서 전문가가 될 수는
없다. 그래서 자기가 취약한 분야가 있기 마련이며, 이것을 극복하기 위해서
오픈 마인드를 가져야 한다. 델마당 같은 동회회의 활동은 바람직하다.
// 사업계획서 작성요령 //
이 설명은 프로젝트 메니저나 프리랜서 개발자가 자영업을 하시는 데 도움을 드리고자
함이다.
1. 사업 계획서 목차
사업계획서 요약
기업 및 산업
사업 및 제품개요
시장 환경분석 / 상황분석
마케팅 계획
재무계획
조직 및 인적 자원 구성
고객 관리 계획
2. 기업소개
1). 회사일반개요
기업명
대표이사
사업영역
자본금
직원수
2). 기업의 비젼
3). 사업개념
비즈니스 모델
주요 사업 전략
향후 사업 전개 방향 :
1단계 : 고객 확보와 시장 점유율 상승
2단계 : 새로운 수익 사업으로의 확장
3단계 : 해외시장으로의 진출 모색
4). 주력 사업 아이템 소개
3. 사업 및 제품개요
1). 주요생산품
2). 주요사업 형태 및 비지니스 모델
3). 수익모델
4. 시장환경분석 및 상황
1). 국내시장 환경 분석 및 상황분석
2). 시장전망
3). 경쟁 업체 현황
5. 마케팅 계획
1). 경쟁우위전략
2). 고객창출을 위한 마케팅전략
3). 고객관리전략
4). 기업시스템 구축전략
5). 시장진입 및 성장전략
6). 예상 매출액과 시장 점유율 산정
6. 단계별 마케팅 전략
1). 시장진입전략
목표(사업목적, 제공서비스, 대상고객)
마케팅 전략(오프라인 마케팅 전략,온라인 마케팅 전략,온 오프라인 마케팅
2). 마케팅 운영 전략
고객세분화
목표시장선정(초반기,중반기,후반기)
포지셔닝
3). 고객 맞춤 마케팅 전략
초기 고객 확보
1:1 마케팅 전개
고객 데이타 베이스 활용
4). 고객유지 마케팅 전략
공유화전략
효율화전략(B2B 거래 마케팅,B2C거래형 마케팅,C2C 거래 마케팅,기업이미지홍보 마케팅)
7.경제성 분석
추정손익계산서=
평균구매액+예상구매고객수+매출원가율(30%)+(판매비/관리비=65%)+ 법인세(20%)
매출액+제조원가+매출총이익+판매비/관리비+세금 공제전이익+세금+순이익+현금흐름
8. 조직 및 인적 자원 구성
CEO(chief executive officer)
CFO(chief fiancial officer)
CTO(chief technological officer)
기술개발지원팀
마케팅홍보팀
비지니스 전략 기획팀
시스템구축/유지보수관리팀
9. 고객서비스
전화+방문+웹+전자우편+팩스=콜센터
// 방법론 탐구//
* 방법론의 프로세스
프로젝트 준비 - 환경분석 - 정보수집 - 집중분석 - 개선안 수립
프로젝트 준비 = 프로젝트 범위설정+요구분석+계획수립+사전정보수립
계획수립(구체적인 작업일정, 업무분장, 산출물정의, 작업방식,
문서화에 대한 계획수립)
환경분석 = 기술조사+관리환경분석
정보수집 = 관리정보수집
집중분석 = 구성분석+성능분석+장애분석
개선안수립 = 개선안 제시, 운영 및 관리체제 수립
// 개발자 직업의 딜래마 //
요즘은 평생 직장은 사라지고 평생 직업만 존재한다는 것을 여러분은 공감하실 것이다.
수 많은 경쟁력 속에서 살아 남아야하고 개발자나 기업 모두다 발전을 위해 새로운
변화에 도전해야만 한다. 새로운 인력의 재배치는 항상 옳은 것만아니다.
인간이란 조직 속에서 바라는 대로만 통제가 이루어지지 않고 언제나 변수가 존제한다.
자기 개발이나 고임금에 스카웃되어 심할정도로 직장을 바꾸는 결과과 항상 좋지
못했다. 보유 스킬은 많지만 기업이나 개발자 모두의 욕구를 충족시키는 경우가
드믈었다. 이러한 변화의 환경속에서도 묵묵히 저급여에도 직장을 옮기지 않고
묵묵히 성실하게 근무하는 직장인도 필요하다는 사실을 깨달앗다.
우리 개발자가 JOB을 찾아 해매이다 보면 개발자란 직업에 대한 미래에 대한 불안과
근본적인 생계 유지에 어려움이 많다는 것이다.
그래서 선배 개발자들이 제안하는 게, 많지는 않더라도 정기적인 수입을 올리는
아이템을 찾으라는 것이다. 그런데, 이것은 말처럼 쉬운일이 아니다.
비록 인기가 많고 성공적인 프로그램을 개발한다 할지라도 불법 복제를 하는 CD판매
업자들 때문에 수입에 한계가 있다. 이것을 극복하기위해 고안한 것들이 네트워크
게임류이다. 비록 크랙되어 널리 퍼진다하더라도 네트워크 접속을 해야하고, 많은
기능을 서버를 통하여 서비스한다면, 망 운영 측면에서 수익을 올리는 것이다.
지금, 필자는 취업을 위해 작년부터 준비해왔지만 지금도 해매고 있다.
안정적인 직장을 찾고 싶다.
// 프로젝트 메니저에 대한 몇 가지 오해 //
지금은 전산 전공자도 아니고 그리고 개발자도 아니고 그리고 코딩 능력을 갖춘 것은
아니지만 서울대 졸업하거나 토익 등 영어 실력이 좋으면 약 4주 정도의 교육을 시켜
프로젝트 메니저로 채용하는 것이 국내 개발 기업의 현실이다.
그럼 미국에서 생각하는 프로젝트 메니저란 무엇인가?
프로젝트 메니저란 코더로서 다년간 구현 능력을 쌓고 개발툴이나 로직등 개발 전
분야에 걸쳐 다양한 능력을 갖고 있어서 프로젝트의 위험성을 잘 알고 있고,
프로젝트 완료 기간을 정확히 예측이 가능할 정도로 안목이 생기는 사람을 말한다.
프로젝트 메니저가 되기까지 몹시 까다롭단 이야기이며 이들의 몸 값도 비싸단
이야기이다.
우리나라에서는 특정 시스템을 구현 할때 어려움을 겪게 되면, 프로젝트 메니저가
해결하는 것이 아니라, 이것의 구현 경험이 있는 개발자를 채용하여 해결하려한다.
그리고 이전 개발자가 잘하는 구현 기능에 대해선 그 개발자에게 다시 의뢰하려고
한다. 이미 해고된 이후에 그렇다.
// 프로젝트 메니저의 역할 //
* PMI 홈 페이지 : http://www.pmi.org
* 프로젝트 관리의 필요성
1. 비용과 투입공수가 착수시에는 낮으나 시간이 흐를수록 점점 높아지다가
종료시점에서는 급격하게 떨어진다.
2. 프로젝트 성공의 가능성도 처음에는 매우 높으나 점차 높아지게 된다.
3. 이해당사자들의 영향도도 처음에는 매우 높으나 점차 낮아지게 된다.
4. 변경비용과 에러수정노력은 시간이 흐를수록 점차 높아진다.
* 프로젝트 관계자
1. 프로젝트 관리자
2. 소프트웨어를 사용 할 사람이나 조직
3. 개발 인력을 파견 및 고용하는 용역회사.
4. 최종 사용자인 개인/조직의 관리자는 최소의 원가에 최대의 이익을 기대한다.
* 프로젝트 단계의 구분은 산출물 완료 시점으로 한다.
* 프로젝트의 처리요소
1. 입력물 : 문서나 문서화가 가능한 항목들
2. 도구와 기법
3. 입력물을 출력물로 변환하는데 사용되는 메카니즘
4. 출력물 : 프로세스의 결과로 산출되는 문서등
* 프로젝트 메니저가 해야 할 업무
1. 프로젝트 통합관리
프로젝트 개발기획 =
입력(다른 프로젝트 산출물,조직의 정책, 제한사항, 가정) +
도구(방법론, 프로젝트 관리 시스템) +
출력(프로젝트 계획서 )
프로젝트 기획의 실행 =
입력(프로젝트 계획서, 조직의 정책, 수정 요구 사항) +
도구(업무처리절차, 제품 기술과 지식 ) +
출력(작업결과서, 변경요구서)
요청사항처리 산출물 =
입력(프로젝트 계획서, 변경 요청서 ) +
도구(변경관리시스템, 추가 계획, 프로젝트 관리시스템 ) +
출력(프로젝트 계획변경서,변경요구서 )
2. 프로젝트 범위관리
프로젝트 범위 도입 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 범위 기획 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 정의 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 검증 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 범위 변경 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
3. 프로젝트 일정관리
프로젝트 실행정의 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 실행순서 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 실행결과 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 일정계획 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 일정통제 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
4. 프로젝트 비용관리
5. 프로젝트 품질관리
6. 프로젝트 인적자원관리
7. 프로젝트 의사소통관리
8. 프로젝트 위험관리
9. 프로젝트 진행관리
* 프로젝트 프로세스 = 착수 + 계획 + 실행 + 통제 + 종료
* 프로젝트의 관리
1. 통합관리 = 프로젝트 계획서 작성 + 프로젝트 수행 + 프로젝트 변경통제
2. 범위관리 = 프로젝트 요건파악 + 업무범위선정, 방법론선정 +
업무범위 확인 및 유지+ 업무범위 통제
3. 일정관리 = 공정계획수립(공정파악,스케쥴작성)+일정통제
4. 원가관리 = 원가산정 + 예산집행계획 + 합의 및 승인 + 경비 투입관리 +
예산집행통제(원가+인건비+경비)
5. 품질관리 = 품질보증계획수립 + 표준 및 절차수립 + 테스트계획 +
문서, 소스코드관리 + 결함보고
6. 인력관리 = 조직화 + 인력운영(교육,근태, 인사관리)+인력파견,해지,스킬등록,
7. 의사소통관리 = 의사소통절차수립+회의, 착수, 중간,완료보고+주간,월간,수시보고
의사결정요청,변경요청
8. 위험관리 = 위험파악 및 대응방안 수립 + 문제보고
9. 외주관리 = 외주계획수립,외주인력요청,외주인력선정,외주비용지급+외주인력평가+
외주업체평가+계약종료
// 인터뷰하는 요령 //
지금 설명하는 내용은 실무에서 사용된 내용이므로 그대로 사용하지 마시고
기업 특성에 맞게 수정하여 사용하시기 바랍니다.
1. 인터뷰의 준비
인터뷰의 목적을 명확화 할 것 .
인터뷰 대상자 확정후, 대상자 상사에게 사전 합의를 얻을 것
인터뷰 대상자의 상사로부터 인터뷰 대상자에게 책임,의무를 알릴 수 있도록 유도.
2. 인터뷰 요청 공문 발송.
반드시 먼저 전화 통화로 고객에게 인터뷰 계획을 의논한다음 즉시, 팩스로
문서 공문을 발송해야 한다.
전화 통화시 녹음기 사용을 양해를 구하고 고객의 허락을 받아야한다.
녹취하지 않음으로써 수 많은 분쟁이 고객과 발생한다.
사실 브로커와 계약시에도 녹취는 훌륭한 도구가 된다.
인터뷰는 프로젝트 메니저 혼자하면 안되고 2명이 한다. 한명은 인터뷰를
다른 한명은 협의 내용을 기록한다.
3. 인터뷰 요청 공문의 형식
To: 이름,제목,소속부서 Date: 오늘날짜
From:이름,프로젝트명
인터뷰일자,시간,장소
목적
가능하면 프로젝트 요약설명, 인터뷰 주제
인터뷰 목적을 기술하고 항목 기술함
토의하기를 원하는 토픽 리스트
특정 질문
의문 사항이 있으면 저에게 전화부탁드립니다.
고객의 질문 사항시 연락처를 남김
* 마케팅 이윤의 책정 : 제조 30% + 판매 10%
// 도움이 되는 글들 //
* 고난이도의 프로젝트를 실행하기 위해서는 특별한 기획 및 실행기법이 필요하다.
* 프로젝트를 주어진 시간과 예산 범위 내에서 실행하지 못할 경우
이와 관련된 단기적 및 장기적 비용을 정확하게 산출해야 한다.
* 일은 스스로 만들어 하는 것이지 주어지는 것이 아니다.
* 일이라는 것은 솔선수범하여 '적극적으로 해 나가는 것'이지 결코 수동적으로 하는 것이 아니다.
*'큰 일'과 맞서라. 작은 일은 자기 자신을 작게 만든다.
*'어려운 일'을 목표로 하라. 이것을 이루어 내는 곳에 진보가 기다린다.
* 일단 맞붙으면 '놓아주지 마라' 목적을 완수할 때까지는 죽어도 놓아주지 마라.
*'일을 끌고 가라' 끌고 가는 것과 끌려 가는 것은 엄청난 차이가 있다.
* "계획"을 세워라. 장기적인 계획을 갖고 있으면 여유와 희망이 생기고 인내심도 갖게 된다.
*'자신'을 가져라. 자신이 없기 때문에 일에 대한 추진력도 끈기도 그리고 성의마저 없는 것이다.
* 두뇌회전은 언제나 '풀 가동'으로 하라. 한 치의 빈틈도 있으면 안 된다.
* 마찰을 두려워하지 말라. 마찰은 진보의 어머니요, 적극성의 비료이다.
마찰을 두려워 하는 자는 비굴하고 뒤쳐지게 된다.
// 프로젝트 완료 보고서 작성 요령 //
지금 설명 드리려고 하는 내용은 실무에서 사용된 내용이므로 그대로 사용하시면
안되고 독자가 알맞게 커스텀마이징하면 된다.
1. 기본 프로세스 흐름도.
2. 코드구성 : 시스템에 사용된 코드 목록.
3. 파일구성 : HDD상의 실제 디렉터리 이름 및 파일명 목록표
4. 테이블 구조. : E-R 다이어그램도
필드명칭+자료형태+NULL유무 형식으로 작성
5. 화면설명서
6. 사용자 매뉴얼.
7. 프로그램 소스코드.
8. 개발일정표 : 월별 개발일정표
9. 개발비 산정표.
프로그램 스텝 = 분류+소스코드파일명+세부기능+라인수 형식으로 작성
디자인 : 이미지(그래픽),
난이도+소스파일명+세부기능+총 수량 형식으로 작성
* 개발용역비 = 소프트웨어개발비 + 시스템운영환경구축비 + 데이터제작비 +
자료입력비 + 정보전략계획수립비
* 소프트웨어개발비 = 직접인건비 + 직접경비 + 제 경비 + 기술료
* 직접인건비의 산정 : 프로젝트형태 + 개발언어 + 규모 + 적용대상규정 +
정보처리형태에 따른 보정계수 산출
// PM직의 승낙 //
재무 구조가 튼튼한 기업에서 근무 중인 개발자가 PM직을 권유 받으면 승낙하시기
바란다. 일반적으로 PM직은 고도의 전문성을 요구한다. 그러나 이러한 PM직은
외국계 개발회사에 해당되는 일이고, 일반 기업에서는 명확한 기준이 없고
애매모호하다. 즉, PM직의 원래 기능보다는 거의 인력 관리 수준에 머물러 있다.
채용하고 짜르고 악순환이다.
// 윈도우 운영체제의 보안 //
윈도우 운영체제는 우리에게 경이의 대상이다. 너무 친숙해서 그런지 모른다.
hacker,decker,cracker 등 수 많은 사람들의 표적이 되었다.
아무튼 지금은 수 많은 보안 패치가 이루어 졌지만, 항상 보안 패치보다 침입이
앞서고 있다. 기상천외한 방법으로 윈도우 운영체제를 공격하지만 이 방법이란게
일반화 되지 않고 특수한 계층의 사람들만 알고 있다가 이것이 많은 사람들에게
알려지면 패치가 되어지곤 했다. 아마도 그 중의 하나가 윈도우 98의 공유 폴더에
대한 암호 해독이 그것이다.
요즘에 특이한 방법으로 윈도우 운영체제를 공격하는 방법으로는
님다 바이러스를 이용한 침입,
자사의 홈페이지 로그인 하는 유저들 대상으로 접속 클라이언트의 로그인 창을 클릭
햇을 때 클라이언트의 보안을 해제하는 방법,
스파이웨어 CuteFTP, FlashGet, GetRight, 또는 RealPlayer 등의 루트를 이용하여
재 침입하는 방법...
애플릿, 인터넷 익스플로러의 자바 스크립트, 비쥬얼 베이직스크립트를 이용한 침입방법,
그리고 보안 패치가 되었지만 쿠키를 이용한 침입이 유행하고 있다.
// 공장자동화와 산업용기기의 제어 //
공장 자동화 뿐만 아니라 각종 산업용 기기의 제어용 프로그램을 개발할 경우가 종종
생긴다. 주로 수요처는 자본금 1억 이하의 벤처기업이다.
혹은 특허 제푼의 시제품 제작을 위해 제어용 프로그램을 필요하게 되었다.
이 기업들은 개발자에게 개발 비용을 지불 할 능력은 없지만 산업용 기기 제어용
프로그램 개발이 필요하게 된다.
우리 개발자들도 생계를 위해서 이 분야도 공부해야 한다.
아무래도 전기/전자 전공자에게 유리하다 할 것이다.
동전교환기, 계수기, 바코드 프린터, 마우스, PLC 등등 많은 기기들은 주로 베이직,
어셈블리어, C언에 의하여 컴파일 된다. 베이직은 우리가 아는 비쥬얼 베이직이
아니라 초창기의 Z8086/8088A CPU를 위한 베이직으로서 예를 들면 MS의 QUICK BASIC
을 사용하면 매우 정교한 제어용 어플을 맹글 수 있다. 컴파일 옵션을 잘 사용하면
실행 파일의 크기를 많이 줄 일 수 있다. 음, 컴포넌트 기반이 아니면서 어셈블리어
수준으로 코딩이 가능하며 유지 보수하기도 쉽다.
베이직으로 게임의 종류인 아케이드를 코딩하신 경험이 있는 분들이라면 많이 공감하실
겁니다.
그러나 요즘은 마이콤 개발의 추세와 고속 제어 처리를 위해선 어셈블리어로
코딩하는 경우가 많으며 요즘은 C로 코딩하는 경우가 많아졋다.
많은 경우에 CPU 롬에 HEXA CODE를 기록 할 때, 롬 리이더가 읽지 못하게 혹은 개발
기술을 보호하거나 컴파일러 회사에 라이센스료를 지불하지 않기 위해 암호화하는
경우가 많아졌다.
// NL 차트의 이해 //
업무 분석 단계에서 사용된 도구는 여러 가지가 있다. 지금도 FLOW CHART(흐름도)를
사용하는 경우가 많다. 그러나, 조직화된 개발 팀에서는 일반적으로 MS의 VISIO2000를
사용하여 DFD(DATA FLOW DIAGRAM)를 그리고 이것을 통하여 개발자간 의사 소통을 한다.
그러나 이것도 프로젝트 일정 때문에 잘 지켜지지 않는다.
설계 없이 곧바로 구현하는 경우가 많고, 보고서 및 설계서, 제안서등은 거꾸로 구현이
완료된 뒤에 만들어지는 경우가 많다. 이것은 분명이 잘못된 것이다.
미국이나 인도의 개발자들은 프로젝트 메니저의 개발 설계서를 보고 의견을 나누거나
독특한 도구를 사용한다. 그럼, 실무에서 사용하는 이 도구는 무엇일까?
독자는 매우 궁금해 할 것이다.
이것을 설명드리기 전에 마인드 맵을 들어 보셨는지? 이것은 우리의 맘 속의 생각을
빠르고 용이하게 기술하기 위한 기법으로 서점에 가보면 관련 서적들이 많이 있다.
이것을 약간 응용된 것으로 먼저 핵심 시스템을 박스로 묶고 박스안에 시스템 명칭이나
고려 대상을 적은 다음에 이 박스에서 수직선을 그어 내린다. 마치 일정표 처럼
만들어 지는 데 수직선 사이에는 흘러가는 정보나 방법등을 기술한다.
글로 설명해 드리려하니 얼른 감이 잡히지 않을 것이다.
대형 팀 프로젝트 수행 경험이 있는 분이나 외국계 개발 회사에 근무한 경험이 있는 분은
곧 바로 제가 무엇을 설명하고 있는지 이해 할 수 있을 것이다.
편의상 필자가 이 도구를 NL 차트라고 이름을 붙였으나, 사용해 보면 여러모로 유익하다.
정보공학 산출물을 만드는 데도 매우 유익하다.
// 국내 소프트웨어개발기술의 동향 //
정확한 통계를 제시하지 못하지만 그 동안 경험으로 국내에서의 소프트웨어 개발 기술은
주로 LG-EDS TEAMS과 삼성SDS TEAMS 기술이 산재하여 있다는 것을 알 수 있다.
물론 대형 SI 업체의 기술이라 업체간의 협약으로 노하우 비밀유지 계약 때문에 일반
개발자에게 알려지는 것은 불가능한 일이다.
추측해 보면 상기 개발회사 출신의 개발자가 고용 안정이 되지 않아 자주 자리를
옮기는 것으로 풀이된다.
지금은 IMF 이후와 KOSDAQ 붐으로 인하여 개발 팀들이 많이 해체되어 버렸지만,
소프트웨어 개발 기술이 척박한 이 땅에 땀을 흘린 분들을 생각하며
유솔로몬이 끝없이 존경하는 마음을 표한다.
초창기 우리 개발자는 전산실의 서버 관리자로서 단순 업무 때문에 개발에 필요한
시간이 생겼지만 지금은 옛날 일이 되어 버리고 많았다. 대신에 일반 잡무가 개발자에게
부여 되었다. 기획, 일반사무, 하드웨어 유지보수 까지 등등...
고급 개발자로서 C나 어셈블리어로 펌웨어 즉 장치 구동드라이버 소프트웨어 개발하는
경우가 있는 데, 국내에서 20여명 안팍으로 추산된다. 이 분들의 동향은 주로 대기업이나
프리랜서, 혹은 자영업하는 경우가 있었다.
아주 특이한 경우를 보았는 데, 게임을 개발 할 때, 컴파일러를 사용하지 않고 HEXA 에디터를
사용하여 직접적으로 기계어로 코딩하는 경우를 보았다. 필자로서는 이해가 가지 않는 일이었다.
또 한가지는 유닉스 기반의 오라클 데이타베이스를 shutdown하지 않고 손상된 레코드를 백업을
사용하지 않고 그 손상된 모듈을 기계어로 코딩하여 붙이는 경우가 있었다. 경이로운 일이다.
// 최고 경영자가 삼성SDS 출신이거나 삼성SDS에서 분사한 벤처기업에 취업하려고 할때//
프로젝트 메니저로서 구인 공고를 하는 경우에는 프로젝트 메니저 자신에게 매우 유용하다.
일반 직원이 회사 인사 정책에 관여하는 경우는 매우 드물고, 회사에서 자신의 위치가
인사에 관여 할 정도가 되면 자기 개발에 매우 유용하다.
즉, 프로젝트 메니저란 위치가 회사를 위해서가 아니라 자기 개발을 위해서 매우 중요하다.
그 이유는 입사 지원한 고급 개발자중에서 특정 분야에 대한 개발 인력의 인적 사항을 확보가
가능하고, 프로젝트 메니저 스스로에게 취약한 기술 분야에 대하여 인터뷰를 통하여
동종 경쟁 업체의 기술을 빼낼 수도 있고, 광범위한 테크니컬 로드 맵을 그릴 수 있다.
그리고 정보 통신 흐름을 파악 할 수 있는 기회를 제공한다.
그런데 특이한 점은 이러한 사항을 최고 경영자는 모르는 경우가 많다는 것이다.
다음 사항은 여러 분이 프로젝트 메니저로서 입사 지원할 때 준비해야 할 일반적인 사항이다.
예시로 회사 규모로보면 직원 수 100명에 코스닥 등록업체인 경우로 설정했다.
여러분도 잘 아시는 바와 같이, 삼성SDS는 매우 보수적인 기업이다.
보수적인 기업이라 함은 공무원 사회와 정신적인 기조가 비슷하다는 의미이다.
물론 사무적인 기조는 최첨단이다.
삼성SDS 출신의 최고 경영자는 인사 문제에 있어서 매우 보수적인 성향을 따른다.
경영자 스스로 그것을 탈피하려 하지만 뼈속 깊이 잠재적으로 그 사상이 심어져 있다.
아마도 삼성SDS 사내의 인력양성 프로그램 영향으로 보인다.
삼성SDS 출신의 CEO는 인력 채용시 4단계 이상의 까다로운 절차를 거친다.
1. 서류전형
요즘 추세가 개발자의 사내 양성이 아니라 현장에 곧바로 투입 할 수 있는 인력을
찾기 때문에 실무 경력자를 우선시한다.
프리랜서인 경우에는 인력파견업체의 사장님이나 최종 사용자의 추천서를 받아두는 게
좋습니다.
추천서에는 추천인의 연락처를 명기하여 구인 업체에서 확인이 가능하도록
합니다.
2. 직무적성검사(프로그램머 직무능력검사)
삼성SDS 출신의 CEO는 이것을 매우 중요하게 생각합니다.
비록, 비경력자라도 적성검사에서 좋은 점수를 받게 되면 채용하는 경우가 많습니다.
적성 검사 방법으로는 현장에서 얻는 실시간 데이타 또는 표를 보구 이 자료를 이용하여
역으로 정보 가공 및 분석, 추론을 할 수 있는 능력을 평가합니다.
이것은 일반 개발자라면 쉽게 습득 할 수 있습니다. 연습하면 향상 됩니다.
즉, 전산 수치해석을 의미합니다.
이 검사는 한국SHL에 의뢰하여 실시하므로 한국SHL 홈페이지를 방문해 보는 것도
유익한 일이다.
삼성SDS에서 이것을 중요하게 생각하는 이유는 아더엔더슨 컨설팅 및 SAP등 외국계
개발회사에서 객관적 평가를 위해 이러한 질문지 도구를 사용하기 때문이다.
3. 면접
삼성SDS 출신의 CEO는 인사 문제에 대하여 정형화 되어 있습니다. 따라서 매우 보수적인
성향을 따릅니다. 첫 인상, 발표하는 태도, 성격, 입사햇을 때 다른 사원간의 인화력등을
살펴 봅니다. 역시 임기응변이나 융통성이 강한 것을 선호하기도 합니다.
4. 연봉
입사 지원자가 사규에 따라서 급여를 받겟다 하더라도 희망연봉을 물어봅니다. 아마도
급여로 인한 불만을 사전에 감쇄하려는 의도입니다. 사전에 입사하려는 회사를 탐방하여
급여에 대한 초급 급여, 인사제도에 대한 자세히 조사를 할 필요가 있습니다.
뛰어난 개발 능력을 보유하고 있더라도 고액 연봉을 요구하는 경우에는 수용하지 않는다.
5. 비지니스 영어
삼성SDS 출신의 CEO는 영어 실력을 매우 중요하게 생각합니다.
해외출장 갔을 때, 호텔에 체크인, 체크아웃하는 방법, 호텔 프런트에 남겨진 전화 메시지
독해하는 방법,정보통신 기술적인 사항을 미국인 개발자와 직접 논의할 정도의 회화구사능력
6. 기타사항
실제 채용 의사가 없으면서 프로젝트 위험 때문에 비상시 구인하기 위한 인적사항을
수집하는 경우도 상당히 많다.
사내 아이템이 동종 업계인 경우엔 상대편 회사의 기술을 빼내기 위한 인터뷰로
활용하는 경우가 많다. 이것은 제가 입사 지원시 저와 함께 집단 면접을 보신 분에게
상대 경쟁 회사의 규모, 시스템 구성에 대한 예리한 질문이 있었다.
// 면접시 예시문제 //
1. 당신이 전 직장에서 퇴직하는 사유가 무엇인가요?
2. 당신이 CEO라면 프리랜서를 어떻게 관리하겠습니까?
3. 3분동안 자기 소개를 해보세요?
4. 3분동안 자기 PR을 해보세요?
5. 영어로 자기 소개를 해보세요?
6. 영어로 컴퓨터의 보안에 대한 기술 사항을 외국인과 함께 논의 가능합니까?
7. 희망 연봉은 얼마입니까?
8. 지방으로 파견냈을 때 근무 의사가 있습니까?
9. 지금 발령을 낸다면 언제 출근이 가능합니까?
10. 당신은 연령이 많은 데, 나이가 적은 상사와 인화문제,
개발 과정에서 사고의 유연성에 대하여 어떻게 생각하는가?
11. 당신이 우리 회사에 입사한 동기는 무엇인가?
12. 당신은 지금 직장에 근무 중입니까?
13. 우리가 당신을 채용한다면 언제 근무가 가능합니까?
14. 당신의 현주소는 어디입니까?
// 개발 아키텍쳐의 개념 //
tier : 어플리케이션 아키텍쳐를 논리적으로 구분하기 위해서 사용하는 용어.
2-tier 아키텍쳐 : 클라이언트/서버 어플리케이션의 하나. 두 개의 tier로 구성.
주고 받는 것 : SQL, FTP, HTTP
클라이언트 : GUI(Graphical User Interface)를 담당. 비지니스 로직을 처리
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
3-tier : 클라이언트 : GUI(Graphical User Interface).
Middle-tier : 비지니스 로직을 처리.
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
TP (Transaction Processing) Monitor : Tuxedo(BEA), Encina(IBM)
CORBA (Common Object Request Broker Architecture)
OTM(Object Transaction Monitor) : M3(BEA사), OrbixOTM(Iona사),
Visibroker ITS(Inprise사), TPBroker(Hitachi사)
// 어플리케이션 서버의 정의 //
분산 객체, 분산 트랜잭션, Component 모델을 제공함으로써 N-tier 구조의
어플리케이션을 쉽게 개발하고 운용할 수 있도록 해 주는 소프트웨어
플랫폼이라고 할 수 있다.
어플리케이션 서버에서 어플리케이션은 보통 Component로 개발되기 때문에
어플리케이션이라는 용어 대신 Component라는 용어를 직접 이용하는 경우가 많다.
================================================================================
*********************************************************************
[입문자를 위한 ] 미니프로젝트실무
*********************************************************************
이 자료는 지적재산권 보호를 받습니다.
개인이 개발과 관련된 연구 목적 또는 자기 개발의 목적으로 활용이 가능하지만
무단으로 배포하거나 타 게시판에 게시하지 못하며,
상용이나 영리를 목적으로 인쇄 및 배포를 금합니다.
이 글 내용의 일부분 또는 전체의 무단 전제를 금합니다.
----------------------------------------------------------------------
이 글은 대한민국의 지적재산권, 저작권 관련법의 보호를
받습니다.
이 글을 델마당, 한국델파이개발자연합, 델파이코리아 등의 게시판에
게시했다하여,
상업적으로 이용 또는 부분 및 전체 복제를 허여하는 것은 아닙니다.
즉, 묵시적으로 허용하는 것이 아닙니다.
이것은 자유 게시판에 공개된 글이라도 상업적으로 이용 가능하다는 의미가
아니며, 어떠한 경우라도 상업적으로 이용이 불가함을 알립니다.
이 글의 저작권은 유 솔로몬에게 있습니다.
Copyrights,2002,By ds4byw, All rights reserved.
초 판 : 2000. 7. 6.
최종수정 : 2002. 6. 26.
유솔로몬 (ds4byw@hanmail.net" target=_blank>ds4byw@hanmail.net Tel 011-645-9006)
******************************************************************************
이 문서는 텍스트 포맷이며 윈도우 보조프로그램 워드패드에 최적화 되어있습니다.
" 이 문서의 수정판은 델마당 개인게시판 메뉴에서 유솔로몬 게시판에 게시됩니다."
http://www.delmadang.com/solomone
******************************************************************************
유 솔로몬은 이 글 내용 및 기법을 이용하여 제작한 프로그램이 데이타 손실 및
파괴에 대하여 민형사상 책임지지 않으며 사용자의 책임임을 알립니다.
따라서,유 솔로몬은 어떠한 경우에도 귀하에게 보증을 드리지않으니 사용에
주의하시기 바랍니다.
이 글을 대한민국에서 소프트웨어 개발을 하시는 이름모를 개발자님들과
이미 늦어버린 나이에도 개발 기술을 취득할 기회를 허락하여 주신 존경하는
박사님들과 얼굴은 모르지만 전화를 통하여 아낌 없는 도움말과 조언을 주신
한국과학기술원 연구원님들 그리고 필자에게 실무에서 아낌 없이 지도 편달을
주신 개발팀장님들께 충심으로 감사 드리며 바칩니다.
********************************************************************************
대한민국의 소프트웨어 개발 분야의 진흥이 되길 빌며...
델파이란 가공할 만한 고성능의 툴에 아낌 없는 찬사를 보내며 ...
"우리는 델파이란 툴을 사랑합니다."
델파이란 툴을 개발한 볼랜드의 델파이 개발 TEAM에 겸손한 마음으로 경의를 표한다.
델파이가 설치된 컴퓨터에서 델파이를 실행한다음 about 메뉴를 클릭한다음
alt키를 누른 상태에서 TEAM이라고 타이핑 하면 TEAM 이름이 나온다.
델파이코리아 만세! 델마당 만세! 한델만세!
*********************************************************************
// 들어가는 말 : 이 글을 쓴 동기 ~ //
필자는 수 십년 동안 컴퓨터와 함께 하면서 직업적인 프로그램머가
되려고 하면서 기업에서 실무 경력자를 선호하는 현실과 벤처기업에
발자취를 남기며 실무 현장에서 평소에 느낀 점이 많았다.
개발자들이 현장 실무에서 느끼는 고뇌와 최악의 근로 조건에서 처절한
자기 자신과의 싸움 그리고 소프트웨어 공학과 정보공학의 개념에
낮설은 우리 나라에서 이치에 맞지 않는 역현상들이 많이 발생하여
이러한 점을 안타깝게 생각하여, 수 많은 사람과 접촉하고 인터뷰한
결과를 기술하는 마음으로 이 글에 담았다. 이의가 없는 한,
아더엔더슨 컨설팅 회사와 SAP라는 회사가 보유하고 있는 노하우가
소프트웨어 개발에 있어서 훌륭한 길잡이가 됨을 의심하지 않는다.
이 글을 길잡이 하여 초등학생으로 부터 대학교수 까지 손쉽게 소프트웨어
개발이 가능하길 바라며 지적재산인 소프트웨어 분야가 기술적으로
다른 나라에 종속되지 않기를 바라는 마음 간절합니다.
짧은 실무 경력이지만 초보 델파이 개발자에게 도움을 드리기위해 이 글을 씁니다.
초보자가 초보자를 위해 글을 쓰는 일은 부담되는 일입니다.
이 글은 초보자를 위해 쓰여지지만 표현이 난해하고 어려운 용어가 사용 될 수 있으며,
주관적인 생각들이 강하므로 이 글에 대한 댓글이나 질문은 정중히 사양합니다.
이 글과 관련하여 절대로 연락하지 마세요.
어떠한 질문이나 메일, 문의 등을 사절합니다.
필자는 이 글을 열람하시는 분들께 답변할 의무는 없으며,
귀한 시간을 거기에 투자해야 할 어떤 이유가 없습니다 .
이 글의 내용 중에 특별한 경우를 제외하고는 특별히 예시를
않더라도, 사용되는 용어는 각 회사의 등록상표임을 밝힘니다.
그리고,이 글을 열람하시는 독자분들께 연재 약속을 드리지
못합니다. 다만, 개인적인 흥미로 틈틈이 글을 쓰려고 합니다.
필자는 1985년 고3부터 프로그램밍을 취미로 처음 시작했으며, 공식 경력은 4년
비공식 실무경력 5년 이상의 개발자이며 현재는 IT 분야의 컨설턴트입니다.
제 나이가 우리나라 개발 문화에서는 황혼기라고 할까요.
항상 프로그램밍에 들어가면,필자가 실무 경력자이지만 착잡한 기분을 감출 수가
없습니다..
이 글의 만약 독자분이 30대이시고 마땅한 직업이 없어서 프로그램 개발에
도전하려고 한다면, 필자는 강경하게 만류하고 쉽습니다.
여러 가지 이유로 개발업체에서 고연령 개발자를 채용하는 것을
꺼리고 있으며 고등학교 혹은 대학교 졸업을 한 전산 전공자를
선호하고 있으며 21세 이상 30세 이하가 적정 연령인 것 같습니다.
많은 분들이 그렇듯이 30세 이상인 분은 전업이나 장래에 대한
계획이 필요합니다.
이 글에서는 정보공학에 대해서는 언급을 전혀 하지 않습니다.
정보공학이 실제로 단순한 코더 보다는 오히려 부가 가치가 높은 것인지도
모릅니다.
필자는 가난한 개발자입니다. 필자가 부자이고 넉넉한 마음으로
이 글을 쓰고 있다면 마음이 편했을 텐데 웬지 서글픈 마음이 드는 것은
왜? 일까요?
개발자가 되고 싶다고 해도,간단한 업무용 프로그램을
만들려고 해도,초보자에게는 모든 것이 힘들기만 합니다.
개발 기술은 개발 회사에서 보호되어 있고 시중의 참고 서적들은
도움이 되지 않습니다. 참으로 이상한 일입니다.
개발자에 입문한지가 어제 인듯하더니 순식간에 세월이
흘러가 버렸습니다. 어느 순간, 직업적인 개발자가 되어버린 모습에
스스로 놀라울 따름입니다.
하지만, 아직도 배울게 많고, 필요한 기능을 신속하게 구현 할 수
있는 능력을 갖도록 노력하려고 합니다.
이 글에 대한 조회수가 1000회가 넘은 것에 대하여 감사를
드리는 맘입니다. 물론,1년이란 기간 동안 조회한 숫자이지만 ,
허접한 글에 대하여 여러분들이 관심을 가져 주셔서 필자로서
고마울 따름입니다.
이 글은 현업에서 실무 중 느낀 점을 간략하게나마 기술한 것이므로
주관적인 생각이 강하고 객관성이 많이 결여 되어있는 것은 사실이지만
개발 전 분야에 걸쳐서 어려움이 많다는 것을 알려 드리고 싶습니다.
일반인들은 소프트웨어가 담긴 CD 한장에 1-3만원 정도란 것이 각인
되어 있습니다.
보통 불법 소프트웨어 카피본에 1만원에 거래되고, 정품 소프트웨어 가격이
저렴할 경우에는 8만원에서 15만원 사이입니다.
따라서, 소프트웨어 개발 비용이 일천만원 이상을 한다고 말하면 도무지
벌린 입을 다물지 못합니다.
무슨 CD 한장에 일천만원 까지 하냐고...사람을 놀리지 말라고...
여러 소프트웨어 개발 회사의 기술 수준은 차이가 있습니다.
아직까지 그것들과 비교해서 이 글에서 소개한 개발 기법에 대하여
강한 긍지를 가지고 있습니다.개발자는 철저한 생존을 위한 몸부림으로
항상 최적화된 개발 기법을 찾아야합니다.
비교적 팀 프로젝트에서는 시간적인 여유를 가지고 진행 할 수 있으나
프리랜서인 경우엔 모든 작업을 혼자 해야하기 때문에 최적화된 기법을
찾기에 힘써야 하며, 프로젝트 시작 전에 라이브러리가 미리 준비 되어
있어야 합니다.
라이브러리는 공통으로 사용된 함수의 모임이나 콤포넌트, 재사용 가능한 것을
말하며 개발 시간을 단축시키고 효율적으로 코딩을 하기 위함입니다.
******************************************************************************
개발된 소프트웨어의 이상적인 국내에서 판매 카피 수는 50만 장입니다.
******************************************************************************
비록, 개발 비용을 회수 못한다 하더라도 50만 카피는 브랜드로서 성공하신
것입니다. 여러분이 프로젝트 메니저 위치에서 이 글을 접하실 때면
필자의 의견에 동의 하실 겁니다.
이제 뜻 깊은 성탄절이 다가옵니다. 필자가 델파이라는 툴을 알기전에 무척이나
고생을 많이 했습니다. 뉴스 구룹에 의지해서 해답을 찾으려고 했던 기억이 납니다.
그리고 특이한 사실은 영어의 독해력이 개발자의 개발 기술과 자기 개발에 도움이
된다는 사실입니다.
===========================================================================
이 글에 소프트웨어 공학과 정보 공학에 대한 내용을 기술하기 위하여
문서명을 델파이프로젝트실무에서 미니프로젝트실무로 변경합니다.
현재 문서에 자바, 리눅스, MySQL, JSP에 대한 내용을 추가하려 한다.
그리고, 틈틈이 제품기획과 상품기획, 마케팅에 대한 내용을 담아서
프리랜서 여러분이 자영업 하시는 데 도움이 되려고 한다.
이러한 기술 문서가 의도하는 대로 우리 모두에게 유익했음 한다.
이 글을 쓰는 시점에 제가 대형 소프트웨어 업체처럼 큰 수익을 얻었으면
조으련만 그렇지 못하여 못내 아쉬움이 많다.
개발자로 있으면서 느낀 것이지만 개발자에게 도덕적인 면이 많이 요구 되는
것 같다. 데이타베이스를 다루다보면 개인 신용정보나 개인정보들 개발과
관련된 영업기밀 등을 누설하지 않아야 한다. 또한 해킹에 대한 역추적을
위하여 본의 아니게 타 전산망을 침투하는 경우도 발생한다.
현재는 급변하는 개발기술 발전에 따라 신 개발기술을 습득해야만 하는
개발자들에게는 많은 융통성을 필요로 한다.
많은 분들이 소프트웨어 개발관련 사업계획서 작성상의 어려움을 호소하고
있고, 정보공학 및 소프트웨어공학에 대한 문의가 많이 와서 여기에 다루고자 한다.
그러나, 이 문제를 다루긴 위해선 지적재산권 문제를 고민을 해야한다.
국내에는 많은 대형 SI업체들이 존재하고 합리적으로 개발 기술을 문서화하는
방법론이 거의 대부분 미국의 아더엔더슨 컨설팅과 여러분에게 유명한 SAP의
자체적인 노하우이기 때문이다.
아무리 개량하고 발전 시켰다 하더라도 상기의 두 회사의 개발 기법을 벗어나지
않는다. 상기의 개발기법을 이용하기 위해선 천문학적인 비용이 소요된다.
그래서 컨설팅을 위해선 기업의 연간 매출이 100억 이상이 되어야 효율적으로
이용 할 수 있다. 정보공학을 고려하면 심지어 오라클의 개발 방법론 까지도
전체적으로 똑 같지는 않지만 상기한 회사의 개발 방법론이 요소요소에서
비슷하거나 공통적인 요소로 인식 할 수 있다.
그럼 천문학적인 비용을 부담하지 않고 정보공학 프로젝트를 수행하는 방법은
없을까?
필자가 여기에 고심하다 중요한 사실을 알게 되었는 데 바로 국제규격이다.
국제규격은 표준화 하는 대신에 해당 기업에 라이센스료를 지불한다.
ISO에 따르면
1. 소프트웨어품질 인증에 대한 표준규격
2. 프로젝트 관리에 대한 표준규격 등이
있다. 매우 정교하고 합리적으로 기술되어 있다.
우리 개발자들이 국제 규격을 전용하면 프로젝트 실무 전반에 대한 문서화를
효과적으로 달성 할 수 있다.
따라서, 국제 표준규격을 전용하면 어느정도 저작권 문제에 말려들지 않을 수
있지만 그래도 세심한 주의를 해야한다.
현재 서울 소재의 델파이 툴을 사용하는 소프트웨어 개발회사에 따라
또는 프로젝트 메니저에 따라서 독자적인 방법론이 존재하지만,
가장 효율적인 것을 취사할 필요가 있다.
현재 실무 경력 3년차인 프로젝트 메니저까지도 확실한 개념이해의 기반 없이
마치 모래위의 성을 쌓은 분들이 너무 많은 게 사실이다.
사실 정보공학의 산출물은 가장 정교하고도 광범위한 지도이며 설계도이다.
따라서, 개발자는 이러한 산출물만 보고도 바로 자기의 프로그래밍 언어를
사용하여 신속하고 빠른 개발이 가능해야만 한다.
//////////////////////////////////////////////////////////////////////////////
// 구직 //
개발자에게서 안정적인 수입은 매우 중요하다. 초창기에는 서버 관리자로서 안정적인
프로그램 개발을 할 수 있는 시간적 여유가 있었다.
프로젝트 메니저가 개발인력이 부족하다는 말은 고급 개발자가 부족하다는 의미이며
경영자가 개발인력이 부족하다는 말은 임금이 저렴한 개발인력이 부족하다는 의미이다.
직업에 대하여 순수했던 저에게 기분을 상하게 했던 것은 경영자가 아니면서 또는
채용 할 의사가 없으면서 저의 이력서를 요청한 사실이다.
나중에 안일이지만 개발 능력보다 중요한게 인맥이다. 개발 능력이 부족해도 고급
개발자를 많이 알아두어 프로젝트에 따라서 단지 소개만 하여도 돈을 벌 수 있는 것
이다. 경영자 또는 개발 업체에서는 특정 분야에 대한 개발 인력이 필요 할 때
공급하는 능력을 매우 중요하게 생각한다.
프리랜서라함은 단어의 의미가 자유 계약직을 의미하지만, 개발직에 있에서는
전문 개발직을 의미한다. 아르바이트와는 별개의 문제이다.
고도의 전문 개발 기술을 습득한 실무 경력자를 의미한다.
그러나 우리 나라에서는 직업소개소, 인력 파견업체를 의미한다. 독자적인 프로젝트
수주가 불가능하고 다른 기업의 프로젝트와 관련하여 사람을 소개하는 정도이다.
이런 일련의 인력파견 업체로 인하여 많은 개발자들이 이직을 하거나 전업을 하거나
개발일에 대하여 환멸을 느끼는 경우가 생겼다.
// 프로젝트 시작 : 인터뷰 //
미니 프로젝트 수행의 어려움은 역시 의사 소통이다. 초기에 필자는 이 어려움을
필자의 사무직원으로서의 행정 업무에 재직 경험으로 보완 할 수가 있었다.
그러나 이러한 점은 프로젝트 수행에 좋은 점이라고 말할 수 없다.
최고 경영자의 협조 지시가 내려 왔는 데도 실무자의 협조를 얻기란 쉽지가
않다. 회사 기밀 보호라는 장벽도 그러하거니와 자기가 가지고 있던 업무상의
노하우를 공개하지 않으려는 잠재적인 것도 부정적인 변수가 된다.
우리 실제 생활 즉 자연 환경을 전산세계로 변환 시키는 작업은 고뇌와 노력
그리고 창의적인 노력을 필요로 한다.
이 해법을 위하여 실무에서는 비슷한 유형의 프로젝트와 비교하여 맵핑 시킨다.
그러나 비슷한 유형의 프로젝트라고 하더라도 항상 참인 것은 아니다.
경영자의 정보처리 가공의 초점이 개발자가 사소한 것이라고 여기는 사건이라면
개발된 소프트웨어의 만족을 가져 올 수 없다.
한가지 예로들면 우리나라 대형 가전업체의 판매 대리점에 대한 전반적인 시스템
구축이다. 결론적으로 말씀드리면 여기서 중요 사건은 고객의 가치에 대한 감동이다.
가전매장의 문을 들어선 고객은 이 시점에 제품을 구매 할 수도 있고 아닐 수도 있다.
제품 구입을 의도한다면 매장 상주 직원에게 제품에 대한 자세한 정보를 요청 할 수도
있다. 고객은 진열 라인에 따라서 고객 취향대로 진열 제품에 대한 시선을 고정시킬
것이다. ...중략
위의 기술한 예는 인간의 복잡하고 다양한 행동 양식을 표현한 것이다. 이것을 전산
세계로 구현하는 것은 입문자에게는 쉽지가 않다. 이러한 것을 실무에 반영하기 위해선
숙련된 시나리오 작성에 유의해야 한다. 우리 개발자는 일반적으로 시나리오는 게임
개발에만 적용하는 것으로 잘 못 알려져 있다.
그러나 외국계 개발 회사에서는 시나리오가 정보공학의 초석으로 산출물 중에서 중요한
위치를 가지고 있다.
"자료구조나 알고리즘(로직)이 중요한 이유는 특정 문제 해결을 위해서 실세계의 문제를
수학적 아이디어로 랩핑시켜 해결하는 요소이기 때문입니다.
실제 세계의 모델을 컴퓨터에 어떻게 효율적으로 구현할 수 있는지를 설계하고
그것을 실제로 구현해보는 것은 매우 중요합니다.
실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로
표현해내는 것은 매우 중요한 능력입니다.
알고리즘(로직)의 습득을 위해서는
- 로직을 스스로 생각해낼 수 있어야 합니다.(기존의 방법이 아닌 새로운 것)
-다른 로직과 효율을 비교할 수 있어야 합니다.
-로직을 컴퓨터 언어와 다른 사람이 이해할 수 있는 의사 코드로 표현해낼 수 있어야 합니다.
- 로직이 정상작동(correctness) 여부를 검증하여야 합니다.
개발 기술을 빠르게 습득하기 위해서는 코드 내에 주석을 최소화하되 코드의 가독성이
떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다.
그리고 고도의 전문가와 함께 날 밤을 세며 짝 프로그래밍을 하면
강력한 만큼 빠른 개발 기술을 습득 할 수 있습니다.
로직 패턴을 공부할 때는 그 구조보다는 의미와 의도를 우선해야 합니다.
// 프로그래밍 언어와 개발자 //
필자는 고백하건데 파스칼 언어를 많이 싫어 했습니다. 필자는 어셈블리어와
c언어의 맹신자이자 열렬한 팬입니다. 물론 하드웨어 제어 측면에서 그렇습니다.
하지만 델파이란 툴이 파스칼을 조아하게 만들었습니다.
프로젝트 메니저로서 서로 다른 언어로 된 소스코드를 분석하고 로직을 읽을 수
있기 까지는 많은 시간이 흘러야 했습니다.
한 언어에 대하여 정통하다면 비록 문법을 모른다고 해도 함수 판독은 어렵지
않습니다.
// DB와 연동된 산업용 기기제어 프로그램 //
데이타베이스와 연동된 산업용 기기(PLC포함) 프로그램은 동기화와 빠른 처리를
필요로 합니다. 따라서, 데이터 베이스 처리를 하게 되면 약 10초 라는 지연
타임이 발생하게 됩니다. 그렇게 되면 프로그램에 대한 사용자의 신뢰성이
회손됩니다. 제어기기와 연동되어 데이타 베이스에 질의를 해야한다면 기기
제어전에 사전 질의를 하여 로컬에 텍스트 포맷으로 가지고 있다가
다시 불러들여 사용하고, 만약 실시간의 기기제어 사항을 데이타 베이스에
저장해야 한다면 소켓을 사용하여 사용자 화면에 결과를 먼저 보이고
데이타 베이스에 동시에 저장하도록 한다.
만약, 서버 클라이언트 환경이라면 정상적인 질의 보다는 소켓을 효율적으로
제어하는 것이 유익하다.
// 여성 CEO 아래의 개발자의 위상 //
요즘은 벤처기업 육성 정책에 따라 20대 후반의 아름다운 여성이 CEO가 되는
경우가 많다. 이런 회사에 입사한 개발자는 행복하지 않다.
이쁜 여성 사장님과 일을 하게 되서 기쁘다는 생각은 버리는게 좋다.
거의 대부분 여성 CEO도 다른 경영자와 마찬가지로 소프트웨어 개발에 대해서
잘 알지 모른다. 여성을 상사로 두면 직장 생활하기가 편하지 않다.
정말 피곤하다.
인간적인 유대관계를 가지기 위하여 진솔한 대화를 아니 의사 소통하기가
쉽지 않다. 세심하고 정확한 여성미가 때로는 개발자에게 수 많은 스트레스를
안겨준다.
// 개발자와 스트레스 //
개발자란 직업은 극도의 스트레스를 동반하는 직업이다. 이것을 해소하기 위한
나름데로의 개발자의 반응은 스포츠, 충분한 수면, 음란한 성인자료 감상,
스타크래프트 같은 게임, 음악감상, 섹스 등으로 스트레스를 풀려고 한다.
음란물 감상, 섹스, 게임 중독은 업무에 지장이 없도록 적절한 통제가 필요하다.
또한 개발팀에 여성이 포함되어 있다면 직장에서 우발적인 혹은 의도적인 성희롱
에 주의해야한다.
직장내 회식의 경우엔 여성 직원은 1차 회식이 끝나면 반듯이 귀가 시켜야한다.
만약 이것을 지키지 않는다면 이성이나 자제력이 흐려진 상황에서 직장 동료들
사이의 섹스는 결과적으로 프로젝트를 위협하므로 주의해야한다.
개발자가 회사 내에서 극한의 스트레스 해소 목적으로 음란물을 보는 경우도 있다.
사전에 프로젝트 메니저는 여성 개발자에게 사전 이러한 사실을 인지 시키고
동료 남자 직원의 컴퓨터에 접근하는 것을 삼가하도록 사전 교육을 실시한다.
// 프로젝트 메니저의 궁극적인 의미? 공학의 의미? //
공과대학에 입학하게 되면 학과 지도 교수로 부터 공학의 의미를 듣게 된다.
공학이란 관련 순수 기술 학문에 돈을 가미한 학문으로 순수한 학문에 경제적인
가치 창출 그러니까 최소 희생으로 최대의 경제적인 효과를 내는 것을
의미합니다.
프로젝트 메니저는 소프트웨어 개발에 있어서 공통적인 인자인 돈(가치)과 결부
하여 경제적인 수익을 내는 직책을 말합니다.
다시 말하면 프로젝트의 성공을 가져오는 것 뿐만 아니라 프로젝트 결과로 수익을
내는 직책을 말합니다. 비 실무자라면 프로젝트 성공적인 완료까지를 의미하지만
현장 실무에서는 반듯이 수익을 창출해 내는 직무를 수행하는 자를 말합니다.
또 다른 CEO라고 표현하면 적절할 겁니다.
만약, 경제 환경으로 프로젝트 성공을 하였지만 개발 결과로 수익을 내지 못했다면
프로젝트 메니저로서의 책임을 다한 것은 아닙니다.
이러한 이유로 프로젝트 메니저 채용시 반듯이 개발자 출신이 아니더라도 직무
수행이 가능하다고 컨설팅 합니다.
그러나 개발자가 프로젝트 메니저 직무를 수행하게 되면 전체적으로 프로젝트를
조감 할 수 있고 여러가지로 유익한 점은 부인하지 않겠습니다.
그러나 개발자 출신의 프로젝트 메니저가 주의 할점은 고정관념을 깨야합니다.
틀에 박힌 고정 관념은 프로젝트의 성공을 위태롭게 만듭니다.
프로젝트 메니저는 프로젝트 수행 기간동안 모든 변수를 파악하고 항상 돈과
관련을 짖고 판단해야 합니다.
// 곧 바로 투입되는 개발자 양성을 위해서는...//
전공 불문하고 전산 전공자이면 더 바랄 것이 없지만, 비 전공자라면 최소 1년
정도의 프로젝트 실무 과정 또는 컴퓨터 관련 학원에서 컴퓨터와 친숙하면 좋겟다.
이런 사회 초년 대졸자를 실제 프로젝트 실무에 투입하려면 소요 기간은 약2년이며
소요 비용은 약오천만원 정도이며, 이것은 개발자가 주야로 밤을 설치면서 노력했을
때의 이야기이다. 개발자 양성이 얼마나 어려운 일인가를 단적으로 표현하고 있다.
그리고 개발회사에서 실무 경력자를 선호하는 이유는 양성하려는 비용,
즉 위탁 비용을 기업에서 부담하지 않으려 하기 때문이다.
양성을 위한 위탁비용과 인건비로 인하여 이중 부담이 되기 때문이다.
// 개발자와 브로커 //
소프트웨어 개발 세계에는 브로커란 직업이 있습니다. 브로커가 나쁘단 이야기는
아닙니다. 아마도 필요악인듯 싶습니다. 프리렌서에게는 돈 줄이니까요...
이 분들은 개발자 출신도 있지만 개발과는 전혀 인연이 없는 영업맨인 경우가
많습니다. 정부 요직의 관료와 친분있는 자와 관공서 및 기업에 소모품 납품업자
하청 업자들이 주류를 이룹니다.
날밤을 세워 어렵게 프로젝트를 완료했으나 개발비를 한 푼도 받지 못한
경험이 있나요?
어렵게 프로그램 개발을 완료하였으나 개발회사가 부도나서 급여를 한푼도
받지 못한 경우가 있나요?
소프트웨어의 개발 회사의 최소 팀 인원은 5명정도입니다.
그런데, 최고경영자와의 신의를 저버리고
중간관리자가 사장을 배신하고 직원들을 대리고 퇴사하여 회사 기술로 다른
상용프로그램을 만들어 팔다가 이 사실을 전 사장이 추적하자 그 회사를 처분하고
사라져 버리는 것을 경험하셨나요?
브로커란 프로젝트 수요처를 파악하고 프로젝트 진행중의 난해한 솔류션 개발을
위하여 개발자를 수요처에 소개하고 거액의 사례비(소개비)를 챙기는 직업을 말합니다.
인력파견 업체도 브로커 성격을 가진 경우도 있습니다.
헤드헌팅과는 질적으로 다릅니다. 브로커는 거액의 돈을 중간에서 챙기게 됩니다.
보통 대형 SI업체에서 5억 정도가 소요되는 프로젝트에 대해서도 브로커는 단번에
일천만원 정도에 해결하려고 합니다. 나머지 금액은 브로커가 금액을 취하게 됩니다.
최초 정부 발주의 프로젝트는 브로커를 위한 게 아니라 개발자에게 돌아갈 금액입니다.
그러나 건설처럼 재하청에 재하청을 주는 악순환이 생기게 되었고, 발주자로선
누가 프로젝트 비용을 취하는 데 관심은 없고 프로젝트 성공 결과만을 바랄 뿐입니다.
자본금이 1억 정도 밖에 안되는 벤처기업에서, 정작 아이템에 필요한 소프트웨어
개발이 필요하게 되었을 때,개발 자금이 전혀 없는 데도 불구하고 5백만원선에서
해결하려 듭니다. 아마도 개발자를 속이려 드는 일이지요
귀하가 프리렌서인 경우라면 계약 할 때 세심한 주의를 해야하고 개발용역대가를
반듯이 나누어 받으셔야 합니다.
프로그램 개발 완료 후 청구하는 것은 이미 늦으므로, 개발 진행에 따라 나누어
받도록해야 합니다.
// 프로젝트 수주의 과정 //
원래는 정보화촉진기금 등 정보통신 분야의 진흥을 위하여 조성된 기금은
대형 SI 업체를 위한 것이 아닙니다.
말 그대로 정보통신 분야의 진흥을 위한 기금이죠.
정보통신 분야의 육성을 위한 각종 정부 투자 자금등은
결론적으로 말씀드리면 최하위에서 실제로 그 프로젝트를 수행하는 개발자가
지속적으로 개발을 촉진하기위한 자극제입니다.
이러한 정부의 의도와는 달리 결국은 수 많은 프로젝트는 대형 SI 업체에서
수주를 하였습니다.
예를 들면, 개발아이템이 무선모뎀 개발 및 드라이버 개발이라면 이 개발을 위해
하청에 재하청에 또 하청을 받아서 최종적으로 실제 개발 업무를 담당하는
개발자로 프리랜서를 고용하여 일억오천만원을 주기로 계약하고, 프로젝트
완료 기간을 6개월로 한정하였다면 실제 수주액은 오억원이 넘을 가능성이
있습니다.
그럼, 실제로 개발을 담당한 이 개발자가 오억원에 정부로부터 이 프로젝트를
수주 받는 것이 가능할까?
실제로 불가능합니다. 비록 이 개발자가 개발능력을 정부로부터 인정 받기는
쉽지 않으며, 인정 받더라도 각종 담보가 없으면 많은 어려움이 있습니다.
대형 SI 업체는 실제로 개발 능력을 보유하고 있지 않더라도, 우선 정보통신
업체로서 각종 정부의 기준에 대한 구비요건을 갖추고 있습니다.
정부가 발주하면서 바라는 것은 실제 개발 능력이 중요한게 아니라 요식행위
즉, 각종 시행 법령에 적합한 문서와 그 요건에 맞추어 버리면 됩니다.
미국과는 마니 다른 문화입니다. 건설 같은 경우에는 시방서라는 자세한
공정 사항이 기록되어 있는 경우가 있습니다. 미국은 합리적인 문화가 발달되어
있어서 문서화가 잘된 개발회사에서는 비록 전산 전공자가 아닐지라도 그 문서만
보고도 소프트웨어 개발이 가능하다고 합니다.
정부로 부터 프로젝트를 수주하기위해 대형 SI 업체에서는 실제 개발에 참여 할
개발자도 이력서를 통하여 연락처와 인적사항을 알고 있으면 된다.
자기 회사에 고용된 직원이 아니더라도 된다.
비록 개발능력이 없다고 하더라도 정보처리기사1,2급 등 관련 자격 소지자가
있다면 수주 받기가 용이하다.
결국은 이러한 악성 구조가 실제 현업에서 개발자의 수명을 단축하게 만들며
개발자란 직업을 버리고 다른 직종으로 이직하게 만듭니다.
현실에서는 개발자가 필요로 되는 경우에는 고액의 외화를 들여 인도나 미국에서
개발자를 수입하게 됩니다.
// 대형 SI 업체의 타업체 개발 기술을 훔치는 방법 //
예를 들면, 브랜드 가치가 10억이 넘는 업체 A사가 있다고 가정하면, 이 업체는
특정회사를 지칭하는 것이 아니므로 국내의 모 회사를 연상해서는 안된다.
이 글에서는 그냥 보기를 들었을 뿐입니다.
A사에서는 실제 개발 인력을 보유하고 있는 중소 업체들에게 공문을 통하여 제안서
요청을 합니다.
제안서 요청시 프로젝트와 관련있다고 하여 세부 스펙을 정해놓고 기술 사항까지
기술하도록 유도하게 됩니다. 중소 규모 업체들은 이것을 수주하기 위해 불필요한
회사의 개발 노하우까지 제안서에 기술하게 됩니다.
수주를 위해서 고육지책으로 이렇게 하는 것입니다.
A사의 입장에서 보면 방대한 기술 자료가 자동적으로 수집하게 됩니다.
프로젝트 수주에 응했던 중소 기업들이 연락이 오지 않아서, 어떤 기업이 수주하게
되었나 문의해보면, 프로젝트를 발주햇던 A사가 자체 개발하고 있음을 알게 됩니다.
물론,제출된 제안서 덕분에 스펙과 테크니컬 로드맵이 작성된것은 당연하구요.
그럼, 이러한 점을 막기 위해 어떻게 해야 할 까?
프로젝트 수행 제안서에서는 불필요한 개발 노하우까지 기술되지 않도록 주의해야
하며, 발주를 한 대형 업체의 최고 경영자와 직접 접촉 및 계약을 하거나
차라리 로비를 해야합니다. 물론 공개입찰 형식을 시행한다하더라도 내부적으로
결정되게 만들어야 합니다.
두번째 방법으로 타회사의 개발 기술을 훔치는 방법을 기술하겟습니다.
우선 프로젝트를 발주합니다. 발주하면서 특약 사항을 넣게 되는 데, 발주처에서
감독관이란 직책을 주어 자사 직원을 프로젝트 수행 개발자들과 함께 참여하도록
만듭니다. 프로젝트 진행기간 동안 관련 개발 기술을 모조리 훔쳐내게 됩니다.
이것을 막기위해 특약 사항을 만들기 전에 감독관 범위와 회사 노하우 보호를
위한 장치를 만들어야 합니다.
세번째 방법으로 이것은 영업 기밀 즉 노하우 보호와 밀접한 관련이 있습니다.
즉, 핵심 기술을 보유하고 있는 대리급 개발자에게 접근하여 거액 연봉 제시를 하여
별도로 기술적인 면접을 봅니다. 스카웃 내용에 대한 계약 이행에는 시간을 끌며
핵심적인 기술 사항에 대한 질문을 하여 개발 기술을 훔쳐 내게 됩니다.
종국에는 자사의 인사 위원회의 결정으로 스카웃이 백지화 되었다고 통보하게
됩니다.
거액 연봉 제시의 스카웃 제의로 핵심 노하우 유출이 너무 쉽게 됩니다.
영업 기술 유출은 친고죄로서 민사 및 형사상의 책임을 져야 합니다.
// JSP 환경의 구축 //
델파이 개발자가 다른 개발 언어에 관심을 갖는 것은 매우 흥미롭다.
JSP는 윈도우 환경에서 코딩하여, 컴파일 하고,
사용 할 때는 리눅스 서버에 적재하는 것이 이롭다.
물론 리눅스에서 VI 편집기로 코딩하는 것도 괜찮을 것 같다.
우선 코딩 플랫 폼은 윈도우 NT4.0/WINDOWS2000pro에서 하는 것을 추천한다.
윈도우 환경은 왠지 불편함을 느낀다.
*** EJB의 개념 ***
Enterprise Java Bean은 일종의 업무용 컴포넌트이다.
또한 wrapper class file이다.
재사용을 위한 것을 보면 라이브러리라고 해도 틀리지 않다.
윈도우 운영체제에서 공유 DLL은 런타임시 각 응용프로그램에서 동적으로 메모리에
적재하여 사용한다. 그리고 각 응용프로그램에서 공유하여 사용한다.
이런 개념에서 볼때에 자바빈은 자바 콘테이너 서버에서 실행시 동적페이지에
빈 테그를 사용하여 서브릿을 참조하게 된다.
어쩌면 공유DLL, 혹은 공유 라이브러리라고 이해하면 될 것 같다.
사실 데이타베이스 접근 및 업무용 질의어를 JSP 내에 코딩하게 되면
지루하게도 똑 같은 코드가 반복되며, 이와 관련된 JSP 파일을 클라이언트에서
다운로드 받게 되면 모든게 노출되어 보안상 이롭지 못하다.
물론 자바의 특성상 역컴파일이 가능하기 때문에 소스 코드의 노출 위험은 언제나
존재한다.
1. 선의 자바 사이트에 가보면 컴파일러를 다운 받아보려고 하면 수 많은 버전들이
존재하여 어떤 것을 다운 받아야 할지 어려움을 느끼게 된다.
물론 최신 버전을 다운 받으면 되겟지라는 생각은 금물이다.
우선 JDK 버전은 데이타 베이스 관련 서브릿 개발 환경이 목적이므로 반드시
JDK가 아닌 J2SDK-1_3_0_02 버전을 다운 받는 게 노하우이다.
2. 컨테이너를 다운 받으려고 자카르타 톰 캣 사이트에 가보면 무수히 많은
버전 때문에 당황하게 된다.
물론 최신 버전을 받으면 되겟지?라는 생각은 금물이다.
JAKARTA-TOMCAT-3.2.4를 다운 받아야 합니다. 그 이상의 버전을 다운 받으면
JSP와 서브릿을 지원하는 범위가 다릅니다. 그 이상의 버전을 다운 받아 압축을
풀어보면 라이브러리에 servlet.jar가 포함되어 있는지 확인하기 바란다.
3. mysql은 mysql-3.23.49가 무난하며,
mysql을 위한 ODBC 드리이버는 myodbc-2.50.39를 다운 받으며,
JDBC 드라이버는 mysql.jar 형태로 압축된 것을 다운 받아서 사용한다.
4. 각종 라이브러리 클래스 파일, 컴포넌트 클래스 파일, 그리고 이것을 JAR 파일
형태로 압축된 것을 c:\jdk1.3\jre\lib\ext로 copy한다. 물론, 사용자 마다
JSDK 설치 디렉토리가 다르게 된다. c:\jdk1.3\jre\lib\ext는 런타임시에
참조할 클래스패스상에 존재하는 디렉토리이다.
리눅스에서는 J2SDKSE1.2.2 + tomcat3.1
윈도우2000에서는 J2SDK1.3.0 + tomcat3.2.4
를 권장한다.
다음은
톰캣이 올바르게 설치되어 있는지 검사하는 소스코드이다.
파일명 :flowservlet
import javax.servlet.*;
import javax.servlet.http.*;
public class flowservlet extends HttpServlet {
public void init(ServletConfig sc) {
System.out.println("init() 가 호출되었습니다.");
}
public void service (ServletRequest reg, ServletResponse res) {
System.out.println("service() 가 호출되었습니다.");
}
public void destory() {
System.out.println("destory() 가 호출되었습니다.");
}
}
테스트는 것을 컴파일하면 flowservlet.class가 생성 되는 데 이것을
홈페이지 루트 디렉토리하위에 예론
c:\public_html\WEB-INF\classes 에 복사한다.
그 다음에 컨테이너 톰 캣을 실행하고나서
웹브라우저의 URL에
http://localhost:8080/servlet/flowservlet 을 입력하여
에러 없이 아무 화면이 안나오면 설치가 제대로 된 것이다.
소스 코딩 및 컴파일 작업은 윈도우 플랫폼에서 하고
실행은 클래스 파일을 FTP로 리눅스 서버로 넘겨서 한다.
리눅스 서버로 넘길 때는 압축파일로 넘기는 게 좋다.
// 프로젝트 메니저의 인력관리 //
프로젝트 메니저의 중요한 업무 중의 하나가 인력관리 라는 것을 아래 글에서
부연한바 있다.
개발인력의 급여 책정은 개발자의 급여의 3배 수익을 보고 결정합니다.
예를 들면, 개발자가 연봉 일천만원에 계약 했다면 그 개발자에게 1년에
약 3천만원 정도의 수익을 낼 것을 기대합니다.
1년 회사 경영에 예상 수익의 3분의 1정도에서 결정합니다.
쉽게 설명드리면 개발자가 자기가 받는 급여의 3배 정도를 벌어 드리기를
기대한다는 이야기입니다.
// 시리얼 통신 제어 프로그램 -- 프로그래밍 기법 //
여러분이 프리랜서 아니면 초보 개발자라 할지라도 가장 많이 코딩하게 되시는 것이
바로 산업용 시리얼 통신 기기의 제어입니다.
주로 컴퓨터와는 근거리 즉 2미터 이내의 케이블로 연결된 장치를 제어하게 됩니다.
보기를 들면 각종 POS 기기, 바코드 프린터, 터치모니터, 전광판, 카드 인식기기,
휴대폰, PDA 등 수 없이 많습니다.
우선 시리얼 통신 제어 프로 그램을 작성하기 위해선 시리얼 컴퍼넌트를 활성화
하는 부분을 try ~ except ~ end; 문으로 감싸야 합니다.
이렇게 하지 않으면 에러 발생시 컴퓨터가 먹통이 되는 경우도 생깁니다.
다른 어플에서 시리얼 포트를 사용 할 때 또 다른 어플이 같은 시리얼 포트를
사용하지 않도록 해야합니다.
우선 시리얼 제어용 유명한 상용 컴포넌트는 바로 터보 파워의 어씽크
프로페션널입니다. 가격은 아마도 일백만원대 일 것입니다.
이 컴포넌트는 우리에게 많이 알려져 있습니다.
어씽크 콤퍼넌트를 사용 할 때 주의 사항은 버전에 따라서 일회 전송 량이
8 바이트로써 ( 8 * 1024 ) 8바이트가 넘은 경우에는 8바이트 씩 나누어 가져옵니다.
그래서 stx := #02 + 전송 데이터 + etx := #03 형식으로 가져옵니다.
여기에서 전송 데이터가 20 바이트가 넘는 경우에는 어씽크에서는 두번 나누어서
가져오게 됩니다. 전송 이 벤트가 여러번 호출 된다는 의미입니다.
이것은 제어용 데이타가 산업용 제어기기에 전송 시점의 동기화가 필요 할 때는
무척 제어를 어렵게 만듭니다.
모든 시리얼 콤포넌트가 그렇듯이 char 타입으로 1문자씩 8비트로 가져옵니다.
보통 컴포넌트 이벤트에서 카운터 많큼 가져 옵니다.
var
i : integer;
read_data : string;
begin
for i := 1 to count do
read_data := read_data + getread();
end;
예를 들어 알파벳 A라는 문자가 전송 될 때,
STX - A - ETX 또는 [02] - A - [03] 이렇게 전송됩니다.
일단 컴포트로 전송된 데이터를 읽어 드려서 STX가 감지되면 지금 버퍼로 읽어 드리고
있는 중이고 ETX가 감지되면 전송이 끝났다는 것이 감지됩니다. 보통 이 때 데이터를
버퍼로 부터 읽어 들이고 난 다음에 다음 전송을 위해서 버퍼를 초기화 시킵니다.
로직을 자세히 설명드리면,
우선 컴포트 상태를 판별하기 위한 상수가 필요합니다.
stx := 02, etx:=03 으로 상수가 사전 정의 된다.
컴포트 작동을 콘트롤을 하는 판별자를 상태에 따라 변수에 배열 형태로 자료형을 정의하고
그 크기를 설정한다. 변수의 그 크기를 측정하고 그 크기만큼 0으로 채워서 배열 변수를
초기화 시킨다.
카운터가 0 이상이면 카운터 -1 만큼 변수에 읽어 드린 자료를 저장한다.
변수에 읽어드린 데이타를 검사하여 컴포트의 상태를 판별한다.
만약 STX가 인지되면 버퍼에 자료를 수신중임을 나타낸다.
읽어 드린 변수가 STX으로 인지되면 버퍼 변수를 초기화하고 컴포트 상태 판별자를
수신가능 상태로 설정한다.
읽어드린 변수 값에서 ETX가 판별되면 수신 데이타를 모니터 콘트롤에 표시하고
버퍼 변수는 초기화 시킨다.
///////
윈도우에서 클라이언트 프로그램을 설치하다 보면 설치 관리자 프로그램의 사소한
실수로 예론, path 설정 부분에 특수 제어문자 혼입으로, 환경 변수의 path가
먹혀들지 않아 곤란을 겪는 경우가 종종 있습니다.
window 95/98에서 autoexec.bat의 내용중에 path을 설정하는 방법입니다.
형식은 set path="절대경로"
다음줄에 set path="절대경로";"%path%";
형식은 set classpath="절대경로"
다음줄에 set classpath="절대경로";"%classpath%";
보통 autoexec.bat 파일을 편집기로 열어서 한줄에 이어서 적어주어야 하는 데
만약, 한 라인이 길경우에나 제어문자가 혼입되는 경우에 라인이 분리되어
path 설정이 안되는 경우가 많습니다.
이런 경우에는 한줄에 다 기록하지 말고 다음 라인에 기록을 해야합니다.
즉, 이미 설정된 환경변수 %path%를 이용하게 됩니다. 만약 편집이 잘 못되어
2라인으로 인식되면 환경변수를 저장할 공간이 부족합니다 라는 에러 메시지를
냅니다. 그래서 다음 보기와 같이 작성해야 합니다.
보기를 들면,
set path="c:\informix\bin"
set path="c:\other application\bin\;"%path%";
다음 보기를 들면
set path="c:\;c:\windows;c:\windows\command;";
set path="c:\first appl";"%path%";
set path="c:\second appl";"%path%";
위에서 보면 중요도가 높은 프로그램이 설정 부분의 제일 앞에 오도록합니다.
이방법 말고 레지스터리를 이용하면 더 손쉽게 경로 설정을 할 수 있습니다.
CPU가 특정 실행 프로그램을 찾으려 할 때 레지스터리를 이용하여 CPU에 알려주면
그만이다.
위와 같이 하더라도 " 환경변수 저장 공간이 부족합니다." 또는 "too many parameter"
메시지가 나오면 다음과 같이 처리하면 된다.
한글 MS- DOS 창을 연다.
최상단의 타이틀의 왼쪽의 DOS 아이콘에 마우스를 대고 오른 쪽 버튼을 누르게 되면
나오는 메뉴 중에서 등록 정보를 선택한다.
그 다음에 메모리 탭을 선택하면 상단의 기본 메모리에서 초기환경 부분을 자동에서
2816 바이트를 선택한다음 적용을 누르고 시스템을 재 시작하면 된다.
위의 경우엔 자동 실행 파일인 경우이고 만약, 현재 파일은 *.bat의 내용중에
환경 설정하는 부분이 있으면 환경변수가 부족하다는 에러 메시지를 만나게 된다.
이럴 경우에는 *.bat에 대한 *.pif 파일을 만들어 등록 정보에서 초기 메모리를
2816으로 잡아준다. 부연하면 *.bat의 등록 정보를 콘트롤 하면 자동적으로
*.pif가 생성된다.
환경 변수 설정의 확인은 MS-DOS 창에서
c:\echo %path%
로 확인한다.
리눅스에서는
# echo $path 으로 확인한다.
/////////////////////////////////////////////////////////////////////////
이 문서는 원래 델파이 개발자를 위한 것입니다. 그래서 델파이에 관련된 내용을
기술하려 했으나 본래 취지에 맞지 않게 리눅스, 자바, 오라클, 델파이, 마케팅
내용이 들어가서 송구합니다.
볼랜드 제품 군 중에 통합 환경(IDE)인 J빌더가 아닌 순수한 JDK 설치와 관련하여
몇 가지 고려 사항을 기술하려고 합니다.
콘 솔에서 자바 컴파일 명령은
# javac -classpath d:\myclass java_source_code.java
위와 같이 -classpath 옵션을 사용하여 참조할 클래스가 있는 절대 경로를
지정해 주는 방법이 있습니다.
그런데, 만약 시스템 환경변수에
예를 들면, 윈도우에서
# set classpath= .;
리눅스에선
export classpath=./:
위와 같이 추가하면 현제 디렉토리를 중심으로 하위 디렉토리를 클래스를 찾게
됩니다. 따라서 자바 소스코드가 있는 디렉토리 중심으로 참조할 클래스를 하위
디렉토리에 두게 되면 현재 디렉토리부터 하위 디렉토리로 찾아 가게 됩니다.
그리고 패키지 클래스를 임포트한 경우라면 패키지 기술을
A.B.C.D.* 로 한다면 현재 디렉토리 중심으로 .\A\B\C\D\* 으로 찾게 되므로
결과적으로 점연산자가 디렉토리 구분자 \로 맵핑된다.
점하고 디렉토리 구분자인 / 하고 일대일 매칭 된다고 생각하면 쉽습니다.
원래 점 연산자는 클래스에서 멤버를 기술 할 때 사용됩니다.
JDK 환경에서 자바 소스 코드 중심으로 임포트 할 클래스는 소스 코드 있는 곳의
하위 디렉토리에, 웹에서 실행 할 클래스 및 jar 파일은 WEB-INF/classes
하위에 두면 콘테이너인 자카르타-톰캣이 클래스 패스를 잡아줍니다.
여기에 자바 소스 파일을 보관하지 않도록 한다.
윈도우 2000/NT 에서
set classpath=.;c:\jdk\lib\tools.jar;c:\jdk\lib\servlet.jar
자바에서는 압축 파일 형식이 zip 형태이거나 리눅스의 tar 처럼 확장자가
*.jar 인 것은 실행 파일이 아니라 압축 파일 형태임을 의미합니다.
*.zip 이나 *.tar를 환경 변수에 클래스 패스에 파일명까지 설정해 놓으면
실행중에 자동으로 압축이 풀리면서 참조 된다.
// 리눅스와 오라클 //
노련한 프로젝트 메니저가 없다면 초보 상태에서 리눅스에 오라클을 설치하여
보기 바랍니다. 아마도 엄청난 시련이 밀려 올 것입니다.
오라클에 대한 자료는 인터넷에 많이 있습니다. 그러나 오라클 세팅과 설치에
많은 시간과 노력이 필요한 것은 사실입니다.
리눅스 배포판 모두에 오라클을 설치 할 수 있는 것은 아닙니다.
수세 리눅스 같은 겨우에는 수세 리눅스 개인판에 설치하려 하면 사후에 서버로
사용하기엔 어려움이 많다. 아무래도 제일 무난한게 레드핫 배포판을 사용하는 게
좋을 것 같습니다.
* 리눅스 배포판 버전과 설치 할 오라클 RDBMS 버전에 주의하여야 한다 .
특히 리눅스 커널과 glibc 버전이 매우 중요하다 .
* 리눅스를 서버로 사용하고자 할 때는 HDD의 파티션 나눌 때 주의해야 한다.
파티션을 효율적으로 나누게 되면 많은 사용자의 수용과 DB의 성능과 리눅스
운영체제가 최적의 성능을 유지하게 된다.
이미 리눅스가 설치 되었다면 다음 명령으로 HDD의 현재 구성하고 있는
리눅스 파티션 현황과 사용량을 알 수 있다.
# df -k
* 표준적인 파티션 용량
루트파티션 / 최소 150~200MB 최대 400~600MB
/usr파티션 /usr 최소 600~800MB 최대 1200~1500MB
/home파티션 /home 최소 150MB 무제한
/var파티션 /var 최소 200~300MB 최대 400~600MB
/tmp파티션 /tmp 최소 200 최대 300 이상
/swap파티션 /swap 최소 50~120MB 램의 두배이상
위와 같이 디렉토리와 파티션을 대응 시킨 이유는 파일 시스템이
손상 되었을 경우 복구가 용이하고 최소화하기 위함이다.
** 리눅스를 서버로 사용하고자 할 때는 파티션을 나눌 때
주의를 해야한다.
만약, HDD가 9GB라면 아래와 같이 나누면 된다.
실제적인 디렉토리가 별도의 파티션에 마운트되게 하면 관리 및 복구가 용이하다.
/boot sda1 16MB
/ sda8 256MB
/home sda6 3868MB
/usr sda5 3868MB
/var sda7 256MB
/swap sda9 489MB
* 오라클 RDBMS을 설치하기 전에 먼저 환경 변수를 설정해 줘야 한다.
기계적인 성능을 설정하기 위해서는 먼저
# vi /usr/src/linux/include/asm/shmparam.h
# vi /usr/src/linux/include/linux/sem.h
내용을 적절하게 편집을 한다.
레드핫 리눅스 배포판인 경우 bash를 사용 할 경우 프로그램 경로명과 관련된
환경 변수를 설정해 줘야한다. 이것은 .bash_profile에 추가한다.
시스템 환경변수는
# vi /etc/profile
계정 사용자 환경 변수는
# vi /home/oracle/.bash_profile
# 오라클 홈 계정에 퍼미션 설정을 위한 마스크 설정을 함
export UMASK=022
# 오라클이 설치된 호스트명을 설정함
export DISPLAY=host_names:0.0
# 오라클이 설치된 홈 디렉토리 oracle 사용자 계정 디렉토리가 아님
export ORACLE_HOME=/home/oracle/8i
# 오라클 실행 데몬이 있는 경로
export PATH=$PATH:$ORACLE_HOME/bin
#export PATH=$PATH:/home/oracle/app /IBMJava2-13/jre/bin
; 리눅스에서 사용자 계정인 오라클 홈을 의미한다
export ORACLE_BASE=/home/oracle
; 오라클 DB 구조를 가진 전역 객체 파일이다. 디비 서버임
export ORACLE_SID=ORCL
export LD_LIBRARY_PATH= "${LD_LIBRARY_PATH}:$ORACLE_HOME/lib"
; 다국어 설정 부분으로 디비 버전에 따라 설정 방법이 다르다.
export NLS_LANG=AMERICAN_ AMERICA.KO16KSC5601;
export ULIMIT=2113674
; 오라클 파일들의 소유자를 의미
export ORACLE_OWNER=oracle
#export ORA_NLS33= $ORACLE_HOME/ocommon/nls/admin/data
; 클래스 패스를 의미
export CLASSPATH=$ORACLE _HOME/JRE:$ORACLE_HOME/jlib
************************************************************
다른 디렉토리에 있는 압축 파일을 현재 위치의 디렉토리에 풀고자 할 때
압축 풀 디렉토리로 먼저 이동하여 명령을 내린다
# tar xvfz /mnt/windisk/oracle8iR2.tar.gz
# chown oracle.oistall XXX 또는 chown oracle.dba XXX
************************************************************************
해당 디렉토리 아래 모든 파일의 권한을 바꾸려면
# chown -R 소유권자 타겟_디렉토리명
# chown -R oracle /usrdir
***********************************************************
오라클 데이타베이스의 기동
; 리눅스 사용자 계정 중 오라클 계정으로 로그인을 하여 DB를 마운트한다.
; 리스너는 원격 컴퓨터에 설치되어 있는 DB 서버와 통신하기 위한
; 즉, 접근하기 위한 데몬이다.
; 리스너의 환경 설정 파일은 /home/oracle/8i/network/admin/listener.ora
; 오라클을 첨 설치할 때 설치되는 listener.ora를 사용하면 안되고
; ../samples에 있는 listener.ora를 복사해서 사용하도록 한다
; listener.ora 파일은 root 권한으로 설정한 # netcfg 값의 영향을 많이 받는다.
# netcfg 의 설정 방법은
127.0.0.1 localhost.localdomain localhost
210.113.114.7 localhost.localdomain dbserver
위에서 젤 오른 쪽이 호스명에 대한 알리아스 명이다.
위 내용은 /etc/hosts 파일에 기록 된다.
; listener.ora 파일을 편집한 경우에는 시스템을 리부팅하는 게 좋다
; tnslsnrctl start
# lsnrctl start
; DB 서버 관리자의 실행
# svrmgrl
; 명령문 마직막은 ;으로 표시한다
SVRMGR> connect internal;
; DB의 시작
SVRMGR> startup;
; 서버관리자의 종료
SVRMGR> quit
***********************************************************
오라클 데이타베이스의 종료
; 서버 관리자의 실행
# svrmgrl
; DB 서버 메니저에 연결
SVRMGR> connect internal;
; DB 서버의 종료
SVRMGR> shutdown;
SVRMGR> quit
; 리스너의 종료 tnslsnrctl stop
# lsnrctl stop
*********************************************************
오라클 디비 안의 사용자 계정에 대한 암호 변경
오라클을 설치하면 기본 계정과 암호는
# sqlplus system/manager
# sqlplus sys/change_on_install
입니다 . 이것을 변경하도록 합니다.
오라클 디비가 마운트 된상태에서
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: manager 엔터
# sql>password 엔터
# sql>old password : manager 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: change_on_install 엔터
# sql>password 엔터
# sql>old password : change_on_install 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
***********************************************************
* 오라클 데이타베이스의 질의
# sqlplus scott/tiger
************************************************************
BDE Administrator 설정
************************************************************
; 서버 네임은 원격 호스트 이름이 아니라 원격 호스트에 설치된
; 전역 객체인 DB 서버의 이름이다.
; 네트워킹에서 IP에 해당되는 호스명이 아닙니다. 즉,
; 리눅스에서 /etc/hosts 내용에서 그 호스명이 아니며 서버네임은 일종의
; 윈도우에서 보면 데이타베이스 구조를 가진 파일명을 의미합니다.
; 입문하신분들이 많이 혼동하는 부분입니다.
; 아래와 같이 설정하면 ORCL파일은 즉 SID는 오라클 구조와 형식을
; 가진 DB 깡통이다 이 안에 테이블을 생성하게 된다.
; 대부분의 관계형 데이타 베이스는 디비 서버 파일을 즉 전역 객체 파일을 제어하기
; 위한 실행 파일과 DB 구조를 가지고 있는 디비 서버 파일로 존제한다.
* SERVER NAME : ORCL
; 사용자 네임은 운영체인 리눅스의 사용자 계정이 아니고 오라클 DB 안의 DB 사용자 계정이다.
; 유저 네임은 운영체제에 즉 리눅스에 로그인 하기위한 계정이 아닙니다.
; 이것은 각각의 관계형 디비 안의 데이타베이스 사용자 계정입니다.
; 이 유저 네임은 데이타베이스 서버 관리자를 사용하여 생성 시킬 수 있다.
* USER NAME : scott
* 리눅스에서 사용자 계정 생성 방법 *
먼저 구릅을 생성하고 사용자 계정을 생성한다. 생성된 구릅에 사용자 계정을 추가한다.
# groupadd mysql
# useradd -g mysql mysql
***********************************************************************************
많이 사용되므로 주의 할 것
* 특정 디렉토리에 하위 디렉토리까지 권한을 설정하는 방법 *
# chmod 755 -R /usr/local/mysql
# chown -R root /usr/local/mysql
# chgrp -R root /usr/local/mysql
*************************************************************
오라클 데이타베이스의 풀 백업
; 먼저 oracle로 로그인한다음에
형식은
# exp system/시스템계정암호 file=/절대경로/백업파일명.dmp compress=n log=/절대경로/로그파일명.log full=y
# exp system/manager file=BACK_FILE.dmp compress=n log=BACKUP_FILE.log full=y
보기를 들면
# exp system/manager file=/data_backup/data/2001_0306.dmp compress=n log=/data_backup/data/2001_0306.log full=y
# exp system/manager file=/data_backup/20020305.dmp compress=n log=/data_backup/20020305.log full=y
* 자바 사이트 목록 *
;자바에 대한 기본적인 내용 문서
http://rtislab.chungnam.ac.kr/~java/j_lecture/home.html
;자바에 관련된 게시판,커뮤니티가 활성화 되어 있는 곳
http://www.javaservice.net
;Java Develope site
;Java marketplace at Sun.
**** 기호식별 ***
# : 슈퍼유저의 의미 쉘스크립트에서 주석문 의미도 있음
; : 쉘스크립트에서 주석문을 의미함
* 쉘 콘솔로 진입하는 방법
boot: linux init=/bin/sh
* 리눅스로 진입
boot : linux
* 도스로 멀티부팅 :
boot : dos
* 루트디렉토리를 읽기 쓰기 가능한 상태로 마운트하기
# mount -o remount / -rw
* FTP 서버의 사용
1. FTP 서버 사용금지자 목록 파일에서 사용하고자 하는 계정 삭제
# vi /etc/ftpusers
2. 호스트 접근 가능한 계정 목록 파일 편집
# vi /etc/hosts.allow
in.ftpd : localhost
형식 : 데몬 : 호스트네임
3. FTP 서버 실행
# /usr/sbin/ftprestart
4. FTP 서버 실행 중지
# /usr/sbin/ftpshut
* 압축파일 푸는 법 :
# tar zxvf mysql.tar.gz
* 디렉토리 이동 :
# mv dir1 dir2
* 아파치 시작하기
아파치 서버는 다음과 같이 실행합니다.
# /usr/local/apache/bin/apachectl start
아파치 서버의 실행을 종료하고 싶다면,
# /usr/local/apache/bin/apachectl stop
아파치 서버를 재시작 하고 싶다면,
# /usr/local/apache/bin/apachectl restart
와 같이 합니다.
* 부팅할 때 자동으로 서버 실행되게 설정하기
# vi /etc/rc.d/rc.local
위 파일을 편집하면 된다.
파일의 맨 마지막에 아래의 명령어를 추가하면 됩니다.
* 현제 데몬의 확인
# ps -aux | grep daemon_nanme
# ps aux | grep daemon_nanme
* 데몬의 재실행
kill -HUP 1
* 삼바의 데몬 실행
# /etc/rc.d/init.d/smb stop
# /etc/rc.d/init.d/smb start
# SAMBA NetBIOS services (for PC file and print sharing)
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
* 구룹 소유자 변경
# chgrp -R root /root/etc
* 소유자 변경
# chown -R root /root/etc
* 시스템 종료
# shutdown -h
* 프로세스 종료
먼저 프로세스 확인
# ps aux | grep process_name
위 명령결과 포로세스 아이디 확인
# kill -9 process_ID
* 파티션 목록 보기
# fdisk -l /dev/hda
* 특별한 플래그 세팅 루트권한으로도 수정이 불가능하고 읽기만 가능하다
chmod 명령보다 상위 명령이다.
# chattr +i /root/etc
해제 : chattr -i /root/etc
* 디스크 오류검사
# fsck -a
# e2fsck -a
* msdos 파일 시스템으로 플로피 드라이브 마운트하기
형식: mount -t 파일시스템종류 물리적인마운트장치명 논리적인마운트될디렉토리
# mount -t msdos /dev/fd0 /mnt/floppy
* 시디롬 드라이브 마운트
# mount -t iso9660 /dev/cdrom /mnt/cdrom
* 언마운트 하기전에 /mnt/cdrom에 접근하고 있는 프로세스를 모두 죽이라는 명령
# fuser -km /mnt/cdrom
**** 만약 리눅스 부팅 중에 sendmail daemon 뛰우는 중에 오래 동안 멈춰 있다면 ****
콘솔로 부팅하여 다음을 시행한다
부팅 중에 sendmail이 오래 동안 멈추는 이유는 파일 시스템 손상도 있겠지만
가장 많은 경우는 /etc/hosts 파일의 내용이 최초 리눅스 설치시와는 다르게 변경 되었을
경우에 많이 발생합니다.
# vi /etc/hosts
127.0.0.1 localhost.localdomain localhost
210.112.113.7 localhost.localdomain fly
만약 sendmail 데몬이 필요하지 않으면 부팅시에 서비스를 죽이는 방법은 다음과
같이 처리한다.
# setup
화면에 나오는 메뉴를 커서로 이동하여 system service를 선택한다
첨 부팅할 때 띄우는 데몬들인뎅 여기에서 sendmail daemon를 해제한다
*********************************************************************
데이터 베이스 생성 즉, 테이블이 존제하지 않는 빈 깡통 생성 방법은
데이터 종류에 따라 약간은 다르지만 주로 각 데이타 베이스의 서버 메니저를
통하여 생성하게 된다
또한 서버 클라이언트 환경에서 다이렉트 콘솔이 아닌 원격으로 데이터 베이스르
콘트롤 할 때는 각종 프로토콜을 이용하여 제어하게 되는 데
각각의 데이터 베이스에 대한 클라이언트 프로그램이 존제한다
클라이언트 프로그램은 데이타베이스 서버에 접근하기 위한 환경 드라이버들을
제공해 준다.
***************************************************************************
// 게임 소프트웨어의 개발 //
게임 소프트웨어를 개발한 경험은 없습니다. 게임에 대해서 논의 하는 것은
부담스런 일입니다. 게임에서 가장 중요한 것은 바로 제품 디자인 측면에서
시나리오란 것입니다. 기술은 어느 정도 수준에 이르면 어렵지 않게
축적되지만 창의적인 면이 강한 부분이 바로 시나리오입니다.
게임 상품으로 성공한 소프트웨어 모두 훌륭한 시나리오가 기본이 되었습니다.
게임이 유명해서 시나리오가 뛰어나다고 한 것이 아니라 시나리오가 소비자를
이끈 것입니다.
// 제품 디자인과 기술의 비중 //
무릇 한 기업의 경영자는 상품의 디자인에 80% 기술에 20% 비중을 둡니다.
상품의 포장을 아무리 강조해도 지나치지 않다는 말이다.
경영자의 속성은 특정 기술과 개발자의 기술에 종속되려 하지 않는다.
사업상 꼭 필요한 기술이거나 희소가치가 높은 기술이라도 제 값을 주고 기술을
구매하려 하지 않는다.
비용을 줄이려고 노력하는 것이다. 프로그램 개발이나 기타 사업에서 기술지상주의적인
발상은 매우 위험한 생각이다.
자기가 속한 개발 회사의 소프트웨어 개발 기술이 다른 개발 회사에서 꼭 필요한 경우가
있다. 경쟁 업체로서가 아니라 사양 분야인데도 다른 기업에선 필요한 경우를 말한다.
그러나 개발 기술이 융통성 있게 확산 되기란 어렵다.
// 오픈 소스에 대한 유솔로몬의 생각 //
소스 코드는 개발자가 땀과 정열, 귀한 시간을 사용하여 낸 땀의 결정체입니다.
따라서 개발자에게 소스를 공개하라 공개하지 마라는 무례한 요구는 삼가 하셔야 합니다.
공개 여부는 전적으로 개발자의 권한입니다.
소스 코드는 " 고기를 잡는 것이 아니라 고기를 잡는 방법" 즉, 노하우를 알려 주는 것으로
부가 가치가 매우 높은 것입니다.
오픈 소스 코드를 활용하여 제3의 진보된 코드를 생산 하거나 그대로 답습할 것입니다.
개발자의 소중한 재산입니다.
상업적인 다국적 기업에게는 오픈 소스 정책이 금전적으로 위협적인 것이 됩니다.
예를, 들면 어떤 응용프로그램이 다량으로 배포가 되었을 때, 그 응용 프로그램의
사용 기업이 특정 부분을 사용하고자 할 때, 많은 부분을 금전적으로 소스코드 소유 기업에
종속되어 버립니다. 그 기업 아니면 해법이 없다는 독점 상태 같은 것 말입니다.
그러나 오픈 소스가 활성화 되면 특정 문제에 대한 해법을 위해 기술적으로 금전적으로
종속되지 않아도 됩니다.
개발자는 당신의 호기심을 충족 시키기 위하여 소스를 오픈 해야할 어떠한 이유가 없습니다.
유수의 대학 내에 비직업적인 개발자가 소스 코드를 오픈 하는 이유는 기술 공유와
기술 유전과 발전을 위한 배려인 경우가 많습니다.
// 외국계 개발기업 그리고 개발자 //
외국계 개발회사에서 개발 업무를 하고 있는 개발자를 바라보고 무척 부러워하고
선망의 눈 빛을 바라보는 경우가 있습니다.
여러분도 그러한 분들 만나게 되면 근무 환경에 대해서 질문 드려 보면 조을 것
같습니다.
그런데, 의외로 그 분들이 마니 힘들어 하는 답변을 하게 됩니다.
첫째로, 모든 프로젝트가 타이트합니다.
이러한 이유로 항상 긴장하고 어떤 분들은 이것에 적응을 못해서 퇴사하는 경우가
많습니다.
둘째로, 모든 업무가 시간관리 중심으로 이루어 집니다.
첫 번째로 인하여 개인 시간으로 배정된 시간 외에는 업무 시간 중에는 업무를 위해 사용
되어야 합니다. 우리나라 처럼 참고 서적을 보며 코딩하는 것은 쉬운 일이 아닙니다.
자칫 자기 개발을 위한 공부로 인식되어 최고 경영자의 눈에 뛰이면 사직서를 내어야 합니다.
세째로, 철저하게 일정표 대로 진행 됩니다.
경험적인 것 그대로 인정되지 않습니다. 모든 성과는 수치로 환산되어 관리됩니다.
// 프로젝트 메니저(PM)가 하는 일 //
<=============================================================================인용부시작
"다양한 프로젝트 경험을 토대로 유능한 PM이 되기 위해서는
첫째, PM역할에 대해 제대로 이해한다.
프로젝트란 목표를 가지고 일정기간 내에 제품이나 서비스를 수행해야 하는 것이며,
한정된 예산과 비용으로 일정 수준의 인력을 어떻게 효율적으로 활용하는가의 문제다.
흔히 프로젝트 관리를 일정관리를 하는 정도로 이해하는 경우가 있는데
프로젝트 관리의 성공에는 많은 변수가 작용한다.
PM은 프로젝트에 대한 범위·일정·비용·품질·인력·위험·조달을 관리하고 책임진다.
둘째, PM이 되기 위해서는 실전에서의 단계적인 연습이 필요하다.
실제로 전문분야에서 개발경험이 없는 사람이 이론적인 경험을 통해 프로젝트를 진두지휘할 경우
실전경험이 없어 예상치 못한 많은 변수를 만났을 때 프로젝트 관리 및 수행을 성공적으로
이끌 수 없는 가장 큰 걸림돌로 작용할 수 있다. 유능한 PM이 되기 위해서는
프로젝트 실전경험을 토대로 단계적인 연습이 필요하다.
셋째, PM과 관련된 체계적인 훈련을 기본으로 공인된 자격증을 확보한다.
전세계적으로 PMI(Project Management Institute)에서 공인하는
PMP (Project Management Professional) 자격증에 도전해
제대로 PM이 되기 위한 길을 준비하는 것도 한 방법이다.
넷째, 비즈니스와 관련된 업무지식을 확보하기에 힘쓴다.
IT기술 관련 전문성과 함께 귀중한 자산으로 쌓이는 것이 바로 비즈니스 프로세스와
관련된 업무 지식이다.
IT관련 개발 인력들의 허점은 단순 프로그래밍에만 집착하면서
전반적인 업무지식의 보유를 게을리하는 데 있다.
부분적인 요구사항의 수렴보다 큰 줄기를 바라보고 업무의 흐름을 파악하는 것이 중요하다.
다섯째, 영어 실력을 꾸준히 연마한다.
IT관련 각종 프로젝트 혹은 컨설팅 프로젝트가 선진기술을 보유하고 있는
해외 유수 업체들과의 합작 프로젝트로 행해지고, 국내에 상주하고 있는 해외 IT업체의 경우도
실제로 솔루션·서비스를 수행하기 위해 영어로 의사소통이 가능한 PM을 확보하려 하고 있다.
실제로 각종 협력 및 제휴관계로 외국 엔지니어 및 PM과 의사소통을 할 수 있는 기회는 많이 있다.
여섯째, 원활한 의사소통 능력 및 리더십을 갖추도록 한다.
프로젝트의 영역관리 중 한 부류로 간과할 수 없는 것이 바로 ‘프로젝트 의사소통 관리’다.
프로젝트와 관련된 내부 인력팀 혹은 시스템을 사용할 엔드 유저(end user)와의 긴밀한 의사소통,
나아가서는 외주업체의 IT 전문인력과의 원활한 의사소통을 통한 프로젝트의 진척성 파악,
정보공유 등을 통한 프로젝트의 의사소통 관리는 성공적인 프로젝트의 완결을 위한
성공 요소임을 인지해야 한다. "
<================================================================================================인용부 끝.
<==========================================================================전자신문 게재일자 : 2002/01/16
// 현제 폼에서 다른 폼 열기 //
방법은 여러가지가 있지만 특이한 코드라 여기에 적습니다.
먼저 uses 절에 참조 할 유닛을 첨가하고
procedure TForm1.Button1Click(Sender: TObject);
begin
with TForm2.Create( nil ) do Show;
end;
// 폼위 라벨의 이메일을 클릭했을 때 아웃룩익스프로세스의 실행 //
ShellExecute( 0, nil, PChar( 'mailto:' + TLabel( Sender ).Caption ), nil, nil, SW_SHOW );
*****************************************************************************삭제부시작
// HOOKING 기법 //
아무래도 후킹은 민성기님 여덕수님, 양병규님이 뛰어나게 구현하신 것 같다.
후킹을 사용 할 때에는 세심한 주의가 필요합니다.
윈도우 운영체제에서 메시지는 운영체제의 근간을 이룹니다.
정확이 알지 않고 임의로대로 메시지를 후킹하면 운영체제가 먹통이 되거나
올바른 동작을 하지 않을 수 있습니다.
개발자가 후킹을 제대로 구현하지 못한다 하더라도 결코 실력이 있거나 없거나
판단 기준으로 고려하지 않도록 프로젝트 메니저는 주의해야 합니다.
후킹에서 고려의 대상은 윈도우 운영체제에서 후킹 기법을 사용하는 응용프로그램이
2개 이상 실행 중일 때, 심각한 문제를 일으킬 수 있습니다.
후킹은 제한적으로 꼭 필요할 경우만 사용하도록 합니다.
복사 방지잠금 장치를 위해 사용자 정의에 메시지 후킹은 권장해드립니다.
다른 한편으로, 다른 여러가지 방법으로 각종 콘트롤 사이에 전역적으로 자료를
교환하고자 할 때는 사용자 정의의 윈도우 메시지와 메모리 맵을 사용하여
데이타를 교환하도록 합니다.
후킹에 대한 사용자 정의 함수는 최소화하여 꼭 필요한 함수만 DLL안에 포함시키고
다른 함수들은 별도 공통 유닛에 만들어 두고 uses 절에 포함 시켜 사용하시기
바랍니다.
사실, 전역적으로 데이터 자료 교환과 특정 메시지 없이는 응용프로그램이 실행되지
않도록 하고자 할때만 사용하도록 합니다.
후킹에 대해서는 구현 방법에 대해서 차후 기술 할 예정입니다.
많은 개발자분들은 후킹을 크랙이나 해킹에 사용된다고 부정적인 시각을 갖고 있습니다.
그러나 이용하기에 따라서 유용하게 사용됩니다.
물론 프로그램머 채널에 이용되기는 하지만...^^
제3자가 보기에 HOOK.DLL으로 이름을 설정하면 어플에서 후킹을 사용하는게 인지된다.
가능하다면 DLL 파일의 전혀 다른 이름을 사용하는게 좋습니다.
물론 메시지 스파이를 이용하면 금방 알아내겠지만...
*******************************************************************************삭제부 끝...
// DLL 파일의 처리 //
대부분 프리랜서들은 소스코드를 넘겨주는 계약을 할 때에 핵심적인
사용자 정의 함수를 *.DLL로 묶어서 배포합니다.
물론 이 DLL 파일은 디자인 타임이나 런 타임시에서도 공통적으로 사용됩니다.
그러나 디자인시에 DLL를 사용 할 때마다 임포트를 해주는 선언 할 때마다
귀찮은 작업이 반복된다.
이럴때는 별도로 DLL를 사용하는 유닛을 만들고 그 유닛의 *.dcu 파일을 다시
use문에 기술하면 됩니다.
// 입력 받은 문자열이 숫자인지 문자인지 판별하는 사용자 정의 함수
Function MySearch(S:String):Boolean;
var
find : Boolean;
i : Integer;
begin
find := True; // 판별자 초기화
// 입력 받은 문자열의 길이가 0 이상이면
if Length(S) > 0 then begin
// 글자열의 첫자 부터 문자열 길이까징 반복
for i := 1 to Length(S) do begin
// 입력 받은 문자열이 0에서 9가 아니면 판별자에 False를 설정
if not(S[i] in ['0'..'9']) then find := False;
end;
end else begin
find := False;
end;
Result := find;
end;
// 함수의 사용
var
Result:Boolean;
begin
Result := MySearch('123');
if Result = true then showmessage('숫자');
if Result = false then showmessage('문자');
end;
// 프로그램 개발, 소프트웨어 개발 ...//
이 글은 아직 미완의 글입니다. 이 글의 바램이 있다면, 고등학교 졸업 정도의
동등의 학력 소지자가 손쉽게 업무용 프로그램을 개발하기를 바랄뿐이다.
비록 체계적으로 글을 쓰지 않았지만 독자가 전체적으로 개관하여
안목을 기르게 된다면 이미 소기의 목적을 달성하는 것으로 봅니다.
// 개발자가 되기 까지~ //
고등학교 졸업 > 독학 > 해커(데커,크랙커) > 구속 > 독학 > 개발자
대학교 정보통신학부 졸업 > 소프트웨어 개발회사 입사 > 개발자
대학교 전산학부 졸업 > 개발자 양성기관 > 소프트웨어 개발회사 입사 > 개발자
대학교 전산학부 졸업 > 해외 유학 > 소프트웨어 개발회사 입사 > 개발자
= 주요 개발자 양성기관
1. 정보통신대학원대학교
2. (주) 비트컴퓨터 내 교육원
3. 삼성SDS 멀티 미디어 스쿨
4. 박영만 전산학원
5. (주)한국오라클 연수원
..
= 주요 소프트웨어 개발회사
1. (주)한글과 컴퓨터
2. 안철수 바이러스 연구소
3. (주)한국마이크로소프트
..
// 쉬어가는 코너 //
델파이 관련 개발자에게 가끔 홈페이지 디자인도 의뢰하는 경우가 있어서
몇가지 말씀 드리려 합니다.
홈페이지 디자인이나 아이콘 제작에 " Adobe Photoshop"을 많이 사용합니다.
포토 샵에서 디자인 작업을 하실 때는 메뉴에서 [이미지- RGB 색상 및 8비트 /채널]
을 선택하시고 작업을 합니다.
그래픽 디자인에서 레이어의 개념은 일종의 사각형의 유리 판을 상상하시면 아주
편리합니다. 특정 대상을 한정하는 외각 툴이죠. 판넬하고는 약각은...
사각의 레이어를 겹쳣을 때 위에서 내려다 보였을 때 시각적으로 보이는 부분이
디자인 이미지가 됩니다.
이렇게 디자인 작업을 완료하신 다음에는 현제 작업 파일을 [*.psd]으로 저장을
한다음에 메뉴에서 [파일 - 보내기 - GIF89a] 클릭하시고 [ 응용파레트 - 16칼라 ]를
선택하신다음에 파일 이름을 지정하면 됩니다.
웹에서 보이는 색상은 256 칼라로 표현 되며 포토샵에서는 웹 파레트라고 부릅니다.
위의 내용은 디자인 작업을 개발자가 작업을 했을 때, 웹에서 나타났을 때
원래 이미지가 달라져 보이는 것을 보정하기 위함입니다.
포토샵에서 글꼴을 편집 할 경우에는 포인트 단위보단 픽셀 단위로 표현하면 좋습니다.
// 프리랜서를 위한 마케팅 전략 및 전술 //
=소프트웨어 개발을 하고자 할 때는 프로젝트 계획시의 위험 변수가 무엇인지 미리 파악하고
그 해결 대안을 미리 마련하여 프로젝트가 위험에 직면할 때에 미리 대처하면 시간 효율을
높일 수 있습니다.
=모든 프로젝트 수행 계획에 있어서 성공인자 및 변수를 사전에 파악해야 한다.
[Key success factor]
// 쉬어가는 코너 //
" 줄 것은 늦게 주어라. 받을 것은 빨리 받아라"
= 4E : Energy, Energize, Edge, Execution
" 활력, 동기부여, 결단력, 실행 "
= 3요소 :
" 제품의 차별화, 원가선도, 집중 "
" 꿀벌은 벌꿀이나 설탕이 있는 곳에 모이고,
사람은 돈이나 희망(기대감)이 있는 곳에 모인다."
" 시장 점유율이 높아지면 시장 지배력이 증가한다. "
" 모든 사람에게 주어진 공평한 자원은 바로 시간이다. "
" 시장을 3분의 1이상 점유하게 되면 독점 상태가 된다. "
// 게임 소프트웨어의 방향... //
지금으로부터 2년전의 일입니다.
한국개발연구원(KDI) 소속의 한 박사님의 세미나를 청강한적이 있습니다.
논지는 부존 자원이 부족한 우리 나라에서 게임 소프트웨어 인력 양성과
투자는 바람직한 일이란 말을 했습니다.
저도 그렇지만 많은 개발자분들이 박사님의 말씀에 냉소적으로 반응했습니다.
그 시점에 이미 일본의 닌텐도 및 미국의 기업들이 게임 시장을 석권하고
있었기 때문입니다.
2년이 지난후 지금 MS에서 X-BOX를 출시하였고, 국내 게임 시장을 보면
실무에 능한 게임 개발자가 턱 없이 부족합니다.
게임 개발 회사의 CEO는 필요한 인력이 없다고 볼맨 소리를 하고
자사에서 신입 사원을 교육하고 양성하는 데 인색하는것이 사실입니다.
비용 때문에 그것이 불가능하고 유능한 개발자로 육성하여도 다른 회사로
스카웃 제의에 회사를 떠나 버립니다.
이론적 사고 방식으로 각 대학에서 인력 양성은 매우 어렵습니다.
그러나 실무의 개발자가 교수로 나선다면 해결책이 될 수 있습니다.
// 소켓 그리고 메모리 DB //
상당이 오랜 전의 일입니다. 시언어로 작성한 일종의 소켓 프로그램인데
서버에 접속된 클라이언트의 메모리 맵을 가져와 상대가
정상적 업무를 하고 있는지 겜을 즐기고 있는 지
감시하는 프로그램있었습니다.
어떻게 맹글었는지는 모르지만 대단한 교수님에는 틀림없다.
오라클 RDBMS가 뛰어난 점의 하나는 강력한 인터럽트 처리입니다.
여기에 절묘한 기술력이 집적되어 있습니다.
물론 DB 포맷이 잘 손상 안된다는 점도 있구여.
제가 오라클 DB의 HDD의 크래쉬가 발생 할 때
어떻게 손상되지 않는 지 매우 궁금합니다.
요즘 미국에서 시도되는 것이 메모리 DB 기술입니다.
사실 DB의 테이블 전체를 메모리에 전부 올린다는 것은
무모한 일인지도 모릅니다.
메모리 가격이 저렴하다는 전제로 약 2GB 정도에 올려 놓구
실험해 보는 것도 재미있을 것 같습니다.
한가지 방법이 있는 데,,,
DB의 인덱스 테이블 만을 메모리 올리면 많은 사이즈를 줄일 수 있습니다.
질의가 HDD가 아닌 메모리에서만 일어나게 하면 DB의 성능이 개선 될 수 있습니다.
즉, HDD의 억세스 빈도를 줄이는 게 기술인듯 싶다.
클라이언트에서는 먼저 서버의 메모리에 접근하여 질의한다음 찾은 메모리 상의
인덱스 테이블에서 레코드 위치 포인터를 반환 받은다음 HDD에서 가져오는 방법이다.
// 즐거운 프리렌서 //
개발자로서 프리렌서 쪽을 희망 하신다면 몇 가지 리스크를 고려하셔야 합니다.
프리렌서라 하면, 일반적으로 자유 계약직을 말하는 데 고도의 전문 지식을
가져야 합니다.
이것은 이미 프로젝트에 들어가기전에 여러분이 비슷한 유형의 프로젝트
수행 경험이 있거나 이미 솔류션을 갖고 계셔야 합니다.
요즘은 개발자가 부족하다 보니까 전혀 실무 경력이 없는 분이 프리렌서로
뛰어드는 경우도 있는 데, 위험 천만한 생각입니다.
프리렌서라면 족히 법을 잘 모른다고 하더라도 계약의 명장이 되어야 합니다.
협상(네고)의 대가란 쉬운일이 아닙니다.
프리렌서는 인맥이 튼튼하지 않으면 수입이 일정치 않아 금전관리를 철저히
하지 않으면 안됩니다.
프리렌서는 항상 체력 관리를 게을리 해서는 안됩니다.
프리렌서하면서 그 길은 순탄하지 않습니다. 가시 밭길 입니다.
미국이나 실리콘 벨리나 외국계 개발회사에서 개발 경력이 있다면 기존 고객과의
연결로 수입을 생각 할 수 있으나 그렇지 못한 경우 애환이 많습니다.
개발자를 등쳐 먹는 브로커도 만나고 귀한 시간과 정열을 바친 소프트웨어 개발
비용을 받지 못하는 경우가 허다합니다.
총 개발 비용에서 개발자가 수입을 3분의 1미만으로 얻기 마련입니다.
유능한 개발자라도 잘 못하면 그 재능을 이용 당하는 경우가 많으므로 좋은
사람과 인연을 맺도록 해야합니다.
우리 나라에서 개발 기술이 일반화 된 이유는 프리렌서의 불규칙하고 일정하지
않는 수입원 때문에 브로커들이 이것을 악용하여 불평등한 조건을 제시하게 됩니다.
이것을 이용하여 개발 기술을 습득한 브로커는 다시 실무 경력이 짧은 개발자에게
개발 기술을 습득하는 기회라고 제시하고 개발자에게 지급하는 인건비를 낮추는
기회로 사용합니다.
결과적으로 우리 개발자가 자신의 무덤을 스스로 판 결과는 아닐까요?
// 소프트웨어의 품질 //
소프트웨어 개발은 사실 인터페이스나 의도하는 바대로 정확한 결과 값이 나오고
기간 안에 납품만 하면 그것으로 끝납니다. 결과만 좋으면 되는 것이다.
가는 길이 여러 갈래 길이지만 치명적인 버그만 없으면 됩니다.
최종 사용자는 품질의 정도를 올바르게 지각하지 못합니다.
그런데, 개발 회사의 재정이 넉넉하여 실무 경력이 7년 이상인 분들에게
최상의 성능을 가진 소프트웨어 개발을 의뢰 하면 놀라운 경험을 하게 됩니다.
그 특징을 몇 가지 제시하고자합니다.
첫째, 프로그램이 물리적 메모리를 효율적으로 사용합니다.
즉, 메모리 누수가 없습니다.
둘째, 실행 속도가 매우 빠릅니다. 로직이 견고한가의 여부에 따라서 체감 할 수있을
정도로 실행 속도의 차이를 느끼게 됩니다.
세째, 소스 코드가 유지 보수하기 쉽게 되어 있습니다.
네째, 소스 코드에서 함수의 반복이 최소화 되어 있습니다.
다섯째, 실행 파일의 크기가 작습니다.
여섯째, 인터페이스가 사용자 위주로 되어 있으며 장시간을 사용해도 피로감이
적습니다.
마지막으로 버그 리포트에 대한 처리와 대량 배포시의 시기 적절한 처리 기술도
노하우입니다.
특히 데이타 베이스 관련 프로그램은 질의에 대해 빠른 응답은 최종 사용자로 하여금
알 수 없는 강한 쾌감을 느끼게 합니다.
// 흐름도에서의 조건문의 처리 //
델파이에선 조건문의 실행 방향을 다음과 같이 처리하시면 됩니다.
var
MyKey : boolean;
begin
// MyKey := 0;
// MyKey := 1;
MyKey := True;
MyKey := False;
// 위 판별자를 적절히 활용하면 로직의 방향을 통제 할 수 있습니다.
end;
// 배열, 문자열에 대한 이해 //
배열에서 각 배열요소에 대한 값은 자료의 포인터와 같습니다.
문자열에서 각 문자 요소에 대한 값은 자료의 포인터와 같습니다.
var
ars : Array[1..10] of Char;
s : string;
begin
s := 'abcdef';
// s[1] = 'a';
showmessage(s[1]);
// s[2] = 'b';
showmessage(s[2]);
// s[3] = 'c';
showmessage(s[3]);
// s[4] = 'd';
showmessage(s[4]);
end;
// 프로젝트 메니저로서의 중국의 소프트웨어 시장 개척 //
요즘은 프로젝트 메니저가 개발에 전념하기는 하지만 중소 규모의 회사는
영업 및 마케팅 업무까지 해야만 합니다.
영업 할 때 주의 할 점은 여러분이 전업을 하지 않고 끝까지 프리렌서 및
개발자로 생존하려면 마케팅에 대한 개발 경력은 인정되지 않으므로
주의하셔야 합니다.
실무에서 현장 개발자가 필요하지 마케터가 필요한 것은 아닙니다.
여기에서 경영자로서 중국 시장 개척에 대한 언급을 하렵니다.
첫째로 중국 문화에 대해서 이해해야만 합니다.
미국이나 일본과는 달리 중국에서는 업체간 계약서는 아무런 의미가 없는
휴지에 불과합니다. 계약 위반에 대한 위약금은 통하지 않습니다.
중국과의 거래는 커낵션이나 신의, 알음알이에 의해서 행해지게 됩니다.
둘째로 중국은 사회주의 국가입니다. 업체 회사 사장이나 공장장과 모든 계약이
완료되었다 하더라도 관할 당의 관리자의 승인 없이는 아무일도 가능하지 않습니다.
세째로 조선족의 통역자를 사용해서는 안됩니다.
조선족의 통역은 우리 나라의 문화하는 달리 완벽한 통역을 기대할 수 없고
재멋대로 통역하므로 한국인을 중국어 교육을 시키는 등의 즉 자기회사 직원을
활용하는 것이 좋습니다.
네째로 중국은 90% 이상 불법 복제가 성행하는 나라입니다.
따라서 서버가 있어야 프로그램이 구동되는 특수한 소프트웨어 판매 및 공략이
좋습니다.
// 윈도우 보안체계와 국가 안보 //
- 님다 바이러스 피해를 중심으로 -
님다 바이러스 종류가 발견 되었을 때, 몇 명의 개발자 및 백신 프로그램을
만드는 업체만이 소리를 높여 그 위험성을 알려왔다.
그러나, 그것은 극 소소일 뿐이었다.
대다수의 보안 담당자들이 자사의 방화벽 및 보안 체계를 믿고 효과적으로
대응하지 못했다. 그런데 특이한 점은 PC TO PC 즉, 직접적인 IP접근에
속수 무책이었다.
이 바이러스군을 누가 만들었는지 알 수 없지만 컴퓨터 실력을 뽐내거나
일시적인 흥미가 아닌 불순의 의도가 개입된 것으로 보는 시각도 있다.
그것은 각종 보안 체계를 무력화 시킨 것이다.
완벽한 보안 체계는 없다는 것을 명심하고, 최선의 노력을 해야겠다.
// 개발자의 자격기준 //
1. 이공계대학원 졸업 실무경력 3개월이상
2. 이공계대학교 졸업 실무경력 1년이상
3. 이공계 전문대학 졸업 실무경력 1년6개월이상
4. 고등학교 졸업 실무경력 4년이상
// 개발검토자 자격기준 //
1. 이공계대학원 졸업 실무경력 6개월이상
2. 이공계대학교 졸업 실무경력 3년이상
3. 이공계 전문대학 졸업 실무경력 5년이상
4. 고등학교 졸업 실무경력 6년이상
// 개발검증자 자격기준 <===프로젝트 메니저 //
1. 이공계대학원 졸업 실무경력 2년이상
2. 이공계대학교 졸업 실무경력 4년이상
3. 이공계 전문대학 졸업 실무경력 6년이상
4. 고등학교 졸업 실무경력 8년이상
// 윈도우 운영체제의 보안 //
윈도우 운영체제의 백도어 존제는 여러 논란이 되어 왔지만 아직까지
명확하게 밝혀진 사실은 없습니다.
러브레터 바이러스가 처음 발표 되었을 때,
웹 브라우저 연동을 위한 비쥬얼 베이직 스크립트가 레지스터리를 마음대로
조작할 수 있다는 실례를 보여줍니다.
윈도우 운영체제를 사용하는 컴퓨터의 추적은
첫째로 CPU의 고유인식번호,
둘째로 HDD의 고유일련번호,
세째로 프로그램의 CLASS ID,
네째로, LAN CARD 고유번호 등이다.
지금의 윈도우 운영체제의 보안은 사용자 정의로 설정하게 되어있으며,
보안이 풀렸을 경우 원격지에서 포맷까지 가능하게 되었습니다.
자바 애플릿, 비쥬얼베이직 스크립트에서 의해서 함수 호출이 그것입니다.
특정 홈페지를 검색 할 때에 입장 버튼을 클릭하는 순간 클라이언트의
보안을 해제하도록 이벤트에 스크립트를 넣는 방법이 있다.
얼마전부터 클라이언트의 무결성 검사 및 인증 작업을 위한 테스트를 해왓다.
그 실례가 스파이웨어들의 활동이었다.
이것은 강력하고도 손쉽게 고객 정보를 빼가는 역할을 햇다.
// group by 그리고 Join //
begin
Query.close;
Query.sql.clear;
Query.sql.add('SELECT L.Field1, L.Field2, L.Field3, SUM(M.Field3) Field3 FROM MyTable L, MyTable2 M WHERE L.Field1 = :Field1');
Query.sql.add('AND L.Filed1 = M.Field1 GROUP BY L.Field1,L.Field2,L.Field3 ');
Query.parambyname('Field1').asstring := Input.TXT;
Query.open;
end;
// INI 파일의 사용 및 응용 //
*.ini 파일은 수 많은 업무용 프로그램에서 활용됩니다.
원래 윈도우 3.1에서 운영체제 기본 시스템 파일로 사용되었지만
윈도우 95 운영체제에서는 레지스터리라는 일종의 DB로 통합되었습니다.
그러나 각종 금융 업무용 프로그램에서 일차 암호화나 각종 환경 설정으로
이용됩니다. INI 파일은 text 포맷 파일입니다.
var
MyINI : TEXTFILE;
MyStr : string;
begin
// MyINIFILE.INI는 HDD에 존제하는 파일 이름
// 외부 MyINIFILE.INI 파일을 MyINI에 할당
AssignFile(MyINI,'MyINIFILE.INI');
{$i-}
Reset(MyINI);
{$i+}
if ioresult <> 0 then
application.messagebox('프로그램 실행에 필요한 파일이 존제하지 않습니다.','시스템오류',mb_ok+mb_iconstop) else
begin
readln(MyINI,MyStr); // MyIni 파일의 내용을 MyStr에 읽어드림
end;
end;
// 빈번한 SQL을 줄이는 법 그리고 1대1 대응을 위한 테이블 비교표 //
이 방법은 여러 가지로 활용이 가능하므로 필수적으로 이해하시는 것이
좋을 것 같습니다.
만약, 문자 '1'를 검색하려 할 때, 사용자 정의에 테이블에 문자 '1'에
대한 일대일 대응 관계로 beta라고 설정해 놓으면 문자 1을 검색하여
찾게 되면 몇번 째에 찾았는지 첨자를 반환받아 Alpha를 반환 받게 된다.
var
MyVIEW: TListView;
MyITEM: TLISTITEM;
begin
MyITEM := MyVIEW.ITEMS.ADD;
// 질의를 하여 질의 결과 레코드를 리스트 아이템에 할당
MyQuery.close;
MyQuery.sql.Clear;
MyQuery.sql.add('SELECT * FROM MyCode ORDER BY LCODE');
MyQuery.open;
if MyQuery.recordcount > 0 then
begin
repeat
MyITEM.SUBITEMS.ADD(MyQuery.Fieldbyname('LCODE').asstring);
MyITEM.SUBITEMS.ADD(MyQuery.Fieldbyname('RCODE').asstring);
MyQuery.Next;
Until MyQuery.EOF
end;
end;
// 사용자정의 함수 : 리스트 뷰내의 아이템 검색
function MyFind(const MyStr : string) : integer;
var
i : integer;
find : boolean;
begin
if MyView.items.count > 0 then begin
i := 0; find := false;
repeat
if MyView.items[i].subitems.strings[0] = MyStr then find := true else
inc(i);
until (find) or (i > MyView.items.count-1);
if find then result := i else result := -1;
end else result := -1;
end;
var
i:integer;
begin
// LCode 검색 결과 참이면 리스트 뷰에 몇 번째에서 찾았는지 그 첨자 값을
// 반환 받고 이 첨자 값으로 대응되는 Rcode 값을 반환 받음.
i := MyFind('A');
Result := MyView.items[i].subitems.strings[1]; // Rcode 값 반환
end;
위 소스코드를 보시면 굉장히 복잡하시리라 생각 됩니다.
단, 한번의 질의 결과 값을 가지고 반복적인 질의를 피하고 대응 값을
반환 받을 수 있습니다.
위 소스 코드의 활용과 용도는 중급 이상 개발자만 이해가 되실 겁니다.
입문하신 분들은 기억해 두시면 언젠가는 필요하실 겁니다.
// RS232C 그리고 시리얼 포트의 제어 //
개발자님들이 다양한 프로그램을 개발하시다 보면 접하는 게
시리얼 포트의 제어입니다.
이것은 각종 산업용 기기를 제어하는 데 사용하며 RS232C는 제어기가 컴퓨터로 부터
즉, 케이블 길이가 2미터 이내의 장치를 제어하는 데 사용됩니다.
예를 들면, 원격 모뎀 제어, 전광판제어, 무선기기 제어 등등
보통 통신 포트의 버퍼에는 버퍼 카운터 증가에 따라서 STX-USER DATA-ETX
형태로 전달 됩니다. 이것을 HEX 코드로 보면 [02]user data[03] 형식으로
됩니다.
이것을 가져와서 메모장이나 스트링렬에 뿌리게 되면 그 값에 대한 아스키
문자의 코드 값을 가지게 됩니다.
여기에 필요한 내용은 다음과 같습니다.
var
I,ma: integer;
ms : string;
begin
// 십진수 코드 값을 아스키 문자 값으로 '8' := #56
// ms := char(56);
// HEX 값을 아스키 문자 값으로
// ms := char($38);
// 아스키 문자 값을 십진수 코드로 변환 #56 := '8'
// i := ord('8');
// HEX 값을 십진수 코드로 변환 #56 := $38
// i := byte($38);
(* for ma:= $01 to $10 do
begin
ms := char(ma);
showmessage(ms);
end;
for ma:= 1 to 10 do
begin
ms := char(ma);
showmessage(ms);
end; *)
// 메시지 창
// showmessage(inttostr(i));
// showmessage(ms);
흥미로운 것은 아스키 코드 값을 인터베이스 디비에 저장해 보도록 합니다.
필드를 CHAR 타입으로 하고 델파이 스크립트에서
var
i:integer;
begin
for i:= 1 to 254 do
begin
MyQuery1.close;
MyQuery1.sql.clear;
MyQuery1.sql.ADD('INSERT INTO ascii_ID ( CODE ) VALUES (:CODE )');
MyQuery1.parambyname('CODE').asstring := char(i);
MyQuery1.execsql;
end;
end;
위에서 char(ma)의 값을 SQL문에 변수로 할당하면 됩니다.
별루 어려운 것은 없져?
****************************************************************************
// 상대방 컴퓨터의 보안을 해제하는 방법? //
1. 폭탄 매일러 프로그램을 사용하여 님다, 서캠, 러브바이러스의 기법을 이용하여
바이러스 감염 매일을 상대에게 지속적으로 보냄
2. 일반 유틸리티에 보안 해제 루틴을 넣은 다음 상대에게 다운 받게하고
실행하게함 .
3. 특정 홈 페이지의 들어가기 버튼 클릭 이벤트에 보안 해제 스크립트를 포함시킴
*****************************************************************************
// flash를 사용 할 때 해상도의 조정 //
플래쉬를 사용 할 때 해상도 문제로 고생을 많이 했습니다.
=== 플래쉬의 preferences 설정 ===
color depth: match screen
resolution:screen dpi
smooth에 체크하지 말것
= gradients on clipboard =
quality : best
== Publish settings ==
= html =
dimensions:match movie
quality:high
그리고 16칼라로 사용될 이미지 파일을 16비트 칼라이상으로 설정하여
포맷변환하면 색상을 잃어 버림으로 주의해야 한다.
// 개발자에게 가장 중요한 점 //
팀 프로젝트가 아닌 경우에는 제일 중요한 점이 납품 기간내에 개발하여
완료하는 것입니다.소프트웨어 품질 같은거는 전혀 고려 대상이 아닙니다.
중소 규모의 개발 회사의 사장님들은 프로그램 실행속도, 독특한 기능
같은 것에는 별루 관심이 없고 기간안에 납품만 하면 그것으로 끝납니다.
또한,아무리 좋은 소스코드를 보며 연구한다하더라도 자기의 것으로 만드는
일은 쉽지가 않으므로 어려움이 있겠지만 실제로 프로젝트 단위로 임의로 만들어
보는게 좋습니다. 일단 시작해 보십시요. 팁과 각종 아이디어는 차후의 고려
대상입니다.
그러나 외국계 팀 프로젝트에서는 합리적인 개발기법에 의하여 진행되게 됩니다.
프로젝트 단위 내에서 소스코드는 세가지 종류의 유닛 단위로 구성합니다.
이것은 객체 지향적인 방법론을 응용한 것입니다.
전역변수를 모아 놓은 유닛, 공통함수를 모아놓은 유닛, 해당 유닛
// 보안지침서 //
= 네트워크 프로토콜 중에 NETBEUI를 사용하지 말 것.
= 네트워크 설정에서 파일 공유 기능을 사용하지 말 것.
= 개발작업은 데스크 탑에서 하도록하고 노트북 사용을 지양할 것.
노트북은 잔고장이 많고 HDD 크래쉬가 심할 경우가 있음
= 개발중인 컴퓨터에서는 이 메일을 열람하지 말 것.
= 개발 작업을 하는 컴에서는 각종 해킹 툴이나 백도어를 찾는 프로그램을
실행하지 말 것.
= 보안관리자를 선임하고 보안지침을 마련하여 체계적으로 대응할 것 .
= 국가보안 기밀, 행정기밀1급에 준하는 컴퓨터에 윈도우 운영체제를 설치하지 말것
부득이하게 윈도우 운영체제를 사용할 경우 인터넷 망에 물리적으로 절단 할 것.
인터넷으로 부터 격리 할 것.
인터넷의 연동된 서버 컴퓨터등의 자료는 낮은 보안등급 자료를 관리하도록 할 것.
= 출입제한구역을 마련하고 전산 담당 및 보안 인가자외에는 전산실 출입을 금할 것
= 정기적인 백업 지침을 만련하고 실시할 것.
= 보안 1급에 준하는 인가자 즉, 행정기관의 장이라 할지라도 전산관리자와 동행하여
보안구역 및 시설을 이용하도록 하고 단독으로 전산실 출입을 하지 말 것.
// 프로젝트 진행 중의 노트북 컴퓨터의 관리 //
프로젝트를 진행하다 보면 예기치 않는 일이 발생하여 프로젝트를 위협하게 됩니다.
예를 들면 개발자가 노트북 컴퓨터를 잃어 버리거나 컴퓨터의 HDD가 크래쉬가
발생하여 중요한 소스코드가 손실되는 경우가 생깁니다.
노트북은 아주 민감하므로 전원을 넣은 상태로 이동해서는 안됩니다.
또한 시스템 종료가 아닌 화면보호기 작동으로 인한 종료된 상태는 마치
전원이 꺼진 것처럼 생각되나 이대로 이동하거나 움직이면 HDD에 크래쉬가
발생하여 데이터를 잃어 버리는 경우가 있습니다.
이 때는 HDD의 PCB를 분해하여서는 안됩니다. 분해하게되면 HDD의 기계적인
정보를 잃게 되어 버립니다.
HDD의 FAT는 종류가 많습니다. FAT, FAT16, FAT16-1,FAT, FAT32, FAT32-1
따라서, 어떤 응용프로그램을 잘못 실행하게 되면 HDD의 크래쉬가 발생하게 됩니다.
FAT가 다른 경우 이미 저장된 섹터엔 자료가 저장되면 안되는데 갱신이 발생하여
두 어플이 동시에 한 섹터의 자료를 사용하게 됩니다. 이런 심각한 버그는 지금은
패치가 되어 있지만 가끔가다 그런일이 발생하게 됨으로 컴퓨터에 프로그램을
설치할 때는 주의하시기 바랍니다.
또한 HDD의 내부 공간은 진공 상태로 먼지가 없는 클린 룸에서 작업을
해야하므로 주의해야합니다.
프로젝트의 모든 자료는 데스크탑에 보관하도록하고 백업을 게을리 하지
말아야합니다.
// HDD의 복구 //
HDD에 이상이 생겼을 때는 전원을 차단하고 절대로 노턴유틸리티 ndd.exe,
finaldata.exe, revival.exe 등 HDD복구 프로그램을 실행해서는 안됩니다.
제일 먼저 동일 제품의 PCB를 교환하여 HDD를 인식 시킵니다.
전원을 먼저 넣기 전에 헤더가 떨어져 나갔는지, 만약 헤더가 떨어져서
디스크 룸 안에서 돌아다닌다면 클린룸에서 HDD의 디스크를 개방한다음
온전한 HDD으로 디스크를 교체합니다.
HDD는 컴퓨터에 슬래이브에 인식 시킨다음 같은 운영체제상에서 복구
작업을 수행합니다.
먼저 논리 드라이브가 인식되면 논리드라이브를 선택하고 파티션 찾기를
해야합니다.
만약 파티션을 못찾을 경우나 논리드라이브 인식이 안될 경우에는
물리디스크 옵션을 선택하고 포맷찾기를 합니다.
찾아진 포맷은 플랫폼에 맞게 선택하며 복구 진행을 하면 됩니다.
HDD의 복구는 먼저 기계적인 손상을 해결한 다음에 복구 작업을
해야합니다.
// 개발자와 그래픽 디자인 //
중소 규모의 개발회사에 입사하게 되면 개발자가 전혀 다른 분야의 일을 하기
마련입니다. 그중의 하나가 그래픽 디자인 입니다.
그래픽 디자인은 하드웨어 영향을 많이 받습니다.
예를 들면 비디오 카드의 메모리가 많을 수록 좋고, 만약 비디오 메모리를
메인메모리의 공유 메모리를 사용하게 되면 원하는 결과를 얻을 수 없습니다.
------------------------------------------------------------------------
=== 삭제부 시작
// 소켓 프로그램의 로직 //
초급 개발자들이 궁금해하고 소스를 필요로하는 소켓프로그램에 대한
로직을 기술하려고 합니다.
이 원리를 바탕으로 각종 툴로 구현하시길 바랍니다.
먼저 THandle의 인스턴트 변수를 정의하고 파일맵으로 사용합니다.
필요한 사용자 정의 함수를 작성합니다.
1. 자료읽기 함수정의
2. 자료쓰기 함수정의
3. 메모리 맵 설정 함수 정의
4. 메모리 맵 해제 함수 정의
즉, 핸들의 인스턴스 변수를 가지고 파일의 시작 포인터를 얻은 다음
메모리 맵을 이용하여 맵핑 작업을 합니다.
파일 동기화를 위해 클라이언트에서 파일 정보를 요청합니다.
Server 에서 전송된 파일과 Client에 있는 파일을 비교한 정보를 출력하고
// 프로젝트 실무에 사용되는 서식의 응용 //
* 업체상담보고서의 구성요소 : 프로젝트명, 거래처, 주소, 부서명, 일자,
담당자, 제안서 제출일, 전화번호, 참석자명단, 협의내용, 담당자의견,
특기사항,
* 개발요청접수대장의 구성요소 : 접수번호,접수일자, 업체명, 프로젝트명,
거래처 담당자, 전화번호, 응대자, 주요내용, 비고,
* 개발검토서의 구성요소 : 프로젝트명, 일자, 개발담당자, 업체요구사항,
검토결과, 특이사항, 의견
* 발주서의 구성요건 : 업체명, 담당자, 전화번호, 주소, 품명, 규격,단위,
수량,단가,금액,비고, 납품장소, 납품기일, 운반조건, 대금지불방법,
포장조건, 검수, 부가세, 일자, 발주자 인적사항
==== 삭제 부 끝
--------------------------------------------------------------------------------------
// 개발자와 인식자(식별자) //
수 많은 프로그램들을 보면 비록 복사방지 장치가 되어있지 않더라도
프로그램과는 별로 관련없는 인식자가 마니 사용됩니다.
이것은 프로그램 채널이라는 것으로 불리는 것으로 전문 개발자 사이의
오래된 전통이다.
이것은 특정 개발자들의 취향으로써 여러가지 목적으로 사용됩니다.
물론 레지스터리를 많이 이용하기는 하지만, 특정 파일이 존제하는가
여부와 특정 파일의 생성 날짜와 버전을 가져와 인식자로 사용되는
경우도 있습니다.
또 하나는 HDD의 고유번호와 LAN카드 고유번호, CPU고유번호 등을 사용하여
독특한 식별 번호를 생성하기도 합니다.
// 프로그램 배포시 주의 할 점 //
프로그램 개발 환경의 운영체제에 유의해야합니다.
윈도우 운영체제는 한가지라고 생각하시겠지만 수 많은 종류의
버전이 존재합니다.
심지어는 핵심 커널및 MS-DOS의 핵심부까징 수정된 경우가 있습니다.
어제까지 존제하던 함수가 어느날 갑자기 사라지기도 합니다.
그래서 개발된 프로그램의 실행 환경의 운영체제의 버전의 빌드넘버가
매우 중요합니다. 최종 사용자가 인터넷에 연동되어 있다면 어느 정도
윈도우 운영체제에 변화가 있다고 추정 할 수 있습니다.
만약, 전국적인 규모로 대량으로 프로그램을 배포햇을 때, 버그 리포트를
받아보면, 모두들 잘 사용하는 데, 특정 환경에서 알 수 없는 오류를
많이 발생됩니다. 만약, MS에서 윈도우 운영체제를 이용하여
특정 개발회사를 망하게 하려한다면 그것은, 어려운 일이 아닙니다.
가끔, 시퍼런 화면의 메시지창에서 보면
" 이 프로그램은 잘못된 연산을 하여 종료됩니다.
이 문제가 지속되면 이 프로그램의 개발회사에 문의하십시요."
일부 특정 컴퓨터에서 실행이 되지 않으면 메모리와 HDD를 교체하여 봅니다.
불량 램을 사용한 경우가 있습니다.
// 전문 정보통신 인력의 양성 //
현제의 우리 나라는 웹디자이너와 웹마스터 양성이 포화 상태입니다.
대학교에서 효율적인 인력양성에 힘쓴다 하더라도 실무에 도움되는
인력의 양성은 쉽지가 않습니다.
많은 개발 기술은 특정 기업에 편중되어 있고, 고스란히 사장되어 있기
때문입니다. 많은 개발 업무가 창의성을 필요로 하나 합리적인 개발 기술의
발달이 필요로합니다. 이것을 위해서 기업의 올바른 판단이 요구되며
산학협력이 매우 중요하다고 하겠습니다.
현제 소프트웨어 개발자 양성의 비결을 갖고 있는 것은 해당 기업이겠으나
많은 기업들이 부도로 사라져가고 있는 것이 현실입니다.
// 소프트웨어 개발의 발주및 수주하는 과정 //
소프트웨어 개발의 발주 및 수주하는 것은 건설회사와 유사합니다.
즉, 개발자를 보유하지 않아도 서류상으로만 확보하고 정보통신업체 자격을
얻은 업자가 제1도급자로 수주를 받게 됩니다.
이 제1도급자는 시세 차익을 얻은 후에 제2도급자에게 하도급합니다.
제2 하도급자 역시 제 하청을 주어 최종적으로는 프리렌서 그룹이나
개발 전문 기업이 최종적으로 개발하게 됩니다.
이 과정에서 최종 개발하는 기업을 제외한 기업들은 개발 환경을 갖추지
않고 서류상, 행정상으로 개발자를 확보할 뿐입니다.
그러나 이것은 일반적인 경우이며 실제적인 경우는 학연, 지연등 인맥에 의하여
발주 및 수주가 이루어 지고 있습니다.
// 델파이의 효용성 그리고 미래 //
델마당의 게시판에 보면 가끔까다 MS 영업부서 직원분들이나 그리고
초보 개발자들에 의해서 비쥬얼 베이직과 비교해서 델파이를 비난하거나
평가 절하하는 경우가 많습니다.
필자는 개인 사견임을 전제로 델파이가 강력한 전문가용 툴이라고 주장하고 싶습니다.
필자의 첫 프로그래밍 시작은 FORTRAN, GW-BASIC,매크로어셈블리어, C++입니다.
만약, 델파이를 개발한 기업인 볼랜드가 망하더라도 델파이 그 자체로는 효용성이 있다고
생각합니다. 클리퍼가 그러했듯이 오랜 동안 개발자들의 사랑을 받을 것이라고
확신합니다.
초보 개발자들은 델파이에 입문 할 때, 자료의 빈곤함을 느끼게 됩니다.
기이하게도 델파이 소스코드가 있는 사이트는 일반 검색 엔진으로 잘 검색되지 않습니다.
외국 개발자가 자기만의 기술을 농축하여 소스 코드를 공개해 놓은 경우가 있는 데,
일반 검색 엔진으론 검색되지 않습니다.
우리 나라에서는 자기만의 노하우를 공개한 경우는 매우 적습니다. 이것은 전통적인
성향이라고 생각됩니다.
고의적인 것인지는 모르겠으나, 와레즈 사이트는 불법이라고 하지만 델파이 개발자 중
전문가 집단이 고급 소스 코드를 공개한 경우와 해킹 툴처럼 강력한 어플을
만들어본 전문가들 중에도 소스 코드를 공개해 노은 경우가 있습니다.
초보개발자들은 처음에 업무용 소스코드에 접근하기 쉽지가 않겟지만
엄청난 규모의 인터넷 망에서 찾다보면 자료 검색의 묘미를 알게되며 이제는 분석할
시간이 없을 정도로 소스코드를 모을 수 있습니다.
델마당, 델파이코리아, 한국델파이개발자그룹 등을 활용해도 전문가 수준의 실력을
얻을 수 있고, 또한, 로직의 묘미를 체득하면 비쥬얼 베이직, 파워빌더에서도 자유자재로
구현 가능할 것입니다.
// ERP (전사적 자원관리 ) //
시스템 통합(SI)업체에 근무하다 보면 이 용어를 많이 듣게 됩니다.
원래 이러한 용어들은 산업공학과 전공서적들을 보시면 쉽게 발견 하실 수
있습니다. 전사적 자원관리는 구현하는 데 많은 돈과 시간을 필요로 합니다.
그래서, 연간 매출액이 100억 이상인 곳에서 추진하시길 바랍니다.
기업의 경영 원칙은 최소의 투자로 최대이윤획득입니다.
어떤 어리석은 경영자는 남이 하니까 나도한다는 식의 사고 방식을 갖고있습니다.
전산화 않더라도 기업 내부에서 생산성 향상을 위해 부단히 노력합니다.
전사적 자원 관리를 하더라도 생산성 향상은 3퍼센트 이내로 제한적인 경우가
많습니다. 부가적으로 위험 부담을 감수해야합니다. 만약, 부분적인 결함으로
전체적으로 업무가 마비 될 수 있으며, 프린터의 소모품 컴퓨터 유지보수, 서버관리
비용등 부차적인 지출이 발생합니다.
요즘은 작은 소기업을 위한 ERP 패키지가 생산 되기도 하지만 아무래도 기업에 맞게
수정하려면 많은 돈이 소요됩니다.
// 네트워크보안 그리고 NT4.0 그리고 funlove.4099 virus program //
일반적으로 NT4.0에서는 각각의 파일에 대하여 소유권이 있습니다.
그런데, funlove 바이러스 프로그램에 감염된 상태에서 관리자모드로 로그인
즉, Administrator란 아이디로 로그인하면 모든 파일의 접근 권한을
everyone으로 변경시켜버려 순식간에 guest까지도 시스템에 접근
할 수 있습니다.
정기적인 바이러스 체킹으로 각종 회사 기밀이 노출 되지 않도록
서버 관리자는 주의하시기 바랍니다. 악의적인 해커가 타켓 서버에
침입하려 할 때 펀러브바이러스.4099의 변종 바이러스는 해킹을 위한
사전 도구로서 사용 될 소지가 있습니다.
이 글을 열람하시는 서버관리자는 자기 서버에 이 바이러스가 감염되었는지
확인하시기 바랍니다.
// C에서의 폼 실행 원리 //
C코딩을 하신 분들은 이해가 되 실 겁니다. 즉 창이 보여 줄 때는 무한루프가
걸려있습니다. 그래픽 처럼 폼을 구현하면 한번 실행되고 사라져 버립니다.
전역 변수를 제외하고는 그리기 이벤트가 계속 발생해야 폼 형태가
유지 되는 겁니다.
// 고급 디자이너를 위한 보정작업 //
모니터의 배경색은 완전한 검정색이 아닙니다. 표준 색상표를 기준으로
모니터 색, 그리고 그래픽 툴 프로그램의 색상 그리고 프린터 인쇄물의
색상이 정확하게 일치해야 합니다.
광원의 삼원색 RGB으로 구현한 색상, 색상의 삼원색 RYB으로 구현한
색상, 그리고 시각적으로 인지하는 색상의 조합이 일치 되도록
색상 보정 작업을 합니다.
// 비쥬얼 베이직에서의 런타임라이브러리 //
비쥬얼 베이직에서 런타임 라이브러리가 몇가지 있습니다. 그 예로
msvbvm60.dll 같은 것이 있다. 실은 1메가 바이트가 넘는 크기 때문에
투덜거리는 개발자도 많지만 이러한 DLL은 사실 우리가 코딩하다 보면
반복적으로 중복되는 함수들을 모아 놓은 것이다. 물론 여기에 포함된 단
몇개의 함수만 사용된 경우도 있습니다. 이렇게 반복되는 함수를 한 곳에
모아 놓지 않으면 각 모듈별 지루하게도 소스코드 내에서 반복되거나 참조하게
될 것입니다. 클래스들을 한 곳에 모아 필요 할때만 참조하도록 하는 것이
괜찮은 생각인지도 모릅니다.
// 델파이 소스코드를 비쥬얼 베이직 소스 코드로의 포팅 //
일반적으로 어셈블리어나 기계어는 CPU 종류에 의존 됩니다.
그리고 C언어나 C++은 플랫폼, 즉 운영체제에 상관 없이 소프트웨어를 이식시키기
위한 목적으로 사용됩니다. 이것은 소프트웨어를 다양하게 판매가 가능하다는 것을
의미하며 부가 가치를 높이는 일일 것입니다.
델파이는 CPU가 인텔인80x86 계열과 알파 칩 계열의 소스코드를 생성하는 윈도우용
개발툴입니다. 윈도우라는 운영체제에 의존합니다.
kylix는 lynux라는 플랫폼에서 소프트웨어를 개발하는 툴이지 윈도우용이나 유닉스용
툴이 아닙니다. 그리고 리눅스에서의 실행파일이 유닉스에서 실행되라는
보장이 없습니다. 크로스 컴파일러나 아니면 에뮬레이터가 필요하겠지요.
델파이 소스코드를 비쥬얼 베이직으로 포팅하는 것은 차라리 소스코드의 로직을
이해한 후, 새롭게 코딩해버리는 것이 빠를 수 있습니다.
일일이 소스 코드를 분석하고 비슷한 함수를 찾아 포팅하는 것이 시간이 많이 걸릴 수
있습니다. 물론 두가지 툴에 전문가라면 쉬운 일이 될 수도 있겠지요.
그런데 또 한가지 방법은 델파이에서 사용된 사용자 정의 함수나 공통 함수를
DLL형태로 만들어서 비쥬얼 베이직에서 임포트해서 사용하는 방법도 좋습니다.
그러나 DLL 파일이 운영체제에서는 인식이 되지만 사용하는 방법이 다릅니다.
비쥬얼 베이직에서는 스텍을 사용하지만 델파이에서의 DLL은 인자전달 방식을
사용합니다. 따라서 파라미터 전달 관계로 임포트하여 사용하는 데 어려운
점이 있습니다. 이렇게 한이유는 우선 MS의 저작권을 피하기 위함이고 또한
DLL사용시 실행속도를 높이기 위함입니다.
결론적으로 우선 델파이로 개발된 응용프로그램의 로직을 파악하고,
같은 로직으로 비쥬얼 베이직에 맞는 컴포넌트를 만들고 새롭게 코딩하는 것이
쉽고 빠르다고 하겠습니다.
델파이에서 올바르고 바른 코딩 습관은 그 방식 그 로직대로 쉽고 빠르게 다른 툴로
포팅이 가능합니다.
우선 플랫품이 다른 경우는 C언어 계열이 조으며 윈도우 운영체제에서는 다른 툴로
쉽게 포팅 할 수 있도록합니다.
// 즐거운 윈도우 프로그래밍 //
윈도우 프로그래밍의 기초는 코딩 순간 순간에 저장 버튼을 수시로
누르는 것입니다. 이것은 매우 중요합니다.
----------------------------------------------------------------------------------------
윈도우 운영체제에서의 코딩은 수시로 저장 버튼을 클릭해야 합니다. 현제 작업의 내용을
수시로 저장하여야 합니다.
------------------------------------------------------------------------------------------
노련하고 직업적인 개발자는 이것을 주의합니다.
필자의 경험으로는 300라인 이상 코딩을 하고나서도 저장 버튼을 누르기
전에 알수 없는 오류, UPS 미 설치로 인한 갑작스런 정전이나 알 수 없는
기타 원인으로 컴퓨터가 폴트되어 처음부터 다시 코딩해야 하는
경우가 생겨서 허탈해 하는 개발자를 많이 보았습니다.
처음 부터 다시 코딩하면 되지만 귀한 시간을 낭비했고, 100퍼센트 원래대로
코딩하기가 쉽지 않습니다. 이것은 습관 문제인데, 여러분이 전문 개발자가
되기 원하시면 수시로 파일 저장 버튼을 클릭하시기 바랍니다.
필자 경험으로 좀 유머스런 일은 그 개발자가 초절정 고수임에도 불구하고
새로운 프로그램 테스트, 새로운 버전의 운영체제 테스트,
혹은 바이러스 프로그램으로 인하여 귀중한 소스 코드와 자료를 HDD에서
잃어 버리는 경우가 많습니다.
그 개발자에게는 별로 중요하지 않는 소스코드이지만 다른 사업자 중에는
그 프로그램을 필요로 하는 경우가 있습니다.
// 오라클 DB에 연결 설정 //
오라클 DB에서 폼 디자이너에 올려진 DB 컴포넌트를 클릭했을 때 나타나는
파라미터의 설정은 아래와 같습니다.
지금 기술하는 것은 오라클 DB와 BDE 5.1 버전에서이며 다른 DB 종류에따라
DB의 클라이언트 종류에 따라 그 설정 방법이 다를 수 있습니다.
[형식1]
SERVER NAME=@(alias of oracle DB )
USER NAME=(user ID)/password
[보기]
SERVER NAME=@ora_mydb
USER NAME=su/1234
// 인쇄 솔류션 //
제일 조은 방법은 프린터에 켄버스를 이용하여 직접 그리는 것입니다.
주의 해야 할 점은 프린터 기종 별로 다르게 인쇄 되지 않도록 해야합니다.
이 방법은 도스 시절 코딩에 익숙한 개발자에게 편리하나 그렇지 않는 개발자는
어렵운 점이 있습니다. 이렇게 구현한 양식의 인쇄 품질은 좋습니다.
또 다른 방법은
인쇄 양식을 스케너를 사용하여 1:1 비율로 스켄한다음 BMP 파일로 저장한 다음
폼에서 Back Ground 이미지로 활용한다음 폼을 투명하게 만들어
양식 이미지에서 인쇄할 좌표를 얻어 인쇄하는 방법이 있습니다.
이 방법은 편리하긴 하지만 인쇄 품질이 좋지 못하여 프린터가 3번 연속
인자 하도록 제어를 해야합니다.
퀵 레포트를 사용하는 방법은 매우 편리하나 버전 별로 약간의 버그가 있습니다.
예를 들면 화면 스케일 변화에 따른 셀들의 수직 선들이 일치하지 않는
점입니다. 개발자에 따라서 특별한 기법을 이용하여 구현하기는 하나
올바르게 구현하면 매우 편리합니다.
// 구현의 시작 //
개발 전 분야를 거쳐서 한사람의 개발자를 양성 시키기 위해서는
막대한 시간과 비용이 듭니다.
필자의 경험으로 볼 때 부유하지 않으면 이제 졸업한 사회 초년생들은 많은
어려움이 있습니다. 그래서, 많은 경우 시중의 서적들을 의지하여
독학하는 경우도 많습니다.
물론 개발자의 자질이 풍부한 분들도 있겠으나 뼈를 깍는 노력을 해야
합니다. 특히, 오라클 관련 핵심 기술은 거기에 접근하는 분들은
많지 않습니다.
윈도우 메시지의 후킹은 나름대로 중요함을 느껴서 나름대로 정리하여
기술 할 것입니다. 필자는 편이한 소스를 선호한 편이지만 쓰레드 처리 기법,
메시지 후킹, 가상머시인 제작, 페이징 기법, 메모리 맵 활용등의 기술은
틈틈이 기술하도록 하겠습니다.
프로그램을 개발하면서 느낀점은 이러한 개발 기술들이 악용되면 취약한 윈도우
운영체제에서 강력한 해킹 툴이 만들어 질 수 있다는 것입니다.
각종 관련 법규보다는 그 이전에 개발자의 직업 윤리가 매우 중요하다고 생각됩니다.
체계적으로 개발 전 분야를 습득하는 것은 개인 자질에 따라 시간이 많이 걸리므로
우선 프로젝트 단위로 만들어 보는 것이 중요합니다.
어려움이 많겠지만 하나의 단위 프로그램의 완성은 개발자에게 자신감을 얻게합니다.
각종 팁은 구현 과정의 요소로써 중요하고 전체적으로는 우선 무작정 개발해 보는
경험이 매우 중요합니다.
개발자가 되기 전에 사무직이나 각종 개발과 관련된 업무에 종사하는 경험이
많은 도움이 됩니다. 개발 툴이 아무리 편리하더라도 프로그램의 개발은
역시 개발자의 몫입니다.
현업의 실무자가 직접 개발하는 것은 바람직하지 않으나 업무 프로세스나 알고리즘
개발은 긍정적인 일입니다.
MS-DOS나 WINDOWS 3.1 그리고 WINDOWs95 모두 개발 툴은 C나 VC가 아닌
어셈블리어로 추정 됩니다. 윈도우 운영체제가 VC와 매우 친화적인 것을 나타내고
있으나 운영체제 개발은 순수한 기계어나 어셈블리어로 추정 됩니다.
최근에 C로된 소스 코드는 나중에 포팅 된 것으로 생각됩니다.
// 소스 코드의 유지 보수성 //
같은 분야에 소프트웨어 개발 회사인 A,B회사가 있다고 할 때,
서로 다른 회사의 개발자가 경쟁 회사의 소스 코드를 볼 기회가 생겼다고
가정하면 지저분한 소스 코드에 실망을 하게 됩니다.
그동안 이러한 지저분한 소스 코드에서 생산된 제품과 회사 사활을 건 경쟁을
했나 하는 허탈감을 느끼게 만듭니다.
이것은, 필자가 가정을 한 이야기이지만 실제 현업에서 많이 발생 할 수 있는
일입니다.
윈도우는 GUI란 직관적인 인터페이스를 갖고 있습니다.
그렇습니다. 그 지저분한 소스 코드로 생산된 제품이 경쟁력이 갖을 수 있는 점은
사용자의 인터페이스의 승리라고 하겠습니다. ^^
비록 이런 제품의 개발은 바람직하지 않지만 결과를 중요시 하는 현실에서
눈에 보이는 부분에 대한 처리는 매우 중요합니다.
그래서 합리적이고 유지 보수가 편리한 소스 코드는 개발자의 시각일 뿐
최종 사용자나 경영자는 그러한 부분이 중요하게 생각하지 않으며
관심도 없습니다.
이런 말을 하는 것은 교양있는 사고 방식이 아니지만 수단 방법을 가리지
않고 주어진 기간안에 개발하여 납품을 하고 사용자 인터페이스에 대한
상품 포장에 대한 것이 얼마나 강조해도 지나치지 않다는 것이
실무에서 중요하다는 것입니다.
현장 실무에서 프로젝트가 돈이 되는지? 상품성이 있는지? 사업성이 있는지가
매우 중요하므로 이 글을 열람하시는 분들은 명심하셔서 개발에 임하시길
바랍니다. 그 결과로 여러 분은 아마추어 개발자가 아니라 프로페셔널한
개발자로 성장하게 될 것입니다.
중소형 개발 기업들이 난립하여 적은 급여에 비하여 엄청난 수고와 자기
건강까지도 망가지는 경우가 있는 데, 그러한 브로커들을 잘 판단하여
개인적인 부를 축적하시길 빕니다.
개발 툴이 어떤 종류이든지 합리적이고 효과적인 소스 코드의 생산을 하는
개발자는 대한민국에서 그리 많지 않습니다.
필자가 소프트웨어 개발 회사들의 깊은 속내를 알 수 없지만 이제까지의
경험으로 볼 때 충분히 유추 할 수 있습니다.
개발자의 코딩 습관은 주위의 영향을 많이 받습니다.
수 많은 프로그램 개발자 중에서 FM대로 교육 받고 코딩하는 분은 매우
적습니다. 요행이 외국계 개발 회사에 적을 둔 분들도 소수에 불과합니다.
양질의 소프트웨어를 개발하기 위해서는 개발자를 양성하는 교육 기관의
역할이 중요합니다. 어떤 개발자들은 현장의 경험이 매우 중요하다고 합니다.
몸으로 체험하는 실무 경험을 중요시 한다는 말입니다.
매우 뛰어난 개발자의 자질을 갖고 있는 분들도, 실무에서 여러가지 원인으로
중도에 그만두고 이직한 사례가 많습니다.
각 소프트웨어 개발회사들이 정도의 차이는 있지만 프로젝트가 완료된
소프트웨어를 개선 및 유지 보수하는 경우는 적으며 개발완료시 소스코드는
그 생명을 다하고 맙니다.
만약, 사회적으로 소프트웨어 개발 기술 발전을 추구하지 않으면 많은 개발자들이
프리렌서 즉, 자유 계약직 형태의 성격을 갖을 거란 전망을 해봅니다.
어떤 대안이 제시되지 않는 다면 미국의 마이크로소프트 같은 성공적인 소프트웨어
개발 회사는 우리나라에서 보기 힘들 것이란 전망을 해봅니다.
인도처럼 소프트웨어 개발 육성책이 필요하다고 하겠습니다. 그리고 가장 중요한 것은
소프트웨어 개발 발전을 위한 기금은 반드시 소프트웨어 개발 분야에 쓰여지고
그 기금의 집행에 대한 관리 감독하는 지혜가 필요하다 하겠습니다.
소프트웨어 개발 분야에 수 많은 브로커들이 난립하여 단기 수익을 위해 나서는 것을
지양하고 기술 개발이 집적되도록 많은 분들의 생각을 모아야 하겟습니다.
// 월 억대 수입을 올리는 개발자 //
매일경제신문의 지난호를 살펴보면 월 억대의 수입을 올리는 개발자를 소개하는
기사가 있습니다. 어떻게 해서 프리렌서가 그러한 수입을 올리는 지 알 수 없지만
필자는 사실 월 억대 수입이라고 해서 오타나 오보로 생각했었습니다.
즉, 연간 수입을 생각했었습니다. 만약 이 기사가 사실이란 전제하에 생각을 해봅니다.
필자는 그 개발자가 실력이 뛰어나다는 생각을 안합니다. 그러한 수준에 있는 개발자는
우리 나라에서 많이 있으리란 생각을 해봅니다.
첫째, 혈연, 지연, 학연등의 인맥입니다. 그에게 억대 수입을 가능하게 만든 것은
그에게 수주하는 많은 사람들을 알고 있다는 의미입니다.
둘째, 그 개발자의 부단한 자기 노력과 자기 개발에 대한 재 투자입니다.
세째, 개발된 제품에 대한 최종 사용자의 만족도입니다.
네째, 그 개발자에 주어진 기회에 대하여 적절히 놓치지 않고 잡았다는 사실입니다.
다섯째, 신문 기사를 살펴보면 외국계 개발회사에서 실무경력과 중요직책에
근무한 점입니다. 아마도 외국계 회사에서 재직할 때 합리적이고 효과적인 코드 생산
기법을 습득하였을 것입니다.
우리나라에는 수 많은 개발자들이 있습니다. 그들 개발자들이 전부 경제적인 안정과
수입을 얻는 것은 아닙니다. 그래서 개발자란 직업에 대해서 장미 빛 환상에
젖어들지 않기를 바랍니다. 수 많은 개발자들이 영리보다는 자기가 하고 싶은
일을 한다는 긍지와 자기 존중이 개발 분야의 발전에 도움을 준겁니다.
특히, 특정 분야에 열정을 가진 전문적인 개발자들에게는 그 기회가 많지 않지만
조은 기회가 올 것입니다. 그 기회를 잘 이용한다면 명예와 부를 획득하지 않을까여?
// 툴의 안정적인 코드생산 //
델파이로 개발한 응용 프로그램의 실행 파일은 안정적인 것으로 알려져
있습니다. 그러나 델파이가 이러한 고성능 툴임에도 불구하고 일부 비판적인
시각이 있는 것을 보면 개발자의 개인적인 개발능력
즉, 소프트웨어의 설계, 업무 분석, 요구분석 등이 중요하다고 생각합니다.
유지보수가 용이한 코드 생산은 아무리 강조해도 지나치지 않습니다.
소프트웨어 개발 회사의 경영자 모임에 나가보면 비쥬얼 툴 중
마이크로 소프트의 비쥬얼 스튜디오를 선호하는 것을 볼 수 있습니다.
우선 그 이유로는
첫째, 툴의 가격이 저렴하다.
비쥬얼 스튜디오 엔터프라이즈판이 이백만원 이내입니다.
경영자에게 가격 문제는 엄청난 자극이 됩니다.
둘째, 비쥬얼 베이직 사용 회사의 외곡된 시각입니다.
특이하게도 개발 분야에 대하여 정통하지 못하면서 경영자가
귀가 얇아서 주위의 분위기에 동조하는 경우가 많습니다.
어떤 툴을 사용하는 것도 중요하지만 그 툴을 사용하여 최적의 고품질의
소프트웨어 개발을 하는 것이 중요합니다.
세째, 개발자 의사에 반하여 경영자의 이상과 추구하는 것은
바로 이윤 추구입니다.
최소의 투자로 최대의 이윤을 추구하는 것이죠.
그래서, 경영자의 입장에선 어떤 툴을 사용하는지의 여부와
상관 없이 돈만 잘 벌면 그뿐이란 생각을 합니다.
그래서, 주위에 근거 없는 이야기와 분위기에 편승하여
델파이를 사용했다가 비쥬얼 베이직을 사용했다가
또, 파워빌더를 사용하기도 합니다.
이런 경영자의 아래의 개발자는 그 만큼 운신의 폭이 좁기 마련입니다.
네째, 경영자의 대부분이 개발자의 기술적인 의견을 경청하지 않습니다.
경영자는 개발하고자는 프로그램의 난이도에 대해서 아랑곳하지
않고 돈이 되는 것이라면 무조건 시행하는 경우가 많습니다.
많은 경영자가 소프트웨어 개발 분야에 전반적인 지식이 없는 경우가
많으며 그래서 전횡을 하지만 그 아래에 개발자는 우수한 인력인 경우가
많습니다. 필자는 그동안 실무 경험에서 어느 툴을 사용하는가도 중요하겟지만
개발자의 소프트웨어 설계 기술이 얼마나 중요한가를 알게 되었습니다.
// 비쥬얼 베이직의 장점 //
1. 툴의 가격이 저렴하다.
2. 배우기가 쉽다.
3. 툴 개발회사의 재정상태가 양호하다.
4. 비쥬얼 베이직 툴을 사용하는 개발자가 많다.
5. 비전문가 툴이다.
6. DB 관련 프로그램 개발이 용이하다.
// 비쥬얼 베이직의 단점 //
1. 컴파일 속도가 느리다.
2. 런타임 라이브러리가 반드시 필요하다.
3. DB 관련 외 다른 분야의 프로그램 개발이 쉽지않다.
4. 툴 사용자가 많아서 버그 패치나 다운로드가 쉽지 않다.
5. 툴 사용으로 인한 다른 손해에 대해서 책임을 지지 않는다.
// 델파이의 장점 //
1. 컴파일 속도가 빠르다.
2. 런타임 라이브러리가 선택적으로 사용 할 수 있다.
단독 실행 파일 생성이 가능하다.
3. 전문가용 툴이다.
4. 오픈 소스로 고급 개발 기법에 대한 것을 습득 할 수 있다.
5. DB 관련 프로그램 개발이 용이하다.
// 델파이의 단점 //
1. 툴의 가격이 비싸다.
2. 버전에 따라서 로딩 속도가 느리다.
3. 퀵 레포트에 버그가 있다.
4. 플랫폼이 다른 경우 직접적인 이식이 어렵다.
5. BDE를 배포 할 경우 별도로 배포해야 되며 실행이 무겁다.
6. 파라독스 테이블의 인덱스 손상이 빈번하다.
// *.DB *.DBF에서 RDBMS으로 포팅 //
많은 개발자들이 파일 시스템의 테이블을 관계형 DB의 테이블로 포팅하는
것을 어렵게 생각하는 것 같습니다.
이 글에 제시한 방법대로 DB를 설계하신다면 DB 종류가 오라클, 사이베이스,
인포믹스, MSSQL, mysql, 인터베이스 등에 관계없이 쉽게 포팅 하실 수 있습니다.
물론 자세한 SQL 스크립트 중에 특정 DB에 종속된 함수가 있을 지 모르지만,
수정하는 것은 어렵지 않습니다.
C/S 버전에서는 서버에 질의하여 계산된 결과만을 가져오도록 해야합니다.
보통 잘못된 코딩으로 레코드를 클라이언트로 가져와 가공하는 경우가 많은데
커넥션이 10이상만 되어도 네트워크 트레픽과 서버의 과부하를 발생시켜
최악의 경우까지 발생시켜셔는 안됩니다.
개발자는 코딩하면서 항상 커넥션을 고려한다면 C/S 개발은 그리 어려운
일이 아닙니다.
// 고급 기법의 사용자 함수들 //
초보 개발자들의 입장에서 보면 메시지 후킹하는 것들이나 좀더
고급 기법의 함수를 사용하는 개발자들을 바라보며 감탄을 합니다.
어떻게 그러한 고급 함수들을 사용하게 되었을 까요?
첫째, 지금은 절판되어 시중 서점에서 구할 수 없지만, 윈도우 프로그래밍이란
주제로 API 함수를 소개한 원서가 있었습니다.
둘째, 러시아, 이스라엘, 인도 등 특정한 사이트에 가시면 고급 함수를 완전히
공개한 경우가 있습니다. 즉, 오픈 프로젝트 구룹입니다.
이러한 사이트 찾는 것이 쉬운 일이 아니며, 최근에는 무슨 이유인지 이러한
사이트에 접근하는 것을 차단하는 경우가 많아졌습니다.
세째, 와레즈 사이트 이용입니다.
와레즈 사이트는 현제 우리 나라에서 불법입니다.
그러나, 순수 연구 목적이라면 와레즈 사이트에서 상용 컴포넌트의 소스코드를
모두 볼 수 있습니다. 보통 와레즈 사이트라면 상용 프로그램의 실행파일을
불법으로 배포하는 것으로 알고 있지만, 소스 코드만을 취급하는 경우도
있다고 하지만 확인된 사실은 없습니다.
// 툴에 관련된 질문 //
질문: 솔로몬씨? 어떤 툴을 주로 사용합니까?
답변: 저는 어셈블리어, BASIC, GW-BASIC, FORTRAN, COBOL,
PASCAL, C++, CLIPPER, Visual Basic, Visual C++,
PowerBuilder, DELPHI를 사용합니다.
질문: 그럼, 어떤 툴이 좋습니까?
답변: 저는 모든 툴이 나름대로 일장일단이 있다고 생각합니다.
그래서 모든 툴이 좋습니다.
프로젝트 종류에 따라 구현하기 편한 툴이 좋습니다.
질문: 모든 툴을 전부 공부해야 합니까?
답변: 능력이 되신다면 권장드리고 싶습니다. 하지만 특정 툴하나에 대해서는
최고의 수준이 되셔야 합니다. 하나의 툴의 전문가가 다른 툴을 배우는
것은 쉬울 수도 어려울 수도 있습니다.
★ 유솔로몬은 델파이가 넘 좋습니다. ★ 델/파/이/만/세/다
// 윈도우 시스템 메시지 받기 //
먼저 프로시져를 변수로 정의하며,
반환 값은 윈도우메시지 명령의 메시지 값입니다.
var
procedure WMSysCommand(var AMsg: TWMSysCommand); message WM_SYSCOMMAND;
실제 함수의 구현 내용입니다.
procedure WMSysCommand(var AMsg: TWMSysCommand);
begin
inherited;
if AMsg.CmdType = SC_MINIMIZE then // 최소화 버튼이 눌려졌으면..
...;
end;
{
TWMSysCommand.CmdType = SC_CLOSE // 윈도우가 닫힐때
= SC_MAXIMIZE // 최대화
= SC_MINIMIZE // 최소화
= SC_KEYMENU // 키보드로 메인메뉴 호출
= SC_MOUSEMENU // 마우스로 메인메뉴 호출
= SC_RESTORE // 최소화에서 원래의 상태로 복원 될 때
}
// 폼 종료시의 메모리에서 모든 컴포넌트 해제 //
// TCloseAction 클래스의 인스턴트 Action의 정의 . 생략가능
var
Action: TCloseAction);
begin
Action:=caFree;
end;
// INI 파일의 응용 //
*.ini는 윈도우3.1에서 보듯이 우리에게 친숙한 파일 형태입니다.
이 파일은 주로 환경 설정용으로 많이 사용되고 있습니다.
만약 MyConfig.ini의 내용이 아래와 같고
[ASection]
MyLeft=1
MyTop=2
[BSection]
MyString=ABCDEFG
위 파일을 읽어 드릴려면 아래와 같이 구현한다.
먼저 선언 할 사항은
uses
IniFiles;
var
MyIni : TIniFile;
procedure INIRead;
var
Path : String;
begin
// ini 파일 동적 생성
Path := ExtractFilePath(ParamStr(0)) + 'MyConfig.ini';
MyIni := TIniFile.Create(Path);
Left := MyIni.ReadInteger('ASection','MyLeft',1);
Top := MyIni.ReadInteger('ASection','MyTop',2);
MyEdit.Text := MyIni.ReadString('BSection','MyString','ABCDEFG');
MyIni.Free; // INI 파일 메모리해제
end;
INI 파일에 내용을 기록하려면 아래와 같이 구현한다.
procedure INISave;
var
Path,MMySting : String;
begin
Path := ExtractFilePath(ParamStr(0)) + 'MyConfig.ini';
MyIni := TIniFile.Create(Path);
MyIni.Write Integer('ASection','MyLeft',1);
MyIni.Write Integer('Asection','MyTop',2);
MMySting := MyEdit.Text;
// 문자열 중에 공백(' ')이 있으면 그 공백을 제거.
while pos(' ',MMySting) <> 0 do Delete(MMySting,pos(' ',MMySting),1);
MyIni.Write String('BSection','MyString',MMySting);
MyIni.Free;
end;
// 메모리 맵의 활용 //
1. 전혀 다른 파일 포맷의 자료 변환 하고자 할 때
2. 소켓프로그램에서
3. 파일 전송시
// DLL 파일의 용도 //
1. 메시지 후킹 할 때.
2. 나만의 함수를 감추고 시플 때(프리렌서들이 사용함 ).
3. 메모리 관리를 동적으로 핸들링할 때.
4. 소켓 프로그램 만들 때 사용.
// 레지스터리의 용도. //
레지스터리는 다양한 용도로 사용합니다.
1. 복사방지 장치로 이용.
2. 응용프로그램의 path 설정.
// 어플의 중복실행을 막아야 하는 경우 //
1. DB 관련 프로그램에서 클라이언트의 과도한 연결을 줄이고자 할 때
2. TMediaplay 컴포넌트 사용시 윈도우 리소스 과도한 사용을 제약 할 때
3. C/S 어플에서 특히 서버 프로그램이 중복 실행되지 않도록 한다.
// 하드웨어 참고자료 //
요즘의 컴퓨터는 저가형에 통합보드를 사용하고 해서
산업용으로 제어하는 데 어려움이 있을 수 있습니다.
BIOS는 자사 브랜드 특성에 맞게 수정하여 범용적인 호환문제에 제약을
둔 경우가 많습니다. 삼성컴퓨터의 M2771도 그렇구요.
HP의 BRIO410A도 그렇습니다.
따라서 BIOS에 의존않고 윈도우에서 제어하도록 해야합니다.
c:\\windows\system\bios.vxd를 도스모드에서
bios.old로 수정한다음 사용하시면 됩니다.
카드 슬롯에 카드를 모두 꼿아서 장치가 많아져서 오동작을 하는 경우엔
시스템-등록정보-시스템장치-PCI장치 - 등록정보 - IRQ 조절장치 사용안함에
체크표시 하면 됩니다.
컴퓨터에 부착된 장치들의 제어에 대한 오동작은 메인 보드의 PCI
ROUTER CHIP의 성능에 의해 영향을 받습니다.
// 프로젝트 관리문서 //
프로젝트 관리는 ISO 소프트웨어 품질관리 규정에 따라 관리하는게
좋습니다. 프로젝트 관리에 대한 문서 목록입니다.
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. 발주서
// 개발자들의 보조 도구 //
여기에는 일반 개발자들이 사용하는 프로그램들입니다.
이 목록에 있는 소프트웨어를 사용하지 않는 분들도 있어요
* 주의 : 모두 상용 소프트웨어이며 제조회사의 등록상표입니다.
1. Case 도구 : ErWin, Rose
2. DFD 도구 : ViSio2000
3. DB 종류 : 퍼셔날 오라클(윈도우용), 리눅스용 오라클(개발자버전)
4. 텍스트 에디터 : UltaEdit32.
5. 압축 도구 : WinRAR
8. 화면캡쳐도구(사용설명서제작): Snigit32
// 보안 //
보안은 아무리 강조해도 지나치지 않습니다. 하지만 완벽한 보안은
없습니다.
해킹, 크랙킹, 데킹의 기술은 항상 보안 기술보다 앞서 있습니다.
우리 나라는 최고의 해킹 기술을 갖고 있는 분들이 다른 해커들을
적발하여 사법 처리를 하고 있지만, 해커를 추적하는 분들도
어느 순간에 해커로 돌변 할 지 아무도 모릅니다.
어떠하든지 세미나, 개발자 모임에서 자기 회사의 서버가 완벽한
보안 시스템을 구축했다고 공언을 해서는 절대로 안됩니다.
개발 툴이 어떤 것이든지 프로그램 소스 코드는 개발회사의 재산입니다.
그러나, 오너, 프로젝트 메니저, 심지어 개발자까지 소스 코드의 보안에
무관심합니다.
보통, 개발 소스가 오픈 된 경우는 바이러스 프로그램에 의한 경우가
많습니다. 바이러스 프로그램이 포트와 공유 리소스를 강제 개방 시키는
것입니다. 바이러스 프로그램에 의한 것은 각종 보안 툴로 검사해도
공유 리소스가 열리지 않는 것으로 나타나지만 실제로는 열려진 경우가
많습니다. 그 실례가 원격 컴의 포트 139번 개방과 네트워크 브로드
케스팅입니다.
특히, NetBEUI 프로토콜인 경우도 보안에 취약하기 마련입니다.
원격 컴퓨터의 공유 리소스 오픈의 확인 형식은
//IP Adress, \\IP Adress, //HostName, \\HostName등입니다.
보기> //127.0.0.1, \\127.0.0.1, //HomPC, \\HomPC
위 형식은 TCP/IP와 윈도우 운영체제에서 공유 리소스에 대한
접근을 허용합니다.
위에 대한 문제는 방화벽을 구축한 서버에서 어느 정도 감시 및 보안을
기대 할 수 있으나 아직도 여기에 무관심한 개발자가 많습니다.
따라서 어떠한 곳이든지 인터넷에 연동 되었다면 공유 리소스가 오픈된
상태에서 자료를 열람이 가능하게 됩니다.
일반 개발회사의 소스코드 노출 사고는 많은 경우 실무 경력이 없거나
개발자에 입문하신 분이나 신입 사원에 의해서 많이 발생하게 됩니다.
개발자 동호회 사이트의 게시판은 프록시 서버를(보안과 캐쉬를 위한)
사용하지 않는 경우에는 고정 IP주소가 고스란히 남습니다.
이것은 해커들의 표적이 됩니다.
해커들은 개발 기술에는 관심이 없고 상대의 컴퓨터 자료를 훔치는
일에 시간을 보냅니다.
폴더의 공유이름뒤에 $를 붙이면 윈도우 탐색기에는 나타나지 않지만
실제로 폴더가 열려 있습니다.
특정 폴더의 읽기 전용의 권한은 방화벽이 없는 경우 근거리 뿐만 아니라
원거리 까지도 공유 가능하다는 것을 주의 하시기 바랍니다.
따라서 폴더를 공유 할 때는 반드시 읽기 전용에 암호를 -바빠도1234정도는-
부여하시고 전체 공유를 해서는 안됩니다.
<주의 >
초보 개발자는 노련한 개발자를 의지하게 마련입니다.
그리고, 전문가의 포트 스캔에 무력하기만 합니다.
그래서 만약 다른 개발자가 보안툴이라고 파일을 보내주면 절대로
개발 작업을 하는 컴퓨터에 설치해서는 안됩니다.
99.9 % 순도의 백도어 프로그램입니다.
비록 호의에 고맙기는 하지만 거의가 백도어 프로그램입니다.
상대 컴퓨터의 소스코드를 훔치려는 나쁜 사람들이 많습니다.
전 개발 과정에서 항상 컴퓨터를 개발자 한사람당 컴퓨터를
2대를 할당하여 개발용 컴퓨터는 물리적으로 인터넷 망으로 부터
절단 시키고, 인터넷 검색용은 별도로 마련하도록 합니다.
DB 서버는 절대로 물리적으로 인터넷과 연동 시켜서는 안됩니다.
// NB Scanner의 로직 //
1. 검색 시작IP와 끝IP를 입력 받습니다.
2. ping을 합니다.
3. ping 응답이 있으면 GetHostName하여 컴퓨터 이름을 가져옵니다.
4. port 검색을 시작합니다.
5. port 숫자는 1..6555 까징
// 나약한 DLL 파일들 //
윈도우 운영체제에서는 DLL 파일을 포함해서 *.DB *.DBF등의 파일은
자주 손상됩니다.
외관상 정상적으로 보이나 헤더 및 중간에 체인이 되는 경우가 많습니다.
어떤 경우엔 HDD의 결함으로 파일 손상이 빈번하게 발생되면,
프로그램의 재 설치로는 소용이 없는 경우가 있습니다.
이럴때는 특정 DLL을 메모리에 로드 할 때 즉시 이것을 가로채어
DLL헤더 및 구조를 검사하여 손상되었으면 복원 및 교체 시키는
방법이 있습니다. 인터럽트를 가로체서 하는 방법이 있을 수 있습니다.
열려진 파일들이 갑작스런 정전시에 닫혀지지 않거나 바이러스
프로그램으로 인해서 발생하기도 합니다.
소스코드에서도 반드시 사용 후에는 파일이 닫혀지도록 코딩하는 게
좋습니다.
// CD-R/RW 사용시 주의 사항 //
* 기록중에는 절대로 다른 작업을 하지 마십시요. 실패의 주원인이
됩니다.
* 각종 DISK를 복사할 때는 HDD에 DATA를 저장 후 복사를 진행합니다.
* 기록 전에 화면 보호기, 백신 프로그램의 시스템 감시기능, 기타
백그라운드에서 실행되는 E-Mail 도착을 알리는 프로그램등을
종료해야 합니다.
* 전원 절전기능은 Disable하십시요(Bios 및 윈도우 절전기능)
* CD-ROM이나 RW의 등록정보에서 DMA 설정창의 활성화
* HDD의 DMA 설정을 Check.
* 디스크 조각모음을 합니다.
* 저배속으로 기록시 실패율이 적습니다.
// 코딩시 주의할 점 //
구현하시다 보면 개발 툴에 관계 없이 질리도록 반복 되는 것이
있습니다. 또한, 한 프로젝트 내에 특정 함수가 생각이 잘 안나서
그동안 개발한 응용프로그램 소스 내에서 찾느라 고생하는 경우도
있습니다. 그럴 경우엔 공통 유닛에 모두 모아 두면 참으로
편하답니다. 물론 단점도 있습니다.
그리고, 어떤 경우라도 로직은 편이하게,
어느 누가 소스를 보아도 이해하기 쉽게 구현하셔야 합니다.
그러면 그것을 재사용 하는 데 용이하고 소스가 사장 되지 않고
프로그램을 개선 할 수 있습니다.
20년 이상을 개발하시는 분들의 소스를 보면 그것을
알 수 있습니다. 조잡한 소스는 그걸로 생명이 끝나고 맙니다.
자기 발전에 도움도 되지 않습니다.
실무용 소스를 보고 가치가 있는 것인지 여부의 판별이
쉽지 않습니다.
// 미니프로젝트 //
여기서 제가 말하는 미니프로젝트는 6개월 이하의 짧은
프로젝트나,팀 프로젝트가 아닌 개발자 혼자서 업무분석,
설계, 코딩, 디버깅, 배포, 도움말 작성등 일련의
모든 작업을 하는 것을 말합니다.
중소 규모의 소프트웨어 개발업체가 영세성을 면하지
못하고 있고, 또한 발주로부터 수주까지의 과정이 까다롭고
투명하지 못하여 하청에 재하청 연속으로 실제적으로 개발자에
돌아가는 현물 금액이 그리 많지 않는 형편입니다.
특히, 델파이와 관련해서 초급 기술자가 많은 편이고
중고급 개발자가 많이 부족해서 소프트웨어 개발 관련 업체에서
많은 어려움을 겪고 있습니다.
// NT4.0에 Interbase DB 올리기 //
* NT를 부팅시킨다음 관리자 계정으로 로그인 한다.
* [ 시작 - 설정 - 제어판 - 서비스 ]를 차례대로 클릭한다음
window installer가 시작되었는지 확인해서 시작되지 않았으면
서비스 시작을 시킨다.
* [ 시작- 프로그램 -관리도구(공용)-사용자 관리 ]를 클릭한다음
새로운 사용자 계정추가를 클릭한다음,
클라이언트의 윈도우 로그온 사용자이름을 입력한다.
주의 할 점은 네트워크 환경을 클릭했을 때 나타나는
컴퓨터 이름을 입력하는 것이 아니라 윈도우 부팅시
로그온 할 때 입력하는 사용자 이름을 입력하는 것이다.
시디롬 드라이브에 델파이 엔터프라이즈 버전을 넣으면
나타나는 설치 목록 중에 InterBase5.11을 클릭한다.
설치 지시에 따라 프로그램을 설치를 완료한다.
* [ 시작 - 설정 - 제어판 - 서비스 ]를 차례대로 클릭한다음
InterBaseServer 를 클릭하고 시작옵션을 클릭한다음
자동으로 선택하고 시스템 및 데스크탑 상호작용을
선택한다.
* 인터베이스 DB 파일을 반듯이 루트 디렉토리에 복사한다.
예론, HDD가 C: D: 으로 파티션이 나누어 졌다면
d:\ 디렉토리에 DB를 복사하면 된다.
HDD의 디렉토리 깊은 곳에 DB를 복사하면 효율적이 아니다.
* 공유에서 디렉토리 사용자 권한 설정은
다음과 같이 4가지 구성원이 추가 되어야 한다.
Administrators 모든 권한
Creator Owner 모든 권한
Everyone 바꾸기
System 모든 권한
* 클라이언트 윈도우에서 BDE 관리자를 열고 알리아스와 Path를
설정한다 .
경로 설정은 다음과 같다.
SERVER NAME의 파라미터 설정은 BDE의 버전에 따라 다를 수 있습니다.
일반적으로 형식은 다음과 같습니다.
서버컴퓨터이름:드라이브명:/절대경로/DB이름
보기> NTServer:d:/InterBase.GDB
구 버전에서 다음과 같은 경우도 있었습니다.
//서버컴퓨터이름/드라이브명:/절대경로/DB이름
보기> //NTServer/d:/InterBase.GDB
// 델파이 개발자님들에 대한 소개 //
초보 개발자나 실무경력 1년차 분들은 다음 소개하여 드린
개발자님들의 홈페이지를 방문하여 많은 자료를 수집하시기
바랍니다.
이 분들의 이름을 알려드리기 전에 그 분들의 허락을 받아야 하나
제 임의대로 게시합니다. 또한 그 분들의 이의가 제기되면
즉시, 모두 삭제하고 다시 편집하겠습니다.
순서는 없으며 생각나는 대로 게시하겠습니다.
[ 개발자 인명록 ]
권용길님, 민성기님, 하영재님,이정욱님, 김영대님, 양병규님,
류기동님, 허일학님, 우영범님, 김태영님, 이화식님, 여덕수님,
석봉현님, 신문섭님
< 추가 >...
우리 나라는 재능이 많은 고급 개발자님 들이 있습니다.
이름이 널리 알려지지 않았지만 초절정 고수님들이 수 없이
우리 주위에 많습니다.
여기 델마당은 다른 개발 툴의 영업직원이나,
비쥬얼 베이직, 비쥬얼 C++, C++, 파워빌더 등
주력 툴이 델파이가 아닌 분들도 많이 방문하는 것으로
생각됩니다.
// DELPHI와 VCL //
VCL은 참으로 예술 자체입니다. 만일 개발자 개인이 이런 라이브러리를
만들 정도라면 실력있는 고급 개발자입니다.
VCL을 보고 다른 툴의 라이브러리로 만들면 재미 있을 것이라는
생각을 했습니다.
소스가 있는 라이브러리는 다른 툴로 쉽게 포팅이 가능합니다.
그래도 원초적인 운영체제의 버그를 피해가거나 최적화 시키기 위해서
dcc32.exe의 역할이 크다고 봅니다. 안정적인 기계어 코드의 생산은
아무리 강조해도 지나치지 않습니다.
// 구현할 때 주의 할점 //
1. 생성된 실행 파일의 크기가 작아야합니다.
2. 실행 파일이 윈도우 리소스를 소모하는 것을 최소화 시켜야
합니다.
컴퓨터의 사양이 저급하더라도 프로그램이 잘 실행되게
만들어야 합니다. 날씬한 프로그램이 C/S 버전에서 위력을
발휘합니다.
3. C/S 버전 어플을 개발한다고 해도 꼭 TClientDataSource,
TClientQuery를 사용 하실 필요는 없습니다.
다만 TQuery나 TDataSource를
사용 할 때 Connection 처리만 잘해주면 실제적으로
프로그램이 잘 실행됩니다.
어떤 개발자님들은 BDE 엔진이 무겁게 느껴져 짜증을 내기도 합니다.
사실 DB 설계만 잘 하면 BDE내의 함수가 다 필요로 하진 않습니다.
그래서 같은 BDE엔진이지만 SQL LINK를 사용하기도 하고
심지어 어떤 경우에는 독자적으로 DB 엔진을 DLL 파일 형태로
만들어 사용합니다. 일종의 소켓 프로그램이지여
// 이론과 실무 //
이 글을 열람한 분들이 이미 느끼고 계시겠지만 이 글 내용면에서
시중의 컴퓨터 관련 서적에서는 볼 수 없는 것들이 많습니다.
물론, 시중의 참고 서적 중에 실무에 대한 책이 전혀 없는 것은
아닙니다. 그런한 서적이 존제한다 할지라도 실무에 얼마나
도움이 될지는 미지수입니다.
이 글은 개발과 관련된 저의 개인적인 경험과 고민을 바탕으로
구성 될 것입니다.
개발자란 직업을 갖게 되었을 때 제일 힘들게 하는 것은
이론과 실무는 너무 차이가 있다는 것입니다.
저의 은사님이었던 박사님들 까지도 그 차이가 크다는 것을
예측하지 못하셨나 봅니다. 또한 저를 개발자로 양성하여
주신 선생님들까지도 실무에 사용된 라이브러리를 공개하여
주시지 않았고 그 개발 노하우 즉 배타적인 개발기술에 대한
강한 집착을 보여 주셔서, 저는 항상 그것에 대해 의문을
가지고 있었는 데, 제가 실무에 종사하고 보니 그 맘을
해아리게 되었습니다.
많은 분들이 소스 공개를 외치며, GNU 구호를 외칩니다.
여러분은 이찬진 님의 워드프로세서 한글97의 소스 가치는
얼마라고 생각 되시는지요?
안철수님의 V3의 소스 가치는 얼마나 된다고 생각하십니까?
빌게이츠님의 운영체제인 윈도우95의 소스 가치는 얼마나
된다고 생각하십니까?
그렇습니다. 모두 수억원을 호가합니다. 이런 부가 가치를
생각하신다면, 개발자 의사에 반해서 함부러 소스 공개를 요구하지
못하실 겁니다. 간혹, 아무 댓가 없이 소스를 주시는 분을 만날 수도
있습니다. 만약, 그렇다면 그 개발자는 님에게 엄청난 호의와 배려를
한겁니다. 현금처럼 자신의 재산을 나누어 주시는 겁니다.
아무쪼록, 이 글을 읽으시는 모든 분들이 양질의 고급 프로그램을
많이 개발하시길 바랍니다.
초보자들이 많이 궁금해 하는 것은 어떻게 하면 빠른 시간 내에
원하는 프로그램을 만들 수 있는가? 또한 그 방법은 무엇인가?
그런데, 정말 기초 부터 튼튼한 개발자라면 델파이에 공개된
소스들을 그냥 지나치지 않을 것 입니다.
이 소스들은 어떻게 코딩을 하는 것인가? 구현 방법들을
구체적으로 예시하여 준 것을 나타내므로 개발자는
왜? 이렇게 구현을 하였는가에 의문을 가지고 주의 깊게
소스들을 살펴보아야 합니다. 개발 관련 고급 기술등은
델파이 정품 안에 모두 포함되어 있습니다.
이 소스와 함께 델파이 도움말을 참고로 연구하신다면
틀림 없이 좋은 결과가 올겁니다.
이 글 때문에 다른 개발자님들의 입지가 좁아질까 염려가 됩니다.
그 분들 나름대로 고생과 땀으로 그 개발 기술을 습득했고
너무 쉽게 개발 기술이 전수되면 질보다는 양적 팽창을
염려하게 될 것입니다.
이 글을 쓰면서 많은 부분이 실무와 관련하여 인연을 맺게된
프로젝트 메니저님, 소장님, 실장님 들의 개발 기술들이
담기게 될 겁니다.
혹시라도, 프리랜서로 재직하시는 분들은 그럴 기회가
있을 지 모르지만, ERP 관련 업체에 근무하시게 되면 꼭 프로젝트
보고서를 열람하시기 바랍니다.
ERP 프로젝트 보고서 이 책 한권을 만들어 내기 위해선
수억이 들어갑니다. 회사 규모에 따라 다르지만 수십억에서
수 백억의 비용이 소요됩니다.
이 보고서는 일반적으로 대외비입니다.
회장, 정보담당이사,전산실장 등이 열람 가능자입니다.
요즘은 평생직장 개념이 사라졌읍니다.
그래서 사람을 임의로 면직 시킵니다.
오너가 무능하면 전산 관련 담당자를 아무나 선임하는 경우가 있고,
보안 관련해서 서버 관리자를 임의로 교체하는 경우도 있습니다.
이런곳에 파견나가면 손쉽게 그 귀한 보고서를 열람 할 수
있습니다. 이 문서의 가치와 취급을 잘 못하는 경우도
있습니다. 개발시 필요하다고 요청하면 되겠죠? ^^
우리나라에서 ERP 관련 유명한 업체는 엔더슨~스미스
컨설팅일 것으로 생각합니다.
SAP는 넘 유명해서 SAP와 관련하여 개발 경험이 있는 분은
많은 기술을 배울 수 있을 것이란 생각을 하지만
잘 모르겠습니다. 우연이라도 이런 자료를 열람하게 되면
그냥 지나치지 마시구 깊이 연구 및 탐독하시기 바랍니다.
저는 고백하건데 파스칼을 본능적으로 싫어 했습니다.
수치해석과 관련하여 어쩔 수 없이 사용하긴 했지만.
아무튼 파스칼이 그래픽을 표현하는 데 용이하다고 해서.
친구 녀석의 꼬임에 넘어가서 관심을 가지게 되었습니다.
델파이가 이런 나의 파스칼에 대한 편견에 마침표를 찍었습니다.
파스칼을 오브젝트 파스칼로 바꾼 것은 예술 그 자체입니다.^^
델파이를 공부하게 되면서 시중 서점에서 엄청 두꺼운 4만원
가까이 하는 델파이 관련 서적들을 구입하여 탐독 하였습니다.
그러나 책을 읽고나서, 도무지 쓸만한 응용프로그램을 만들 수가
없었읍니다. 그리고 인터넷에서 웹,고퍼,아키, FTP 사이트를
전전해도 실무용 소스를 찾기는 힘들었습니다.
개발자가 되고 싶다고 해서 인도처럼 실무에 사용 될 정도로
개발자를 우리나라에서 양성하는 곳이 적습니 다.
물론 (주)비트컴퓨터에 입사하면 좋은 데 입사가 매우 까다롭고
입사 시험에 합격해야 합니다.
우리 나라에서 개발자가 되는 일이 쉬운일이 아닙니다.
그리고 전산 관련 세계는 인맥을 중요시 하니까, 어느 직장에
입사하시든지, 실무 1년차는 인간관계를 소중히 하시길 바랍니다.
피곤하고 스트레스 많아도 직장 상사들과 원만하게 지내며
근무하시길 바랍니다.
// 실제 세계와 컴퓨터의 세계 //
소프트웨어 개발 업체의 오너는 개발 과정에 대한 이해가
많이 부족합니다.
그래서 때때로 개발자에게 말도 안되는 로직과 기능을
요구합니다. 보통 오너들은 개발자가 만능 재능을 가지고
있다고 착각을 많이 합니다.
개발자도 나름대로 자신 있는 분야가 있기 마련입니다.
예론, 비쥬얼 베이직 개발자 에게 자바 프로젝트를 의뢰한다거나
어셈블리어를 구현 시키는 것 등등 .
중급 개발자라도 오너가 로직이 불가능한 것을 지시했을 때
의견 충돌로 사직하는 경우가 많습니다.
오너는 자기가 제시한 아이디어가 구현하는 것이 그렇게
어려운 일인가는 모릅니다. 다만 사업성 즉, 돈이 되겠다는
생각에 그렇게 지시하는 것입니다.
이때는 먼저 오너가 제시한 문제에 대하여 최선의 인터뷰를
기획하여 사장님의 구상이 실제 전산 세계로 변환시키는
작업을 합니다.
프로그램 실행상 오류를 내겠지만 그것을 조각화 내지
단편화 시켜서 부분적으로 구현합니다.
그러니까 제시한 아이디어 중 당신이 구현 가능한 것을 찾아내어
그것부터 구현하시라는 말입니다.
그리고 구현이 어려운 부분은 예외처리를 이용하며
최선을 다하여 개발에 힘쓰고 전반적인 것에 대하여
충분하게 오너에게 설명해야 합니다.
오너가 이해하든지 말든지 그게 중요한게 아니구요.
필요하다면 프로젝트 성공을 위해 자기가 취약한 부분에 대한
다른 개발자 차용 및 임용 또는 아웃소싱을 고려합니다.
오너 입장에서는 경제성을 고려하여 프로젝트를 진행할것인지를
결정하게 될 것입니다.
개발자가 무조건 오너에게 반항하는 것은 옳지 못합니다.
사전에 충분이 오너에게 이해를 구하셔야 합니다 .
이런 일이 실무에서 자주 생겨서 유능한 개발자가 사표를 내는
경우에 마음이 아픕니다.
이 글을 읽으시면서 실무경력 1년차 분들은 실무에 대한
기본적인 개념을 습득하길 바라며, 여기에 소개된 로직과
함수들은 비쥬얼베이직, 파워빌더, C 언어로 모두 포팅이
가능한 것들입니다.
각 개발 툴에서 기본적인 것이 무엇일까요?
저는 프로그래밍한지가 오래 되었습니다.
그렇다고 해서 제가 실력이 뛰어나다는 것은 아닙니다.
프로그램 구현에 있어서 가장 중요한 것을 들라면
컴포넌트, 클래스, 함수, 로직이 아닐까 생각합니다.
결국은 함수의 싸움인 것 같습니다.
여기서 함수란 사용자 정의의 함수를 말하며,
델파이에서 지원하는 기본적인 함수의 함수를 말합니다.
함수안에 함수로써 로직을 구현한 것들의 집합입니다.
여러가지 비쥬얼 툴들은 컴포넌트만 잘 관리하고 유지하면
응용프로그램들을 쉽고 빠르게 만들 수 있습니다.
개발자는 틈틈히 컴포넌트에 대해서 깊게 공부해야 합니다.
컴포넌트 아무리 강조해도 지나치지 않습니다.
컴포넌트 내부를 뜯어 고치려면 함수를 깊이 알아야
합니다.
컴포넌트는 소스가 없으면 외관상으로 컴포넌트 프로퍼티나
이벤트는 쉽게 나타나지만, 내부의 실제적인 구현 내용
즉,컴포넌트가 가지고 있는 행동 기능은 나타나지 않습니다.
일반 라이브러리처럼 콤포넌트 사용설명서나 소스가
있어야 내부에서 이 콤포넌트가 하는 일을 정확히 알 수
있습니다.
폼에 콤포넌트를 올리면 바로 그 컴포넌트가 하는 기능을
사용 가능합니다. 그치만 그 폼에서 그 컴퍼넌트의 영역으로
영향을 주는 범위로 한정합니다. 마치 지역 변수 객체처럼요.
여러가지 함수로 자기만의 라이브러리를 구축 할 때
자기도 모르게 개발능력이 배양되는 것 같습니다.
어떤 특정 기능을 위해서는 즉, 막고 품어야 할 경우에는
API 함수를 잘 알아야 합니다.
이 함수 전체를 알 필요는 없지만 그래도 많이 알아 둘수록
막고 품어야 하는 최악의 경우에 매우 유용합니다.
많은 실무용 프로그램에서 자주 사용되는 것은 바로
사용자의 입력 받는 폼의 처리입니다.
대다수의 고급 개발자는 델파이 컴퍼넌트의 파랫트에
있는 표준 컴포넌트를 그대로 사용하지 않습니다.
왜냐하면 델파이를 오래 사용했다 하더라도 표준 컴포넌트에
내장된 정확한 함수를 모르는 경우가 많고 기능도 모르는 것도
많습니다. 그래서, 이 표준 컴포넌트를 가지고 중복정의하여
새로운 컴포넌트를 만들어 사용합니다.
그럼, 표준용 컴포넌트를 가지고 사용자 정의용 컴포넌트를
만들어 보겟습니다.
이렇게 표준 컴포넌트에 다가 다시 사용자정의로 컴포넌트를
만들어 쓰는 이유는 물론 텍스트 상에서 소스를 분석 가능
하겠지만 이 사용자 정의의 컴포넌트가 없으면,
비쥬얼하게 소스를 보는 것이 쉽지가 않겟지여.
각 툴들이 동일 버전에서 마이그레이션을 한정합니다.
그래서, 표준 컴포넌트만 사용하면 마이그레이션이
쉬울 겁니다.그러나 소스 코드만 갖고 있다면 염려하실
필요는 없습니다.
가장 많이 사용되는 것이 에디트, 마스크 에디트, 리얼에디트,
비트버튼 등입니다.
수 많은 클래스 구조를 만들어 보시고 이미 만들 어진
클래스도 열람하시면 됩니다.
// 에디트 클래스의 구조 //
TMyEDIT = Class(TEdit)
private { Private declarations }
FFFF : Boolean;
procedure enter; Override;
procedure Click; Override;
procedure Change; Override;
procedure KeyDown(Var key : Word; Shift : TshiftState); override;
public { Public declarations }
Constructor Create(Aowner : Tcomponent); override;
published { Published declarations }
property Han : Boolean read FFFF Write FFFF;
end;
먼저 사용자 정의의 에디트 클래스에 추가해야 할 멤버 함수는
Change, Click, Enter, KeyDown, Create 등입니다.
// procedure TMyEDIT.Change의 구현 //
1. 폼 변수 설정
2. 상속 ( inherited change; )
3. 폼 변수에 할당 ( GetParentForm(Self); )
4. 만약 폼 변수 <> Nil 이면
만약 MaxLength = GetTextLen 이면
SendMEssage(MyFORM.Handle,WM_NEXTDLGCTL,0,0);
// procedure TMyEDIT.click의 구현 //
1. SelectAll
2. 상속(inherited Click;)
// procedure TMyEDIT.DoEnter의 구현 //
1. 만약 ffff 이면 SetHan(Handle) 그밖에 SetEng(Handle);
2. 상속 (inherited doEnter;)
// procedure TMyEDIT.KeyDown(Var key : Word; shift : TshiftState)의 구현 //
1. 변수정의 (Var MyForm : TCustomform; )
2. MyForm := GetParentForm(Self);
3. 만약 MyForm <> Nil 이면
Case key of
Vk_Down,
Vk_Return : SendMEssage(PFORM.Handle,WM_NEXTDLGCTL,0,0);
Vk_Up : SendMessage(PFORM.Handle,WM_NEXTDLGCTL,1,0);
그밖에는 Inherited KeyDown(key,shift);
// Constructor TMyEDIT.Create(Aowner : Tcomponent)의 구현 //
1. 상속 ( inherited Create(Aowner); )
2. AutoSize := False;
3. AutoSelect := True;
4. Parentctl3d := False;
5. Maxlength := 10;
6. Ctl3D := TRUE;
7. FONT.Name := '굴림체';
8. Font.Size := 10;
9. Font.Color := ClBlack;
10. TEXT := ';
----------------------------------
// TMediaPlayer 컴포넌트 사용시 주의 할 점 //
* DB 연결 오류, 네트워킹 오류, TMediaPlayer.Path에 절대 경로
상의 재생 파일이 없을 때 mmsystem 오류를 냅니다.
* Mplayer.exe 와 Mplayer2.exe는 다른 특성이 있습니다.
재생시 코덱이 필요한 경우가 있으며 사용 권한을 인증 받아야
재생되는 경우가 있으니 주의하시기 바랍니다.
* Try TMplayer execept ~ end;로 처리하는게 좋습니다.
* Refresh를 해 주어야 합니다.
// 자료 복구 프로젝트 //
DB에서 유일해야 할 레코드가 중복 되었을 경우 레코드를 검사하여
복구해주는 루틴입니다.
1. 관련 컴포넌트 : TDataBase 1개, TQuery2, TDataSource 2개
2. 자료검사 버튼의 처리
3. 레코드 중복검사 질의문
qy1.close;
qy1.sql.clear;
qy1.sql.add('
select code, wdate count(*) cc from MyTable group by code, wdate
having count(*) > 1 ');
qy1.open;
if qy1.recordcount > 0 then button2.enabled := True;
edit1.text := Qy1.recordcount;
// 델파이 환경설정 팁 //
[ Tools - debugger options - OS Exceptions - Access violations ]
Handled By : Debugger 체크,
On Resume : RunHandled 체크
위와 같이 하지 않으면 어떤 경우엔 Stack dump나 시스템 폴트를
일으켜 작업중인 변경된 소스를 저장 할수 없게 될 수도 있읍니다.
메모리가 적은 윈도우 95 운영체제에서 발생 될 소지가 있으나
그외의 사양에서는 문제 될 것이 없다고 생각됩니다.
// 프로로젝트의 관리 //
프로젝트 관리는 개발자 취향에 따라 여러가지가 있습니다.
어떤 개발자는 컴포넌트를 모두 한 디렉토리에 모아서 사용하는
경우도 있습니다.
필자는 프로젝트 하위에 디렉토리를 생성하고 컴포넌트를 위치
시키는 것을 권장합니다.
물론, 컴포넌트 소스 파일이 중복된다는 단점이 있지만
해당 프로젝트에서 어떤 컴포넌트가 사용 되었는지를
명확히 하고 또한 소스 파일을 백업 한 후
백업본을 다시 사용 할 때 컴파일이 쉽다는 장점이
있습니다.
예론, c::\myproject\mycomponent
그리고 프로젝트 단위별로 암호를 사용하여 압축한 뒤에
날짜별로 보관합니다.
// 소프트웨어 유지보수 //
소프트웨어 유지 보수의 관건은 비용 문제입니다.
어떤 경우라도 비용이 제한 폭 내에서 지출되어서는 안됩니다.
자동업그레드 기능을 응용프로그램에 추가하는 방법이 있습니다.
자동 업그레드 전에 설치 마법사를 사용한 셋업 프로그램이 준비
되어 있어야 합니다.
1. 고객과 전용선을 통하여 웹으로 연동되어 있는 경우에는
ICS(Internat Component Suite)컴포넌트등을 사용하시면 됩니다.
원격제어 프로그램 노턴의 PCAnyWare를 사용하는 방법도 있습니다.
2. 고객과 순수하게 모뎀으로 연결한다음 원격제어 프로그램을
이용하는 방법이 있습니다.
터미널 제어 프로그램 즉 통신 에뮬레이터를 활용합니다.
3. 고객은 모뎀으로 접속한다음 전화접속 네트워킹을 통하여
웹과 연동한 다음 자동 다운로드하게 만듭니다.
4. 인터넷에 접속 > 버전 검사 > 다운로드 >
실행중인 프로그램 강제 종료 > 이전 버전 프로그램제거 >
업그레드 시작 > 시스템 재시작
// 윈도우 95/98에서 경로 설정이 안될 경우 //
간혹 운영체제에서 경로 설정이 되지 않는 경우가 있는 데 아래와
같이 처리합니다.
* autoexec.bat 에 추가 내용 *
PATH=C:\WINDOWS;C:\;C:\WINDOWS\COMMAND;
SET PATH=%PATH%;C:\WINDOWS;C:\;C:\WINDOWS\COMMAND;
// 주석문 사용법 //
(****************************************************
폼 명칭 : 용도 설명
저작권 : (c) Copyright ~
저자명 : 저자이름(전자우편)
홈페이지 : 홈 페이지 주소
사용법 : 사용법 기술 및 제약사항
--- 각 함수에 대한 주석 방법 ---
명 칭 :
소 속 :
목 적 :
****************************************************)
// 부분 소스연구 //
* Cancel 버튼을 클릭 이벤트의 처리
ModalResult := mrCancel; // Close;의 결과 값을 반환해줌
* Ok 버튼을 클릭 이벤트의 처리
ModalResult := mrOk; // Ok 버튼을 클릭한 결과 값을 반환해줌.
* TEdit.text에디트로 입력 받은 URL을 가지고 기본 브라우저를
실행시켜 사이트에 접속.
ShellExecute(Self.Handle,
PChar('open' + #0),
PChar((Sender as TEdit).Text + #0),
PChar( #0 ),
PChar( #0 ),
SW_SHOW);
* 폼에서 초기화 부분이 많을 때 일괄 초기화 시킴 *
procedure FormCreate(Sender: TObject);
begin
Self.Initialize;
end;
procedure Initialize;
begin
초기화 할 컨트롤 목록들
end; { Initialize }
// 고급 개발자로 출발시 유의 할 점 //
1. 개발 툴이 비쥬얼 베이직, 비쥬얼 시뿔뿔, 파워빌더, 델파이든지
개발 툴의 종류에 상관 없이 각 개발 툴에 대한
자기 고유의 라이브러리를 구축해 나가야 합니다.
2. 라이브러리가 구축되면 각종 환경에 적용 가능한
프로젝트 원형을 만들어 나가야 합니다.
3. 새로운 프로젝트가 발주되면 가장 비슷한 원형을 가지고
구현을 시작하며, 만약 새로운 프로젝트가 기존 원형을 가지고
있지 않을 경우 프로젝트 진행과 더불어 원형을 만드는 작업을
동시에 합니다.
4. 프로젝트 원형을 만들면서 반복되거나 재사용 가능한 함수는
모두 공통 유닛에 라이브러리에 모아둡니다.
5. 모든 구현 코드는 알기 쉽게 편이하게 구현하며 수 십년간을
꾸준히 업그레드합니다.
6. 모두의 코드의 구현이 개발자 혼자하든지 아님 팀으로 하든지
동일한 인터페이스를 가져야 합니다.
7. 각 개발툴의 버전에 따른 소멸된 함수, 생성된 함수에 관한
내용을 공통 유닛에 주석문으로 처리하여 기록합니다.
특히 클래스 계보에 관한 것도 주석문 처리하여 기록합니다.
8. 만약 운영체제 플랫폼의 제약을 받지 않으려면 시언어로
포팅을 합니다.
9. 만약 이미 툴에 존제하는 함수이지만 개발자가 사용자 정의로
새로운 아이디어가 생각 났을 때, 공통 유닛에 사용자 정의함수로
구현하도록 합니다.
// 윈도우 설치시 그림이 동적으로 디스플레이 되는 방법의 구현 //
사용 컴포넌트는 TTimer, TImage, TFileListBox를 사용하여
TFileListBox의 Visible 속성을 False로 한다음
타이머 이벤트에 아래와 같이 구현한다.
procedure Timer1Timer(Sender: TObject);
var
path : string;
begin
path := 'e:\'; // 동적으로 뿌려줄 *.bmp 파일이 있는 경로
Image1.Picture.LoadFromFile(Path + FileListBox1.Items[piccount]);
inc(piccount);
if piccount = FileListBox1.items.Count then piccount := 0;
end;
// 미니급 C/S 버전 프로그램의 개발 //
1. 프로젝트 파일의 내용
1) . Y2K의 처리
2). 프로그램 중복실행 방지 루틴
3). 응용프로그램의 동적 타이틀 생성.
4). 로그인 폼을 메인 폼으로 만들 것( 제일 먼저 생성되게 만듬)
5). 스플래쉬 폼의 처리
* 프로그램 중복실행 방지의 구현
if FindWindow( 'TloginFrm', '착한 여자가 조아 Ver 1.0' ) > 0 then
begin
Application.MessageBox(0,'프로그램이 중복 실행 되어
이 프로그램은 종료합니다. ',
'중복실행오류',mb_ok+mb_iconstop) ;
Halt;
end;
* 프로그램 중복실행 방지의 구현2
var
MuxHandle : THandle;
begin
Application.Initialize;
MuxHandle := FindWindow( 'TFrmLogin', PChar('바보프로그램') );
if MuxHandle <> 0 Then
Begin
Application.MessageBox('프로그램이 이미 실행중입니다','확 인',
mb_OK+mb_DefButton1+mb_IconInformation);
Halt;
end;
* 스플래쉬 폼의 구현
Application.Initialize;
SplashFrm :=TSplashFrm.Create(Application);
SplashFrm.Show;
SplashFrm.Update ;
Application.Title := '착한 여자가 조아 Ver 1.0';
Application.CreateForm(TloginFrm, loginFrm);
SplashFrm.Hide ;
SplashFrm.Free ;
Application.Run;
2. 로그인 폼의 설계
1). 폼 생성시에 동적으로 폼 위치를 설정.
2). DB 연결.
3). 사용자 인증.
4). 사용자 인증이 되면 메뉴 폼 배열을 열기.
5). 폼 닫힐 때 DB 연결 해제. 모든 컴포넌트 메모리 해제.
6). 작업일자 입력받기
( 년월일을 가져와 콘트롤에 표시하고 사용자의 수정을
받은 다음에 문자열 전역 변수에 보관함
테이블 필드의 자료형태도 Char형을 사용함 )
* 로그인 폼에서 사용자 인증은 여러가지 방법이 있으나
ini 파일을 이용한 방법과 DB의 사용자 테이블을 이용하는
방법이 있습니다.
* 로그인 폼에서는 만일 자료를 파일 시스템으로 관리 할때는
예론, *.DBF 나 .DB 일 때는 자료 정리 과정을 편이하게 구현합니다.
주로 인덱스 파일을 검색하여 인덱스 파일이 존재하면 루틴을 빠져
나가고 그렇지 않으면 인덱스를 생성한다.
begin
if (fileexists('c:\DB\1.mdx') = true) and
(fileexists('c:\DB\2.mdx') = true) and
(fileexists('c:\DB\3.mdx') = true) Then
exit;
end;
* 작업 진행바는 TGauge를 사용하며
Gauge1.maxvalue := 인덱스 파일 갯수 ; 로 설정한다.
* 메시지 폼의 설계
{**************************************************
메시지 폼 모듈
Copyrights,2001,By ds4byw, All rights reserved.
2001. 5. 10.
유 솔로몬 (ds4byw@hanmail.net" target=_blank>ds4byw@hanmail.net Tel 0116459006)
사용법:
사용자에게 알림 메시지를 뿌리고 사러지게함
사용하고자하는 유닛의 use절에 uses message;
를 추가한다음 아래와 같이 호출
smsg := '난 착한여자가 조아!';
frmmessage := tfrmmessage.create(nil);
frmmessage.ShowModal; // 윈도우 NT에서 지원안됨
frmmessage.Gauge.progress := 0;
frmmessage.free;
exit;
***************************************************}
unit message;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
ExtCtrls, Gauges;
type
TFrmMessage = class(TForm)
pnlmessage: TPanel;
Timer1: TTimer;
gauge: TGauge;
procedure FormActivate(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FrmMessage: TFrmMessage;
smsg: string;
implementation
{$R *.DFM}
procedure Tfrmmessage.FormActivate(Sender: TObject);
begin
pnlmessage.caption := smsg;
timer1.enabled := true;
end;
procedure Tfrmmessage.Timer1Timer(Sender: TObject);
begin
Gauge.progress := Gauge.progress + 1;
if Gauge.progress = Gauge.maxvalue then
begin
timer1.Enabled := false;
close;
end;
end;
end.
* 보통 작업 진행바는 TProgress를 사용하지 않고 TGauge를
많이 사용합니다.
* 폼생성시의 폼의 위치 동적 설정의 구현
top := 278;
left := 286;
* 메뉴 폼의 호출의 구현 : 폼 배열을 응용한 MDI 폼
if MyMenuFrm[0] = Nil then
MyMemenuFrm[0] := TBaboMenuFrm.Create(Application);
공통 유닛에 다음을 사전 정의해야 하고 각 폼의 uses 절에
공통 유닛을 포함 시켜야 한다.
Var
MyMenuFrm : array [0..20] of TForm;
* 폼이 닫힐 때 컴포넌트의 메모리 해제의 구현
" 당근이져? 그쵸?" ^^
Action := CaFree;
// 판넬(TPannel)을 사용하는 이유 //
일반적으로 개발자들은 윈도우 리소스를 최소한으로 잡아 먹도록
고려를 합니다. 그래서 가능한 판넬 사용을 자제하려고 합니다.
판넬은 판넬 자체로 다중 창을 구현 할 수 있고
판넬 위의 컴포넌트들은 판넬 안에서 그 행동을 제약 받게 됩니다.
따라서 폼 디자이너에서 판넬을 이동시키면 판넬 위의 콤포넌트들도
동시에 이동하게 되는 것입니다.
일반 폼위의 콤포넌트 위치 조정은 복수 개를 선택하여 이동 시켜야
합니다.
판넬은 다양한 속성을 가지고 있어서 여러가지 효과를
나타냅니다.
보통 입문자들은 밋밋한 폼에 각종 콘트롤을 올려 놓게 되는 데
이렇게 작업하다보면 폼 디자인에 손질이 많이 가서 귀한 시간을
낭비하게 됩니다.
반복의 최소화 효율적인 코딩을 위해서 판넬을 사용하시기
바랍니다.
// 명령 단추에 대한 고정관념 깨기 //
보통 윈도우에 기본적인 프로그램의 버튼들은 작고 귀엽게 생겼습니다.
이것은 미관상 좋을 뿐이지, 실제로 업무용 프로그램의 버튼들은
큼직하고 투박하게 만듭니다.
다른 개발자에게 구현을 시켜 보았을 때, 만약 그 개발자가
버튼 모양을 크게 만들었다면 그는 고수이거나 재능이 많은 분임에
틀림없습니다.
최종 사용자가 마우스 버튼을 클릭하여 최단시간에 버튼을 조작하며
그 조작함에 있어서 행동에 자연스럽고 피로가 적게 하기 위한
배려가 필요합니다.
업무용 프로그램은 일반적으로 지루한 반복작업의 순환이 되기
때문이지요.
// 사용자 인터페이스 GUI, TUI //
사용자 입력을 받는 부분은 옛날 도스 운영체제의 인터페이스가
많이 적용되고 또한 은행처럼 반복된 입력 작업이 요구되는 곳은
엔터 키를 누르면 탭 키를 눌렀을 때의 효과를 내는 것을
구현하여야 하며 이것은 응용프로그램 중에 많이 사용됩니다.
아래 소스를 비교해 보십시요.
procedure KeyPress(var Key: Char);
var
MYForm: TcustomForm;
begin
if Key = #13 then
begin
MYForm := GetParentForm( Self );
if not (MYForm = nil ) then
SendMessage(MYForm.Handle, WM_NEXTDLGCTL, 0, 0);
Key := #0;
end;
if Key <> #0 then inherited KeyPress(Key);
end;
procedure KeyDown(var Key: Word; Shift: TShiftState);
var
MYForm: TcustomForm;
CtlDir: Word;
begin
if (Key = VK_UP) or (Key = VK_DOWN) then
begin
MYForm := GetParentForm( Self );
if Key = VK_UP then CtlDir := 1
else CtlDir :=0;
if not (MYForm = nil ) then
SendMessage(MYForm.Handle, WM_NEXTDLGCTL, CtlDir, 0);
end
else inherited KeyDown(Key, Shift);
end;
procedure KeyDown(Var key : Word; shift : TshiftState);
Var
MYForm : TCustomform;
begin
MyForm := GetParentForm(Self);
if MyForm <> Nil then begin
Case key of
Vk_Down,
Vk_Return : SendMEssage(MyFORM.Handle,WM_NEXTDLGCTL,0,0);
Vk_Up : SendMessage(MyFORM.Handle,WM_NEXTDLGCTL,1,0);
else Inherited KeyDown(key,shift);
end;
end;
end;
[ 데이터 베이스 설계 ]
업무용으로 사용된 많은 응용프로그램이 데이터 베이스와 연동
되며 최상으로 설계된 데이터 베이스는 프로젝트를 성공으로
이끌며 프로그램 개발을 쉽게합니다.
그러나 잘못된 데이터베이스 설계는 프로젝트 실패와
많은 금전적 시간적으로 손해를 줍니다.
경험이 부족한 프로젝트 메니저는 이런 이유로 인하여 많은
리스크를 감수해야 합니다.
데이터 베이스는 경험이 많은 분이나 특히 개발쪽이 아니라
기업 및 관공서의 실무에 능한 분이 설계하는게 좋습니다.
이런 이유로 몇 년전만해도 테이블 설계만 해주고 고액의
용역 댓가를 받아가는 경우가 많았습니다.
오라클 솔류션에 보면 오라클 특유의 도구와 방법이 있습니다.
특히, 어떤 경우에는 데이터 베이스 설계를 Er-win이라는
프로그램을 사용합니다. 이 프로그램은 테이블 설계를 쉽게하고
자동적으로 테이블을 생성하여 줍니다.
오라클 기반의 질의문 사용시 어떤 결과를 원할 때에
개발자 임의로 질의문을 사용하지 마십시요.
오라클 솔류션에 보면 질의에 대한 결과 값에 대한 비슷한 경우에
사용 될 수 있는 최적화된 질의문을 이미 갖고 있습니다.
최적화된 질의문을 사용하십시요.
만약, 개발자가 최적화된 질의문을 찾았다면 질의문 예제집을
만들어 재활용 하도록 하십시요.
관계형 데이터 베이스에 대한 고정 관념을 버리십시요.
노련한 경우가 아니면 결코 지나친 정규화나 프라이머리 키,
포린 키를 설정하여 제약 사항을 만들지 마십시요.
그렇지 않으면 데이타 베이스와 연동되는 응용프로그램이
에러를 내거나 데이터 베이스를 전면 재설계해야 하는 경우가
생깁니다.
일반적으로 데이터 베이스는 데이터를 통합적으로 관리하기 위해
데이터 중복을 최소화하는 목적으로 사용됩니다.
필요하다면 데이터 중복에 연연하지 마십시요.
실제 코딩시 직관적인 변수는 알기 쉽고 이해하기 쉽게 설정하고
전체적인 알고리즘을 다른 개발자가 이해하기 쉬운 편이하게
구현합니다.시간이 허용하는 한 주석을 많이 첨가 하십시요.
일부 고급 개발자는 주석이 많은 것에 대해 꺼려합니다.
소스가 지저분해진다는 것 때문입니다.
그러나 주석이 많을 수록 그 프로그램에 대한 이해를 도우며
나중에 문서화하는 데 도움이 되며 다른 개발자에게 개발기술
전수라는 효과를 줍니다.
함수 사용에 어려움이 있다면 사용자 정의 함수를 만들어
사용하십시요. 어떤 함수들은 에러를 유발합니다.
이런 함수의 사용을 자제하십시요.
[ 비정규적인 데이타베이스의 설계 ]
이 방법은 불합리한 면도 있지만 기업이나 개발자들이 아직도
사용되고 있습니다.
바로 관계형 데이터베이스를 바로 ISAM 테이블 구조로
설계하는 것입니다.
검색 키로 사용되는 필드는 모두 인덱스 테이블을 생성합니다.
인덱스 테이블이 엄청 많아 지겠지요.
많은 대용량 솔류션 컨설런트들이 비난한점이 있지만 나름대로
이 방법이 사용되고 있습니다.
대용량 솔류션에서 보면 수백만건의 트랜젝션이라 하더라도
제3차 정규화까지하게 되면 응답속도가 3초이네로 단축 시킬 수
있다고 합니다.
이것을 구현하려면 아주 전문적인 설계자가 아니면 실패하기
쉽습니다.
많은 분들이 이런 경지에 오르려고 노력하는 것도 사실입니다.
아래 설명하려는 방법은 표준적인 방법이 아닙니다.
유지 보수의 편의성을 중심으로 아래와 같이 설계를 하는
것입니다.
기존 코볼로 만들어진 응용프로그램이나 이에 연동하는 DB와
호환하려 할 때 사용됩니다.
프라이머리 키와 포린키의 제약을 두지 않습니다.
실제적으로 테이블에서는 레코드 중복을 허용을 하며
많은 부분에서 응용프로그램에서 데이터 중복을 막습니다.
예론 락킹 방법을 사용합니다.
만약, 레코드의 중복을 피할려면 인덱스 테이블을 생성하고
그 인덱스 테이블에서 해당 필드에 대한 프라이머리 키로 제약을
합니다.
먼저 개발하려고 하는 해당 업체의 관련 부서의 모든 결제 서류를
취합한다음 관련 있는 것끼리 모아서 필드명를 정합니다.
데이터 중복이나 정규화에 신경쓰지 말고 한 테이블에 관련있는
필드를 모두 모아둡니다.
응용 프로그램에서 검색창의 조건에서 검색 키로 사용되는
모든 필드는 인덱스 테이블을 생성하고 그 필드를 인덱스 키로
설정합니다.
검색 키로 사용될 필드는 모두 인덱스 테이블이 생성되어야 하며
필드 형태는 CHAR를 사용합니다.
금액이 들어갈 필드는 자료의 표현범위에 유의해야 합니다.
필드 타입이 잘못되면 금액 계산 및 자료가 모두 표현되지
못합니다.
특별한 경우를 제외하고는 필드 형태를 CHAR를 모두 사용하세요.
검색 키 필드로 사용할 때는 CHAR를 사용하세요.
[ 공통 유닛의 설계 ]
공통 유닛은 따로 만들어 둡니다.
여기에는 반복된 사용자 정의 함수나 공통으로 사용된 함수를
모아두며 모든 유닛의 uses 절에 포함시킵니다.
이렇게 함으로 교차 참조 문제를 해결합니다.
보기를 들면
unit1.pas unit2.pas unit3.pas..project.dpr의
내용에 공통적으로 포함시킴.
implementation
{$R *.DFM}
Uses myunit;
식으로 모두 포함시킵니다.IDE에서 포함시키지 말고 직접 타이핑
하세요. 그럼 이제 공통 유닛의 깊은 곳을 들여다 볼까요?
공통유닛의 제일 앞부분으로 와야 될 것이 뭘까요?
바로 전역 또는 광역 변수의 처리입니다.
지역 변수인 경우에는 바로 유닛 내에서 사용하고 해제해버리면
그만이죠.
전역변수에 사용되는 것은 주로 날짜, 사용자 레코드 타입의
자료형태 정의 부분이 사용되고 특별히 응용프로그램 내에서
판별자로 사용되는 변수의 초기화 부분이 정의 됩니다.
자! 그 담에 와야 되고 구현 되어야 할 함수들의 목록입니다.
가. 입력 받는 콘트롤의 영문입력상태로 변경하는 함수
나. 입력 받는 콘트롤의 한글입력상태로 변경하는 함수
다. 메시지 출력처리.
라. 입력 받는 문자열 사이의 스페이스를 제거하는 함수
마. 입력받는 문자열이 특정 길이를 요구 받을 때
입력받는 문자열 다음을 스페이스로 채우는 함수
바. 주민등록 번호를 체크하는 함수
사. 사업자등록번호를 체크하는 함수.
아. 신용카드번호를 체크하는 함수
자. 한글을 완성형으로 변환하는 함수
차. 한글을 조합형으로 변환하는 함수
카. 날짜처리함수
타. 날짜를 문자열로 변환하는 함수
파. 특정 컴포넌트를 찾는 함수
하. 입력 받은 값의 반올림이나 절사처리 함수
그리고 여기에 포함되지 않지만
별도로 공통 프린트 모듈을 만들어야 됩니다.
왜냐하면, 간혹 가다가 옛 날 구형 프린터 혹은 도트형 프린터에
인쇄를 해야하는 경우가 생기구요.
은행등 금융기관인 경우엔 각종 전표나 양식에 보정 작업을
해야하고 바코드 프린터 제어에 필요하답니다.
틈틈히 사용자 정의 함수로 프린터를 직접 제어하는 루틴을
만들어 두시고,그게 어려우시면 퀵 레포트를 이용한 프린터 모듈을
다양하게 미리 만들어 두시면 매우 유용합니다.
초보 개발자님들께 제가 넘 무거운 숙제를 드린 것 같습니다.ㅎㅎ
*** 최종 사용자 입력 창, 디스플레이 내용의 초기화 방법 ***
여러가지 방법이 있지만 사용자의 입력을 받는 것의
콘트롤의 초기화 부분을 유닛내에 사용자함수로 묶어 놓으면
참으로 편리하답니다.
보기를 들면
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls,
Forms, Dialogs;
type
TForm1 = class(TForm)
private
{ Private declarations }
procedure myclear;
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
uses myunit;
procedure Tform1.myclear;
begin
edit1.text := ';
edit2.text := ';
edit3.text := ';
end;
end.
[ database desktop 사용법 ]
데이터베이스 데스크 탑은 데이타 베이스 유지보수에 많이
사용되는 도구입니다.
대용량인 레코드인 경우에는 일일이 PgDn을 사용하는 것은
어려운 일입니다.
그래서 SQL문을 많이 사용하게 됩니다.
메뉴에서
[ file - new - sql file]을 차례대로 선택합니다.
그런다음에 메뉴에서
[ sql - select alias..]를 선택합니다.
알리아스는 BDE adminstor에서 미리 만들어 두며 해당
알리아스를 선택합니다.
그런다음에 sql문을 작성합니다.
select * from babo
메뉴에서
[sql-run sql]를 선택합니다.
번개 아이콘을 눌러도 됩니다. 아님 F8을 누르시던가...
데이타 베이스 데스크 탑에서 참 좋은 기능이 있는 데여...
[file - open - table]를 차례로 클릭합니다.
그 다음에 알리아스를 선택하시고
데이터 베이스 접근 아이디와 비밀번호를 입력하면
테이블을 열리는 데여
테이블을 선택하고 더블 클릭하면 열려 버리니까
그냥 테이블을 선택하고 마우스 오른쪽 메뉴를 누르시면
매우 유용한 팝업 메뉴가 나온답니다.
[ 윈도우 리소스를 생각하세요 ]
구현 단계에서 처음부터 윈도우 리소스를 고려해주세요
필요 없는 사용되지 않는 변수나 컴포넌트는 지우고
특히, 동영상을 사용할 때는 중복 실행되지 않도록
주의하세요.
[ 메시지 박스의 사용 ]
메시지 박스 종류도 여러가지가 있지만 그 중에서
showmessage('자기 사랑해?');
application.messagebox('자기야 넘 이뻐?','오류',mb_ok+
mb_iconstop);
등이 있는 데 그 중에서 고수님들은 첫 번째 것 보다
두번째 것을 많이 사용한답니다.
왜? 고급 개발자들이 두번째 함수를 선호 할 까요?
그 이윤 저두 몰라여. 그럼, 첫 번째 것은 어디에 사용하나?
어떤 고수님들은 C에서 개발하던 습관 때문에
디버깅시 에러난 지점을 귀신 같이 찾아 낸답니다.
디버거가 있지만 주석처리하는 // 이것을 조합하여
첫번째 함수를 사용 한답니다.
유닛내에서 대충 에러 낸 지점을 찾기위해서요
저의 선배님들이 많이 사용하셨어요.
[ 화면 색상 디자인 ]
각 폼의 컬러풀한 디자인은 실무에서 매우 중요하답니다.
물건을 포장하는 일은 매우 중요하답니다.
두 가지 주의 사항이 있어요.
업무용 프로그램이기 때문에 장시간 사용해도 눈에 피로감이
없어야 합니다.
또 한가지는 프로그램의 품위와 가치, 품격을 높이기 위해
색상을 산뜻하게 디자인해야 합니다.
개발일에 무지 몽매한 상사를 만났을 때 화면 디자인이 잘 되면
마냥 좋아합니다.
" 보기에 좋고 먹기에 좋은 떡이죠?"
[ 콘트롤의 화면 배치 ]
콘트롤이나 박스 그리고 버튼의 가로 세로 길이의 비율이
모두 황금비를 따르는게 좋습니다.
이 황금비는 시각적으로 사람에게 쾌감을 준답니다.
[ 메뉴의 종류 ]
메뉴 구현 방식은 여러가지가 있어여
메인메뉴, 팝업메뉴.. 사용자 정의 메뉴 등
그런데, 사용자 정의 메뉴는 이미지 버튼이나 판넬을 이용하는
것을 의미하구요.
메뉴에서 폼을 호출 할 때 배열을 사용하면 참 편리해요
[ 객체 사용과 관련하여 ]
다른 분들은 어떻게 하는지 모르지만
구현 하면서 저에게 철칙이 있는 데여.
델파이, 파워빌더,비쥬얼 베이직, C등등 모두에서
변수를 사용 할 때엔 사용하기 전에 반드시 초기화하고
사용한후에는 메모리에서 해제 시키는 것입니다.
지금은 변수에 쓰레기 값이 들어가서 애먹는 일이 별루
없지만 옛날에는 고생을 많이 했어여.
포인터 객체 사용할 때 주의하세요.
[ 최종 사용자와의 만남 ]
글쌔요? 개발자가 사용자를 얼마나 만나게 될지 모르지만
미니 프로젝트에선 다양한 방법으로 만나는 경우가 많답니다.
보험 설계사 수준의 영업에 대한 지식이 필요해요.
개발자가 영업력까지 갖추면 오너와 연봉 협상에서 유리하답니다.
그치만 사람 만나는 일이 아무리 조은 사람 만난다 할지라도
많은 스트레스를 준답니다.
[ 폼 스타일과 데이터 베이스 연동 ]
폼 스타일과 데이터 베이스 연동시 델파이와 파워빌더에서
SDI 폼 스타일 보단 MDI 폼 스타일을 많이 사용한답니다.
고수님들이 왜? MDI 폼 스타일을 많이 사용하시는지 모르겠어여?
[ 코딩의 습관 ]
구현 방식이 크게 두가지 있습니다.
하나는 컴포넌트 안에 스크립트를 밖아 놓는 방법이 있구요
또 다른 한가지는 모든 컴포넌트 생성 및 프로퍼티 처리를
모두 동적으로 처리한는 방법이 있습니다.
개발자 취향이지만 제가 아는 내공이 강한 분들은 모두
동적처리 방법을 많이 사용하셨어요.
[ 고정관념을 버리자 ]
많은 분들이 이미 알고 있는 함수를 적절히 조합하여
잘 사용하면 된다라는 생각을 갖고 있답니다.
저두 여기에 동의하기는 하지만 ....
그래서 구현하는 데 뭐 창의력이 필요하냐고
오너들은 연봉협상에서 연봉을 깎으려 합니다.
그런데,프로그램 개발이 분명히 창의력이나 창의성이
필요하답니다.
이것은 실무에 오래 종사하다보면 자연히 알게 됩니다.
약 2년쯤...ㅎㅎ
각종 조건문을 적절히 조합하여 구현하다보면
거의 환상적입니다...
알고리즘은 아무리 예문을 본다해도 쉽게 늘지 않는답니다.
간혹, 평소에 수학을 잘하시는 분....그러니까 연역적 증명과
귀납법을 잘하시는 분은 강한 것 같습니다.
수학 잘하시는 분들의 소스를 보면 소스가 깔끔하고 명료하고
아무튼 기분이 참 조아여.
메니저는 이런 것을 상관안해여.기간안에 에러 안내고 납품만하면
그걸로 끝이져.그 결과를 중요하게 생각합니다.ㅎㅎ
유지보수 할 때 비용하고 시간때문에 애를 먹기는 하지만..ㅋㅋ
[ 단편적인 소스에 대한 작은 생각 ]
구현 방법은 여러가지가 있지만 응용프로그램이 날씬해서
최종사용자의 메모리나, CPU 사양이 낮은 컴퓨터에서도
무리 없이 실행되는 것이 중요하답니다.
저급한 컴퓨터든지 고성능 컴퓨터이든지
모두 잘 실행되어야 해요
Application.Title := '자기야 사랑해! Ver1.00';
위의 문장을 보시면 폼의 caption 안에 타이틀을 타이핑 하면
될텐데..꼭 고수님들은 위와 같이 동적으로 구현한답니다.
제가 실무에 사용된 소스에서 많이 발견한 점입니다.
이윤 저도 몰르져...그치만 개발자 맘이 아닐까여?
[ 배열을 이용한 메뉴의 호출방법 ]
공통 유닛에 다음과 같이 정의하고
var
MyMenu : array [0..10] of TForm;
아래와 같이 사용
begin
if MyMenu[0] = Nil then
MyMenu[0] := TMain.Create(Application);
end;
위 소스를 보시면 폼들을 배열로 사용했을 때 호출하는 방법을
보여 줍니다.
[ 메인폼이 하는 일 ]
가. 프로그램 중복실행 방지 루틴.
나. 폼 생성시의 처리
시스템 날짜처리.
데이터 베이스에 연결.
질의 객체 생성 및 메인폼에 연결.
다. 폼이 닫힐 때의 처리
데이터 베이스 연결해제.
DataBase1.connected := False;
질의 객체 해제.
Action := CaFree;
음,,,각 폼들을 다룰 때 배열로 처리하면 참 좋아여.
그게 싫으면 여러분 맘대로 하세요.
[ 로그인 창의 처리 ]
로그인 처리하는 방법은 참으로 다양합니다.
주로 C/S 응용프로그램에서 많이 사용됩니다.
그 중 한가지가 사원관리 테이블의 id, passwd 필드를 추가하고
입력 받은 값하고 비교해서 로그인을 허용하는 것입니다.
카운터 처리해서 3번 입력후 실패하면 응용프로그램을
종료시키는 게 좋겠죠.
[ 유능한 개발자가 되려면 ]
이건 저의 독설인데여...
유능한 개발자가 되려면 많은 노력과 땀과 정렬 그리고
시간, 커피, 술, 고민을 소모해야 된답니다.
그리고 젤 중요한 것은 거짓말을 잘해야 합니다.
오너나, 프로젝트 메니저 심지어 최종사용자까징...
다음과 같은 답변에 익숙해야 합니다.
" 제가 만든 프로그램은 100% 오류가 없습니다."
" 아뇨? 절대 그럴리가 없습니다.뭔가 착오가?"
" 오류라니요? 다른 원인이 있겠죠?"
" 그럴리가요? 아마 바이러스에 감염 되었는지 모릅니다."
" 제가 만든 프로그램은 완벽한 프로그램입니다."
" 아뇨? 프로그램에 버그가 있는 것이 아니라 기능 개선을
위해 업그레이드 합니다."
" 가격이 비싸다니요? 이만 하면 저렴하게 개발해드린겁니다"
[ 시리얼 포트의 제어 ( RS232C interface ) ]
시리얼 통신 제어는 참으로 흥미롭습니다.
시리얼 제어의 핵심은 바로
sleep(10);
입니다. 바로 지연시간이지여.
시리얼 포트에 쓰기를 할 때 제어문 하나 날리고
지연 시간을 주는 것이져.
만약 이 함수가 없으면 제어도 잘 안되고
엉망이 되네여...주의하세요.
처음엔 아무것도 모르다가 이 지연 시간 땜에 고생을
많이 했어여.
[ 인터베이스에 연결시 Alais 설정 방법 두 가지 ]
BDE Adminstrator에서
BDE 버전이 낮은 경우에는
SERVER NAME : 컴이름:c:\db\babo.gdb
보기: SERVER NAME : myhost:c:\db\babo.gdb
BDE 버전이 높은 경우에는
SERVER NAME : IP Adress:c:\db\babo.gdb
보기: SERVER NAME : 200.200.200.1:c:\db\babo.gdb
음.. 이해가 되시나여?
아참, 윈도우 계열에 DB를 올리는 경우에는
원래 윈도우 운영체제에선 파일이름에 붙어있는
파일확장자가 많은 의미를 가지고 있잖아여
예론, babo.txt 같은 경우에 .txt 같은거...
DB 이름 정할 때 인터베이스 DB 확장자가 .GDB 이죠.
이것을 빼버리세요. 운영체제를 속이는 거죠..뭐...
쓸대 없이 로칼 서버를 다시 열지 못하도록...ㅎㅎ
만약, 인터베이스 DB 이름이 Babo.gdb 라면 구냥
Babo..이렇게..휴..
그전에 클리퍼로 만들어진 응용프로그램이 많아여.
이것을 인터베이스로 포팅하면 딱 좋아여.
파일 타입의 파라독스 테이블을 사용하면 좋은 데
웬지 인덱스가 자주 손상되어 속상해여
.Db .DBF도 마찬가지이지만..자료의 체인에는
속수무책인 것 같아여.
물론,복구 루틴을 구현하면 되지만여.
보통 메인 메뉴에 "자료재정리"나 아님 "자료복구"메뉴를
만들어 넣습니다.
웅, 다른분이 인덱스 사용 안하면 되잖아여? 라고
반문하시네여.
그것도 한가지 방법이네여. 그치만 인덱스 사용한거와
안한거랑 실행속도 함 비교해 보세요.
[ 질의문 스크립트 ]
처음에 파워빌더하다가 델파이에서 어떻게 질의문 스크립트를
사용하는지 몰라 좀 챙피하고 힘들었음다.
아래 소스를 보시죠...
QY1.close;
Qy1.Sql.Clear;
Qy1.Sql.add('select * from babo');
// Qy1.parambyname('aaa').asstring := bbb;
Qy1.open;
QY1.close;
Qy1.Sql.Clear;
Qy1.Sql.add('select * from babo');
// Qy1.parambyname('aaa').asstring := bbb;
Qy1.active := true;
{ 레코드 삭제 }
Query1.Close;
Query1.SQL.Clear;
Query1.SQL.Add('Delete from babo where Name = 'nana'');
Query1.ExecSQL;
QY1.close;
Qy1.Sql.Clear;
Qy1.Sql.add('select * from babo');
// Qy1.parambyname('aaa').asstring := bbb;
Qy1.execsql;
위 문장의 차이가 이해가 되시나여?
근데, 위 문장은 넘 평범해 보이나요?
그럼, 이렇게 하죠.
공통함수에 질의문 처리를 위한 사용자 정의 함수를 만들고
문자열 변수로 받아서 처리하는 것입니다.
예론...요렇게
babosql('select * from babo')
보기에도 좋죠?
근데 procedure babosql 구현 내용이 궁금하시리라 생각하는 데엽
아무리 초보자라도 조그만 고민하시면 만들지 않겠어여.
[ 미니 프로젝트의 원칙]
원칙요? 그런거 없어여. 이 글을 KAIST 모씨가 보면 틀림없이
절 비난할 것 같아여. ㅋㅋ
미국이나 인도 개발자들은 주먹구구식으로 플밍하는 것을
용납하지 않고 이해도 못하져.
그들은 합리적인 사고 방식의 소유자들이니까...
원칙이라는게 존제하긴하져. 그치만 항상 시간이 부족해서,
그러니까 주먹구구식으로 만드는 거져. 수명 단축하는 거죠 뭐.
프로젝트 범위에 따라 정확한 납기 기간을 예측해야 하는데
이런 경우 개발자와 의논 한번안하고 그냥 결정해 버려요.
운이 조으면 납기내에 납품하고 그렇지 못하면 위약금 물고
망하는 거죠.
보통 이런 일 하다보면 다 그런것은 아니지만
프로젝트 메니저, 개발팀장, 개발부장, 오너 모두 공히
소프트웨어 공학에 대한 기본 개념이 없는 경우가 많아여.
전공자도 아니면서 그냥 자리만 차지하는거죠..뭐.
오직, 한가지 생각..." 돈이 되느냐? 마느냐?"
[ ]. 어느 박사님께 어떻게 해야 유능한 개발자가 되느냐?라고
질문을 드렸는 데 답변은 아래와 같습니다.
가. 전산수학을 잘 알아야 한다.
나. 알고리즘을 잘 알아야 한다.
다. 자료구조에 대하여 잘 알아야 한다.
[ 무선네트워크 구성 (WLAN) ]
이것은 이 글 제목과는 아무 관련이 없습니다.
이것을 알아내느라고 비용,시간, 고생을 많이 했어여
요즘, 무선랜이 아주 각광을 받고있고 관심 갖는 이도
많습니다. 응용 할 곳이 많아졌어요.
주의할게 억세스 포인터랑 PC용 무선랜카드랑 같은 회사에서
만드는 것을 사용하는 것이 조아여.
그리고 PC용 무선 랜카드는 고정용으로 설계된 것입니다.
현제 삼성전자, 3COM, COMPAQ(삼성전자OEM)등에서 만들어져 있지만
PC가 이동 중이면서 네트워킹에 연결된다면 그리고
성능비교로 한다면 노트북용 무선랜카드 3COM 사의 3CREW737
성능이 가장 뛰어 나네여.
이것은 스펙트럼 확산방식이 사용되어 각종 장애물이나 악조건에서도
네트워킹 연결 에러 복구를 쉽게합니다.
이것은 PC 고정용 랜카드에 비해서 뛰어난 성능을 발휘한답니다.
정확한 데이터를 예시로 들수는 없지만 한번
벤치마킹해보시길...
참고하세요.
무선랜카드는 네트워크 타임아웃이 안나오는게 중요합니다.
네트워크 검사
ping -t 500.500.500.500
[ 소스에 대한 소고 ]
소스는 개발자의 눈물, 땀, 고민 등의 결정체입니다.
만약, 다른 개발자가 선뜻 소스를 귀하에게 건네어
주었다면 그것은 당신에 대한 애정과 신뢰의 표현입니다.
사실, 돈이 되는 소스는 따로 있지만 그것을 분별하는
사업자는 많지 않습니다.
소스는 한마디로 현금과 같이 개발자의 재산입니다.
개발자에게 소스를 달라는 것은 "돈 내놔?"와 똑 같습니다.
버전 관리 하면서 소스 취급이 난잡하여 헷갈릴때가 많습니다.
때에 따라선 구 버전을 보관 할 가치가 생기기 마련입니다.
압축하여 보관하시고, 소스를 수정할 때는 가능하다면
원문은 주석처리 하시고 왜? 수정을 하였는지 기술합니다.
가끔, 내가 어디를 수정했는지 몰라...당황한적이 있습니다.
시간이 부족하여 급조한 소스가 아니라면 개발자가
포기하지않고 꾸준히 다듬으면 정말로 좋은 프로그램이
만들어 질 것입니다.
[ M실장님과의 만남 ]
실장님은 제가 알고 있는 개발자중에서 뛰어난 개발자입니다.
실장님은 업무상 개발관련으로 만나뵙게되었습니다.
저에게 행운과 어쩌면 저의 스승이나 다름없어여.
실장님은 뛰어난 고급 개발자입니다. 단, 2개월이라는
짧은 기간 동안에 제가 어플을 개발가능한 능력이
생기게한 저의 은인중의 은인입니다.
깊은 대화를 나누지 못했지만 개발자로서
배풀어 주신 실장님께 감사의 맘을 전합니다.
원래, 저는 돈에 욕심이 없었고 뛰어난 개발자가 되어
조은 어플 개발의 열망에 젖어 있었던 소망을 이루어 주셨습니다.
제 스승인 문실장님을 존경합니다.
[ 소프트웨어 개발업체에 입사준비 ]
요즘엔 구인난에다가 구직난입니다.
소프트웨어 개발업체 또한 예외가 아닙니다.
보통 인사담당자는 총무과장, 전산실장, 인사과장, 정보담당이사,
프로젝트 메니저, 개발과장, 개발부장 등등입니다.
[ 개발자의 나이제한 : 30세이하 ]
수 많은 면접 담당자의 대 다수가 개발자의 연령이 30세를 개발자의
정년으로 생각하고 있었습니다.
그점이 이해가 안되어 탐문한 결과 그 내부적인 이유인즉,
프로젝트 팀내에서 통제의 용이성 때문이었습니다.
개발자로 채용한다고 해서 곧바로 개발자로 종사하는 것이 아니라
대 다수가 잡무에 종사하고 있습니다.
예를 들면, 커피 심부름, 운전수, 프린터 소모품 교환, 공문처리,
컴퓨터 조립 및 고장수리, 타자수, 프로그램 설치 등등...
필요에 따라 욕설도 해야하는 데 나이가 많으면 곤란하다고 합니다.
[ 포트폴리오의 준비 ]
실무경력이 5년 이상이라도 실제 프로젝트 수행이 가능하냐가 중요한
문제이므로 면접전에 개발회사의 특성에 맞는 포트폴리오를 준비합니다.
소스까지 공개할 필요는 없습니다.컴파일하여 실행파일을 준비합니다.
[ 경력증명서의 준비 ]
프로젝트에 참여한 경력이 있는 분은 경력증명서를 준비합니다.
경력증명서에는 프로젝트명, 프로젝트 수행기관, 프로젝트에서
담당업무가 자세히 명기되어야 하며 프로젝트 메니저의 확인인과
추천서를 첨부하면 좋겠습니다.
또한 경력증명서에 개발자 양성기관에서 수료한 경력이 있는 분은
교육과정, 기간등을 명기하여야하며 6개월 이상이면 좋습니다.
비록 프로젝트 수행경험이 있더라도 해당 업체에서 근무기간이
1년이하인 경우에는 경력에 포함시키지 않는 것이 좋습니다.
[ 개발업체의 선정 ]
개발업체의 사업자가 다 정직한 기업인이 아닙니다.
경우에 따라선 개발능력 즉, 개발자금이 부족한 경우에도 개발자를
채용하여 프로젝트 완료후에 면직시키는 악덕업자도 있습니다.
이 경우엔 외주를 주거나 프리렌서나 자유계약직으로 개발자를
고용하면 인권비 부담 때문에 정규직으로 채용하여 면직시키는
경우입니다.
[ 프로젝트 메니저로서의 개발자의 채용 ]
요즘은 개발자의 실력을 중요시하고 프로젝트의 리스크를 최소화
시키기 위하여 노력을 합니다.
그러나 인간성이 뒷받침 되지 못하면 악덕 개발자를 채용하게되면
각종 기계의 손실, 금전적인 손해등 많은 문제를 발생시킵니다.
아마도 제 생각엔 끈기, 팀원간에 융화, 그리고 개발업무에 대한
흥미와 적성이 아닌가 쉽습니다.
개발자마다 아님 프로젝트 메니저마다
자기 주관이 다르겠지만 가끔 편이한 소스를 만나게
되면 오랜 친구를 만난 것 처럼 반가운 마음이 든다.
가끔 아주 난해하게 구현한 것을 마치 실력이 있는 것처럼
착각하는 개발자가 있습니다.
등산하다보면 정상에 오르는 길은 등산로에 따라 다양합니다.
한 가지를 구현하기위한 방법들은 개발자의 개성에 따라
다양합니다.
그렇지만 저를 포함한 몇몇의 개발자는 편이한 구현 방법을
선호합니다. 그리고 그 값어치에 많은 분들이 동의 합니다.
이 글에 대해서 반문하실 분도 계실겁니다.
하지만 이것은 저의 주관적인 생각일 뿐 많은 분들을 대변하는
것은 아닙니다.
프로젝트 진행 중에 가장 괴롭고 힘든 것이 바로 시간입니다.
목에 칼이 들어와도 납기일을 준수해야 하는 점입니다.
만약 납기일을 어기면 고객의 클레임에 걸려 참 당혹스러운
일을 당하게 됩니다.
프로젝트를 잘 콘트롤하지 못하면
" 사공이 많으면 배가 산으로 간다. "
최종 사용자인 고객의 변화무쌍한 요구사항 따라가다가
프로젝트를 다시 시작해야 하는 비극이.ㅠ.ㅠ
고객 중에 같은 건에 대해서 전무 따로 과장 따로 대리 따로
이러니까 우왕자왕...크~ 날짜는 얼마 안남았고 ...
결론은 철저한 인터뷰 계획을 세우고 모든 건을 문서화해야
한다는 점입니다.
[ 신기하고 절묘한 CASE 문 ]
사용자정의 함수
function myfunc(MyNum : byte) : Boolean;
begin
Case MyNum of
1 : begin
end;
2 : begin
end;
3 : begin
end;
4 : begin
end;
5 : begin
end;
end;
end;
함수호출
begin
myfunc(1);
myfunc(2);
myfunc(3);
myfunc(4);
myfunc(5);
end;
위의 케이스문 보시면 응용가능 할 부분이 많겠죠?
한번 깊이 생각해 보시기 바랍니다.
[ 속성개발자 양성 ]
어떻게 하면 빠른 시간안에 개발자를 양성하여 실제
프로젝트에 투입 될 수 있을까요?
우선 끈기가 있어야 하고 책임감이 강한 사람이 좋겟죠?
각각의 대형 프로젝트를 작은 프로젝트로 나누어
솔류션 중심으로 개발프로그램을 나눕니다.
이 솔류션 중심으로 실무에 사용된 프로젝트 소스를 가지고
교육을 하면 이론적으로 배우는 것보다 초보 개발자가 빠르게
개발 기술을 습득할 수 있습니다.
[ 검색키로 사용될 인덱스 테이블의 설계]
이 방법은 표준적인 방법이 아닙니다.
우선 검색에 자주 사용되는 필드를 인덱스 테이블로 생성합니다.
입력 받은 검색 키에 대하여 반환 받은 값이
레코드 한개의 값이 될 수 있도록 설계를 합니다.
수 많은 연결이 발생 되더라도 클라이언트로 한개 값을
반환하는 것은 그리 큰 문제가 아니라고 생각됩니다.
이 한개의 레코드를 반환 받기 위해 검색키로 비교될 필드는
유일해야 합니다.
마치 인덱스 테이블의 프라이머리 키처럼 제약을 합니다.
이 반환받은 레코드 값을 임의의 변수-바이트 타입이면 좋겠죠.-
에 저장해 놓고 우리가 필요한 필드 값만 취하면 되겠죠.
가져오는 구체적인 방법은 포인터 개념을 참고하시면
쉬울 듯합니다.
만약 특별하게 설계된 테이블과 필드에서 질의를 한 결과 값이
여러개의 레코드일 때는 당연히 리스트 객체에 저장해 놓고
여러분 맘대로 가지고 놀면 되겠죠.
보관 할 변수의 타입이 리스트 객체 말고는 아직 잘 모르겠어요 .
음...배열 방법을 사용해야 하나요?
음 배열도 알고 보면 시작 번지를 취하는 것이니까요
아무튼 전 리스트박스 콤포넌트가 좋습니다.
[너무 빠른 소프트웨어 개발기술]
이곳 광주에 처음 8비트 컴퓨터가 소개 된 때가
바로 어제 같습니다.
DOS운영체제 이전의 CP/M 이란 운영체제에 한참 맛들여 있었는 데
취미로만 프로그래밍하다 막상 직업적으로 프로그래밍하려고 하니
많은 어려움이 있습니다.
정말 열정을 가지고 한가지만 꾸준히 고집했더라면 지금은 고수의
반열에 올랐을 텐 데...
제일 아쉬운 것은 Z80A용 어셈블리어와 C언어에 더 관심을
가져야 했었는 데 못내 아쉬움이 남습니다.
갑자기 저의 은사님의 한마디가 생각나네요?
" 소프트웨어 개발에 있어서 그 툴을 잘 알고 함수를 많이 알고
잘 사용하는 것도 중요하지만 그것은 가장 낮은 단계의
하급 기술자이다.
제군들이 무한한 가능성을 갖고자 한다면 구현 단계 이전의
설계 기술과 그리고 업무 분석 단계에서 실제 세계의 일들을
얼마나 빠르게 전산 세계로 이끄는가 매우 중요합니다.
그러기 위해서는 특히 전산수학, 통계 등 수학을 잘해야 하며
알리즘과 자료구조를 명확히 공부해야 합니다. "
[DB연결과 SDI폼 그리고 MDI폼]
델파이를 비록하여 모든 비쥬얼 툴에서 DB와 연동 할 때 SDI 폼
보다는 MDI폼을 선호 합니다. DB와 연동 할 때는 여러 PM님과
소장님들 거의 모두 MDI 폼을 추천합니다.
SDI 폼이든 MDI 폼이든 그것은 개발자 취향인데 특별한 이유를
말해주지 않고 단지 팀원들에게 그렇게 권유합니다.
[DB관련 프로그램]
대형 ERP 즉 전사적 자원관리가 아니라도 일반 사무에서 혹은
업무에서 DB 관련 프로그램이 필요로 합니다.
도스 플랫폼에서 우리가 클리퍼를 사용했듯이
미니 프로젝트의 필요성은 아직도 있다고 봅니다.
그런면에서 델파이는 매력적인 툴임에는 틀림 없습니다.
유지 보수를 한다해도 그렇습니다.
델파이를 사용하다 보면 첨엔 그것을 못 느끼나 사용하면
할 수록 뛰어난 툴이라는 것을 느낍니다.
비록 영문 메뉴로 되어있지만 일단 델파이에 맛을 들이면
그 깊은 속으로 빠져들게 합니다.
*.DBF 나 파라독스 테이블 그리고 인터베이스는 공통적으로
개발자가 쉽게 제어 하도록 합니다.
파워빌더의 기업판 가격이 비싸서 초창기 대기업 중심의
솔류션에서 많이 사용되었습니다. 그 특징은 C++ 기반으로
다른 플랫 폼에 이식성이 강하다고 하겠습니다.
그러나 델파이는 윈도우 플랫폼에서 가장 강력한 위력을
나타내고 있습니다.
빠른 컴파일 안정적인 코드생산 그리고 윈도우 플랫폼에
안정적인 동작등 수 많은 장점을 가지고 있습니다.
[질의 결과 값과 첨자]
질의를 하여 그 결과로 한개의 레코드를 반환 받았을 때
이 한개의 레코드에서 우리가 원하는 값을 가져와야 되는데
가끔 실무에서 첨자를 잘못 사용하여 PM님이나 다른 팀원에게
핀잔을 듣는 경우가 많습니다.
" 아직 기초가 부족하다는 말과 함께" ..키킥...^^
테이블 명이 BaBo이고
필드명이 생성 할 당시 순서대로 나열하면
A1, A2, A3...
여기서 첨자는
첫번째 필드 A1는 0
두번째 필드 A2는 1
세번째 필드 A3는 2
n번째 필드 An는 n-1 이 됩니다.
음 제가 넘 어렵게 설명한듯합니다.
이 개념은 실무에서 사용되는 경우가 있으니 꼭 기억해 두세여...
[참고 서적의 소스들]
입문하신 분들이 책에서 따라해보라는 대로 소스 코드를
그대로 타이핑하고 컴파일한다음 실행하는 경우 책에서
나오는 결과 값이 나오지 않아서 짜증을 내거나 그 책을
발간한 출판사를 원망하게 됩니다.
프로그래밍 관련 서적들을 보실 때는 먼저 그 원리 파악에
관심을 두셔야합니다.
어떤 책들은 오타가 심해서 사용된 변수명이 다르거나
아님 개발툴 버전이 달라서 없어진 함수를 호출하는
스크립트가 있는 경우엔 에러를 내는 것은 당연하겠지요 .
인내심을 가지고 어떤 로직을 가지고 초기화는 잘되었는지
사용된 변수가 오타는 아닌지 살펴 보아야 합니다.
[SQL문의 결과값]
RDBMS에서 필드에 프라이머리 키로 제약을 준다면
자동적으로 인덱스를 생성하는 것으로 알고 있습니다.
만약 특정 테이블의 필드가 빈번하게 사용되고 검색 키로
사용된다면 의도적으로 빈번한 검색이 이루어지는 필드를
인덱스를 생성하고,프라이머리 키의 제약을 필드에 준 것처럼
인덱스테이블의 인덱스 필드를 유일하게 지정한다면 제약하고
이 유일한 인덱스 필드를 검색키로 사용하면 조건 질의에서
언제나 질의에 대한 결과 값은 한개의 레코드 값을 반환합니다.
만약 한개 값을 반환하지 않는다면 임의로라도 그렇게
설계해야합니다.
이런 경우엔 클라이언트의 다중 접속을 해도 상관이 없습니다.
즉, 수 많은 연결이 발생되더라도 그리 문제가 되지 않습니다.
그런데 문제는 조건 질의에 대하여 결과 값이 많은 수의
레코드 일 때 입니다.
이 때는 그 결과 값을 클라이언트로 가져와 리스트 객체에
저장해 놓고 질의 결과 값 내에서 다시 질의 하는 경우에는
많은 트레픽을 유발시킵니다.
수 많은 자료를 클라이언트로 전부 가져오는 것은
비효율적입니다.
어쩔 수 없는 경우라면 포인터 객체를 이용하던지 아니면
리스트 객체를 사용하여 그 결과 값을 임시로 저장합니다.
오라클 같은 고성능의 DB라면 클라이언트로 가져오지 않고
첫 번 째 질의에 대한 다수의 레코드 결과 값내에서 다시
중복 질의하여 오직 하나의 레코드만 반환 받을 수 있습니다.
그래서 SQL문을 사용하실 땐 신중히 사용하시기 바랍니다.
[ 입력 콘트롤부의 초기화 ]
사용자 입력을 받는 콤포넌트의 초기화는
여러 방법들이 사용됩니다.
사용자가 취소 버튼을 누르거나 다른 목적으로 초기화 시킬
필요가 있을 때 모듈내에서 초기화 과정을 하나의 프로시저로
묶어 놓으면 참 편리하답니다.
[ *.~df *.~pa 파일의 효용성 ]
*.~df는 *.dfm의 백업 파일이구요
*.~pa는 *.pas의 백업 파일입니다.
성격이 급해서 원하지 않던 작업이 갱신 되었을 때
파일명을 각각 *.dfm 이나 *.pas로 이름을 변경하여 앞전의 소스를
복원하실 수 있습니다. 어떤 분들은 이것이 귀찮다고 하시는데
전 매우 편리하다는 생각을 합니다.
이것의 사용 여부는 델파이 메뉴에서
[ Tools - Environment Options - Display ]를 선택하고
Display and file options 아래에 보시면
Create backup file에 체크하게 되어 있습니다.
[ 주석문의 이텔릭체 해제 ]
델파이 기본 설정에선 주석문이 이틸릭체인데여 그럼 알아보기가
힘들어서 그것을 변경하면 참 편리해요
델파이 메뉴에서
[ Tools - Environment Options - color ]를 선택하고
왼쪽 창의 목록중에 Comment를 선택하고 오른창 중에서 Italic을
체크표시를 해제합니다.
[ 컴포넌트 색상 변경 ]
한델 팁모아 게시판에 껄떡쇠 님이 올려 주신 팁이 있는 데요
"프로퍼티의 color값 쓰는 곳을 더블클릭하면 색상을
선택하는게 나타나요"
저도 이것을 몰라서 좀 해맸습니다.
나타나는 목록 중 하나를 선택하는 것을 알았어도 거기를
더블 클릭 해야 한다는 것을 미쳐 몰랐네여 . 히 ~^^
[ DB용 공통 유닛의 제작 ]
공통유닛의 이름을 임의로 [ MyComm.pas ]라고 만들겠습니다.
여기에는 비쥬얼 객체가 사용되지 않으므로
implementation 문 아래에 {$R *.DFM} 있다면 삭제 하십시요 .
그럼 *.res 나 *.dfm 파일들은 참조하지 않아도 될겁니다.
함수와 프로시져 차이는 반환 값이 있는지 없는지 인지를
잘 아실것입니다.
SQL문 실행을 위한 함수는
Procedure 임의의 프로시저명(질의 결과값을 보관할 변수명:
바이트; SQL문: 스트링);
임의의 프로시저명에는 삭제,추가,갱신,취소 등에 관련된
이름이 좋겠죠.
var
변수명이 어쩌고 저쩌고
begin
Query.Close;
Query.Sql.Clear;
Query.Sql.ADD(SQL);
질의 성공여부 판별자 ---- 불리언 타입
try
Query.Active := True; { 질의 시작 }
Except
질의 성공여부 판별자
여기에 BDE 에러 코드들 가로채어 case문을 사용하여
사용자가 알기쉬운 메시지 창을 띄워줘도 괜찮을 듯
end;
end;
DB에 관련하여 어떤 공통 함수를 만들어 두는 것이 편리 할까요?
1. 동적 DB 연결
2. 동적 DB 연결 해제
3. 동적 질의 객체 및 DB 소스 생성
4. 동적 질의 객체 및 DB 소스 해제
5. 특정 검색 키에 대하여 자료를 가져옴
6. SQL문 실행
7. 테이블 락킹 시작
8. 테이블 락킹 검사
9. DB 커밋
10. DB 롤백
위의 의사코드를 보시고 여러분도 한번 만들어 보세요
[ 델파이 응용프로그램과 RDBMS의 연결 ]
입문하신 분들에게는 모든 것이 어렵습니다.
특히 DB와 연동 문제는 더욱 그렇습니다.
참고 서적들을 살펴보면 연결 방법이 넘 쉬어서 그런지 몰라도
자세히 언급되지 않았습니다.
DB연결을 하다 잘 안되어 날 새는 경우가 허다하구요
회사내에 선임자가 알고 있어도 잘 안가르쳐 주는
경우가 많습니다.
막고 품으라는 둥, 알아서 해결하라는 둥 ...^^
우리에게 알려진 DB는 오라클, MySQL, MS-SQL, 사이베이스,
인포믹스, 인터베이스등 종류가 많습니다.
우리에게 알려진 DB에 연동하는 방법은
그 개념 자체가 유사합니다.
단지 구체적인 설정 방법이 다를 뿐이지요
전 몇 가지로 분류했습니다.
1. ODBC 드리이버를 사용하는 방법
2. BDE 네티브 드라이버를 사용하는 방법
3. 특별하게 만든 소켓을 사용하는 방법
4. 기 타 .
공통적으로 CLS 툴을 사용한 연결이 있습니다.
RDBMS 서버에 접근하기 위한 클라이언트 툴의 종류는 각각의
DB 종류에 따라 다릅니다.
자동실행 파일인 autoexec.bat에 이 클라이언트 툴이 있는 곳의
경로가 잡혀 있어야 됩니다.
TCP/IP 프로토콜을 위해서는 윈도우가 설치된 디렉토리안에
hosts 와 services 파일이 올바르게 설정되어야 합니다.
[ PM님께서 해주신 말씀들 ]
1. 프로젝트 완료후 개발자가 포기하지 않고 꾸준히 관심을
가지고 개선해야 고품질의 제품을 만들 수 있다.
2. 아무리 최고 성능을 자랑하는 RDBMS라 할지라도 모든 것을
만능처럼 처리해 주지 않는다.
개발자가 원하는 데로 방향을 설정해주어야 한다.
질의에 성공했는지 실패 했는지 판별자를 별도로
만들어 주어야 한다.
트렌젝션 테스트는 10,000건 이상의 실제 레코드로 해야한다.
질의에 실패시 사용자에게 어려운 에러코드를 가로채어
사용자가 이해하기 쉬운 메시지로 표시해주어야 한다.
각종 변수, 상수, 입력 콤포넌트는 사용하기 전에 반드시
초기화 한다음사용하고 사용한 다음에는 메모리에서
해제 시킨다.
DB 연결은 세션별로 접근하고 사용한 직후엔 연결을 끊는다.
3. 항상 자료형 변환에 주의해야한다.
다른 형태의 자료형을 스트링 형태로 변환하는 데 주의해야 한다.
4. DB에 관해서는 막고 품어라 .
고생하지 않고 깊은 고민 없이는 내 것으로 만들기 힘들다.
5. 우리 개발자에게 칼 퇴근은 허용되지 않는다.
6. 돈을 벌 목적으로 프로그래밍하지 말고 프로그래밍에만
정렬을 가져라.
7. 나의 사전에는 access violation error가 없다. ㅋㅋㅋ
조금만 주의하면 이 에러를 막을 수 있다.
8. 고객의 의견은 친절하고 조용히 경청하고 프로그램 개발에
대한 이해를 먼저 구한다.
9. 인간관계를 소중히 해야 한다.
10. 상용이든 자기가 직접 만든 컴포넌트이든지 반드시 전체
소스코드가 있는 컴포넌트를 사용한다.
그래야 개발툴의 버전 업그레이드에 대하여
마이그레이션이 가능하다.
*.dcu 형태로 제공되는 컴포넌트는 사용하지 말 것.
[ 버튼에 대한 이런 생각, 저런 생각 ]
우리가 프로그램을 만들다 보면 약방의 감초처럼
버튼이 사용됩니다.
버튼은 저장,취소,닫기,종료 등 다양한 목적으로 사용됩니다.
한가지 로직을 알려 드리오니 꽤 쓸만한 방법은 아니지만
사용하셔도 괜찮을 것 같습니다.
먼저 비트버튼 컴포넌트를 상속받아 여러분의 임의의 버튼
컴포넌트를 만듭니다.
특별한 기능을 오버라이드 하실 필요는 없답니다.
요렇게 만들어진 버튼을 사용하시면,이 사용자 정의의 버튼
컴포넌트가 없으면 델파이에서 소스보기가 힘들어 지겠죠.
물론 고수님들은 텍스트 에디터로 보시면 되겠지만요.
[ 로그인 폼의 설계 ]
로그인 폼은 다양한 로직이 사용됩니다.
1. *.ini 파일을 이용하는 방법입니다. 암호화 알고리즘을
이용하여 *.ini 파일로 저장했다가 로그인시 다시 읽어드려
인증하는 방법입니다.
2. DB에 인증을 위한 사용자 테이블을 만들고 사용자 ID,
비밀번호 필드에 미리 입력하여 두고 입력 받은 값과 사용자
테이블에 저장된 값과 비교하여 인증하는 방법입니다.
3. 레지스터리를 이용하는 방법도 있습니다.
4. 기타 여러가지 방법이 사용되지만 제가 배우는 대로
여기에 첨삭 하겠습니다.
파워빌더에 익숙해져 있던 처음엔 델파이는 솔직히
불편했습니다.
윈도우 바탕화면위에 둥둥 떠있는 메뉴가 그랬습니다.
하지만 지금은 델파이가 넘 편하고 좋습니다.
정직하고 솔직했던 저는 입사시 좀 무리한 배짱을 부렸습니다.
면접시 무엇이든지 다 구현 가능하다고 ...^^
하지만 델파이 쪽은 툴 다루는 방법하고 몇 개의 함수 밖에
몰랏습니다.
어떻게 해서 저희 PM님을 알게 되었습니다.
PM님은 솔류션 하나를 꾸준히 작업을 하셔서 나름대로 독특한
구현을 하신분입니다.
비록 두 달 남짓 짧은 기간이지만 교과서로 배울 수 없는 값진
것들을 배울 수 있었습니다.
전 아직도 초보 티가 물씬 풍기지만 델파이와 DB 관리에
자신감을 갖게 되었습니다.
이 글을 통하여 감사드리고 쉽습니다.
[ 테이블의 동적 생성 ]
여러분은 DB를 설계하실 때
SQL Explorer나 Database Desktop를 사용하여 테이블의
생성,추가,삭제 작업을 하실 것입니다.
일단 만들어진 DB는 백업만 잘해두면 그것을 가지고 데이타
펌프 같은 것을 사용하여 적절하게 이용하시면 될 것입니다.
하지만 DB를 관리하다보면 레코드가 전혀 없는 테이블만 생성된
DB가 필요 할 때가 있습니다.
1년 단위로 결산하여 1년간의 DB 자료는 백업 보관해두고
새로운 DB에 레코드를 입력해야 할 때 그리고 기타 이유로
이것이 필요해 집니다.
하지만 수 많은 테이블을 각각 데이타베이스 데스크 탑의
empty 메뉴를 사용하여 테이블의 레코드를 삭제하는 작업은
매우 귀찮은 작업입니다.
또한 처음 DB를 설계할 때 처럼 데이타베이스 데스크 탑에서
테이블을 생성한다면 한참 동안의 시간이 소요 될 것입니다.
이럴때 테이블 동적 생성용 소스를 만들어 두면 매우 편리합니다.
물론 테이블을 생성하고 나서 인덱스 테이블을 생성하는 함수를
같이 만들어 두면 좋구요 .
case문을 응용 하시면 도움이 될 것 같습니다.
이 모듈은 사실 메인 폼이 생성하는 이벤트에 추가하여
한번만 실행하면 레코드가 들어 있지 않는 빈 깡통의 DB의
테이블이 만들어 질 것입니다.
[ 프로젝트 모듈의 설계 ]
program MyProject;
uses
Forms,
windows,
MyUnit,
Splash,
main in 'main.pas' {MainFrm},
login in 'login.pas' {LoginFrm};
{$R *.RES}
begin
Application.ShowMainForm := False;
Application.Initialize;
SplashFrm :=TSplashFrm.Create(Application);
SplashFrm.Show;
SplashFrm.Update ;
Application.Title := '나의 프로그램 ';
Application.CreateForm(TMainFrm, MainFrm);
Application.CreateForm(TLoginFrm, LoginFrm);
SplashFrm.Hide ;
SplashFrm.Free ;
Application.Run;
end.
위에 있는 소스는 MyProject.dpr의 일부 내용입니다.
이것은 임의로 만든 것으로 실제로 사용되는 여부와는
관련 없습니다.
프로젝트 모듈에는
1. Y2K 처리를 위한 로직
2. 응용 프로램 실행시 메인 폼이 나타 낼 때까지
스플래쉬 화면 처리
3. 응용 프로그램의 타이틀 동적 생성 처리
4. 로그인 처리 즉 인증처리
등을 처리하면 조은 일입니다.
위의 소스를 임의로 제가 만든 이유는
위에 USES문 아래 보시면 MyUnit이라는 것이 있지요 ?
이것에 대해 생각해 보려구요.
음 이 유닛에는 공통적으로 사용되는 프로시져나 함수가
포함 될 수 있습니다.
아니면 자기만의 노하우에 관련된 것을 구현하셔도 되구요.
실제 업무용 소스를 살펴 보면 이렇게 프로젝트 모듈에
소스안에 바로 코딩하지 않고 별도의 유닛에 작성하여
포함시키는 경우가 별로 없습니다.
물론 컴파일 과정에서 소스에 직접코딩하시거나
이렇게 별도의 유닛에 미리 작성하여 포함시키는 것은
같은 의미이며 컴파일 결과는 같습니다.
[ 윈도우 미디어 플레이어 ]
프로그램을 고급화 시키거나 완성된 프로그램을 화려하게
포장하려 할 때 여러가지 멀티미디어 기법이 사용됩니다.
멀티미디어를 고려한다면 윈도우 미디어 플레이어를
고려 해야 합니다.
델파이에서 미디어 플레이어 파일들을 지원한다 해도 가끔은
의외의 상황이 발생 될 수 있습니다.
멀티미디어 파일들의 포맷은
*.asf *.asx *.wm *.wma *.wax *.wmv *.avi *.wav *.mpeg
*.mpg *.mpe *.m1v *.mp2 *.mpv2 *.mp2v *.mpa *.mp3
*.m3u *.mid *.midi *.rmi *.ivf *.aif *.aifc *.aiff *.au
*.snd *.mov *.qt 등이 있습니다.
여러분이 미디어 플레이어 풀 버전을 설치하신다해도
동영상 파일을 재생하실 수 없는 경우가 있습니다.
그것은 코덱 문제로 코덱은 코더 디코더를 말합니다.
미디어플레이어전체 설치 프로그램은 코덱을 다운 받으시더라도
더미 코덱만 가지고 있습니다.
따라서 별도의 코덱제작 업체에서 코덱을 다운 받아
설치하셔야 합니다. 즉 3th Party 제품입니다.
동영상 재생 파일의 확장자가 *.avi 이더라도 재생이 안되는
경우가 있는 데 *.AVI 까지도 옛날 포맷이 있고 새로운
포맷이 있습니다. 다만 확장자만 같을 뿐입니다.
별도의 코덱을 다운 받아 설치해도 모든 문제가 해결되는
것은 아닙니다.
인터넷 익스플로러 4.0과 유사한 버전에서 많은 제약사항이
발생됩니다.
결론은 인터넷익스플로러 5.0 이상이 설치되어야 어느정도
미디어 플레이어가 동작 됩니다.
많은 사용자들이 미디어 플레이어 재생문제에 대하여 질문을
올리는 데 그들의 공통점은 대부분 인터넷 익스플로러
4.0이하의 버전을 사용한것으로 나타납니다.
[ 소스를 감추는 여러가지 방법들... ]
개발자가 개발하면서 너무 고생을 해서 나만의 노하우를
간직하고 싶을 때 여러가지 방법을 사용하여 소스의 보호를
하게 됩니다..
첫번째 방법은 HDD의 LOCK을 이용하는 방법입니다.
이것은 소프트웨어의 암호화 알고리즘을 사용하여 HDD에 LOCK을
거는 방법인데 CMOS SETUP에 암호입력 설정하는 경우처럼
HDD에 접근에 제한을 두는 방법입니다.
두번째는 자주 사용되는 공통 함수나 전역변수 그리고
인터페이스를 하나의 유닛으로 통합하고 즉 공통 유닛을 만들고
*.DCU 형태로 공급하는 겁니다.
일반적으로 개발용역 계약에 따라 소스까지 납품하게 된다면
일단 컴파일이 되어야 하니까 *.DCU 형태로 납품하면 됩니다.
세번째는 특정 공통함수 모듈을 런타임 *.DLL 형태로 만들어
사용하는 방법입니다.
네번째는 감추고 싶은 함수를 한 유닛에 모아 컴파일 할 때
사용하고 납품 할 때는 해당 유닛을 빼 버리는 방법도 있습니다.
[ 데이터 베이스와 윈도우 운영체제의 확장자 ]
윈도우 운영체제에선 확장자[file type]가 많은 의미를 가지고
있읍니다.
어떤 경우에는 확장자에 대한 응용 프로그램이 설정 되어 있다면
윈도우 탐색기에서 더블 클릭하게 되면 확장자에 설정된 응용
프로그램에서 불러 오게 됩니다.
인터베이스 확장자는 .gdb 입니다.
윈도우에서 인터 베이스를 사용 할 때 이것이 인터베이스
특정 파일로 인식해버려 파일에 대한 공유 위반등 귀찮은
문제가 발생합니다.그러니까 특정 파일에 대한 이벤트 발생시
중복 실행이 염려가 되네요.
그런 일이 생기진 않지만 혹시 모르잖아요?
이것을 피하기 위해 데이타 베이스 이름에 확장자를 주지 않고
데이타 베이스 이름을 설정하는 것입니다.
보통 테이블이 아직 만들어 지지 않는 인터베이스 RDBMS 이름은
사용자의 정의에 따라 임의로 만들어 질 것입니다.
예를 들면
MyDB.GDB
User.GDB
BaBO.GDB
이것을 다음과 같이 수정합니다.
MyDB
User
BaBo
이렇게 수정하게 되면 윈도우 운영체제에선 그냥 일반
파일로 인식하게 되어 속이 편하게 됩니다.
[ 검색 로직의 한가지 ]
DB 관련 코딩을 할 때 사용자가 검색할 키를 입력하면 공백이
입력되거나 아님 특수문자가 입력되거나 해서 DB의 키에 따른
필드와 비교가 안돼서 올바른 질의가 안돼는 경우가 있습니다.
이럴때 아우터 조인을 사용하지 않고 관련 자료를 가져오는
로직을 설명합니다.
하나,사용자가 입력한 내용을 검색키로 하여 관련 테이블에서
조건에 맞는 레코드를 가져와 저장합니다.
둘,질의 결과내 자료에서 특정 필드의 값을 가져와 저장합니다.
저장된 값을 검색키로 하여 다른 테이블의 조건에 맞는
레코드에서 특정 필드 값을 가져옵니다.
셋, 완료
쩝...쉬운 로직을 넘 어렵게 설명했나요? 미안해요!
[ 구현 방법의 두 가지 ]
코딩 할 때 두 가지 방법이 있습니다. 어떤 것이 옳은 지는
잘 모르겠습니다.
하지만 자기 취향 대로 하심이 ...캬캬~
한가지는 스크립트 코딩시 비쥬얼 컴포넌트를 올려 놓고
콤퍼넌트 속성이나 이벤트에 가두어 놓고 코딩하는 방법입니다.
예를 들면 질의 문장 수만큼 질의에 관계된 컴포넌트를 올려 놓고
스크립트 하나가 한 컴 포넌트를 점유하는 방식입니다.
이것의 장점은 구현 시점에서 코딩이 빠르게 할 수 있습니다.
또한 구현이 용이하고 쉽습니다.
단점은 유지 보수 할 때 다른 개발자가 각 컴포넌트의 속성을
찾아바야 되고 유지 보수가 쉽지 않고 델파이 버전 차이나
컴포넌트 손상시 소스를 불러오지 못하며
많은 컴포넌트를 사용하는 점입니다.
다른 하나는 모든 컴포넌트나 객체를 스크립트에서 동적으로
생성 및 구현하는 방법입니다.
이 방법의 장점은 유지 보수가 쉽고 개발자 자질에 따라 소스가
체계적으로 구현 될 수 있습니다.
단점은 스크립트를 코딩하는 시간이 길어지고 비 시각적이라
취향이 다른 개발자에게 난해하게 비추어 집니다.
[ 개발과정의 준수 ]
고수님들 옆에서 코딩하시는 것을 지켜보노라면
안타까운 일이 있습니다.
머리속의 구상을 별다른 설계없이 곧 바로 구현하시는 점입니다.
저의 은사님들은 꼭 의사코드를 작성하게 하고 입출력창을
먼저 설계하도록 권유하셨습니다.
만약 이를 어기면 호되게 꾸중을 하셨읍니다.
실무에서 이렇게 하기가 매우 어려운 일이고
개발자 3명이 할 일을 혼자 다 하시는 걸 보면
고수님들은 수퍼맨이란 생각이 듭니다.
하지만 팀 프로젝트에선 별로 좋은 일이 아니란 생각이듭니다.
물론 모듈별로 실행파일을 별도로 만들어 버리면 할 수 없는
일이지만...
[ 개발자와 면접 ]
면접을 받으려 갈 때는 준비를 철저히 하여 자기의 실력을
표현 가능한 포트폴리오를 만들어서 가져가도록 합니다.
실무 경력이 있는 분은 그 경력을 증명 할 수 있는
문건 예론 재직증명서를 제출하도록 합니다.
어떤 분야에 대해 한번이라도 다루어 본적이 있다면
잘 할 수 있다고 대답해야 합니다.
물론 이것은 신입에 해당하는 말이고 경력자는
잘못하면 회사에 많은 리스크를 가져다주므로 주의해야 합니다.
저의 기준으로 교육기관에서 정보처리기사 1,2급에 준하는
교육을 받았고, 개발자 양성기관에서 6개월 동안 일요일을 제외한
오전 6시에서 저녁 10시까지 스파르타 식으로 컴퓨터를 손에서
놓지 않고 공부했습니다.
약간의 실무 프로젝트 수행 경험이 있다면 개발자 능력에 따라
다르겠지만 입사후 수습 기간동안 약 3개월이면 충분히
응용 가능한 개발자로서 육성이 가능하리라 생각됩니다.
[ 유닉스에서 부팅 락킹해소 ]
유닉스와 연동해 놓구서 서버/클라이언트 용 프로그램을
개발 중에 있었는 데 성격이 급해서리 서버의 전원을 일찍
내려버려 락킹이 발생되었습니다.
보통 유닉스에 UPS(무정전원장치)를 장착하기도 하구
이렇게 락킹이 발생 할 때는 초기화를 위한 로그파일 백업과
함께 복구용 스크립트 및 실행파일을 준비된 경우가 많습니다.
젤 염려되는 것은 디비관련 HDD의 크래쉬입니다.
또한 락킹이 발생했을 경우 우선 HDD의 기계적 백업이
선행되어야 합니다.
실시간 자동 백업 시스템이 갖춰지지 않았다면
데이타베이스 전체를 잃어버리는 결과를 초래합니다.
데이타 베이스의 성격에 따라 수억의 손해를 발생되게 합니다.
관리자가 이럴땐 사표내도 감당하지 못하겠죠....뭐...
다음 설명은 교과서적인 것이 아닙니다. 그냥 참고만 하십시요.
single user 모드로 로그인하여
[ls -al] 명령을 하면 리눅스 아님 유닉스 공통으로
루트 디렉토리나 아님 root/etc 에 [.pwd.lock]또는 [.pwd.lck]가
보일 겁니다. 이건 부팅 스크립트 환경 설정에 영향을 받겠지만요.
사이즈가 보통 0 인경우도 있구요 이 파일의 소유자는 system입니다.
그런데 슈퍼유저 권한으로 로그인한다해도 프롬프트가 #인 경우
퍼미션 변경명령 예론 [chmod 777]이나
파일 삭제 명령 [rm 파일이름]으로 삭제되지 않습니다.
이럴땐 삭제 명령 [rm -f 파일이름]으로 삭제하시기 바랍니다.
예론 [ rm -f .pwd.lock ]
[ NT 서버의 인터베이스 연결 ]
입문자 분들이 이 글 내용중에도 언급되어 있지만 NT 서버에
인터베이스 디비 연결에 고생을 많이 합니다.
우선 연결하기 전에 NT 서버에서 서비스가 실행되어야 합니다.
유닉스의 데몬처럼 램 상주되어 실행중이어야 합니다.
[ 시작 - 설정 - 제어판 - 서비스 ]를 열고 서비스 목록중에
인터베이스 서버를 선택하고 [ 시작옵션 ]을 클릭하고 나서
[시스템계정]을 선택하고 나서 [서비스와 데스크탑
상호작용허용]에 체크표시합니다.
인터베이스 연결 형식은
[NT서버의 호스트이름:드라이브명: \경로\데이타베이스이름.gdb]
보통 윈도우 운영체제에서 네트워크 드라이브 연결 할때 네트워크
컴퓨터이름 앞에 [ \\호스트이름]을 사용하는 데 인터베이스에서는
호스트이름 앞에 [//나 \\ ]가 오면 절대루 안됩니다.
또한 호스트 이름 다음과 드라이브명사이에 [ /나 \]이
오면 안됩니다.
윈도우 탐색기로 네트워크환경을 클릭하면 컴퓨터이름 목록이
보이실 겁니다. NT 서버가 설치된 컴퓨터 이름이 보이실거에요.
만약 그 이름이 [babo]라고 가정하면
그 형식은 다음과 같습니다.
[ babo: c: \usr\database.gdb ]
임의로 만든 usr디렉토리는 별도로 NT 서버에서 공유나 접근
권한설정 그리고 connect 수를 제한하는 어떠한 설정도 하실
필요가 없습니다.
공유 설정이 안되어도 클라이언트에서도 잘 연결 되실겁니다.
그래서 최근에 게시한 자료가 신뢰성이 있습니다. ^^
비록 초보인 제가 작성한 글이지만 한델의 게시판을 이용하시는
고수님들이 관심을 가져주셔서 그게 제 맘을 기쁘게 했습니다.
전 실제로 초보자라 다른 메뉴들 팁란, 강좌란, 자료실에 자료를
업로드 할 형편이 안되어 주로 자유게시판만 방문하고 있습니다.
[ 이 글에 대한 효용성 ...]
우리 주위에는 델파이 고수님들이 많습니다.
저의 글은 실무 경험과 관련하여 비록 깊이 있는 논의는 아니지만
현실에서 부딛치는 내용들을 담으려 노력했습니다.
또한 이 글을 쓰는 시점이 델파이 개발자로서는 초보자이지만
아무쪼록 다른 분들께 도움이 되었으면 좋겠습니다.
아마도 실무에서 우리 개발자들이 너무 고생을 많이하고
이런 힘든 경우때문에 개발자직을 그만두고 전업을 하는
경우가 많습니다.
그와 더불어 고급 인력이 많이 부족해 질 수 있고 효율적인
기술집적도 어려워 질 수도 있습니다.
솔류션과 관련하여 해법을 찾으려 각종 참고서와 밤을 밝혀 가며
고민하신적이 많을 겁니다.
하지만 내가 어려워하는 부분은 다른분은 너무나 쉽게 해결하고
구현하시는 것을 보면 맘이 착잡해집니다.
특히, SHELL API 함수를 잘 다루시는 분들을 볼 때면
부러운 맘이 듭니다.
[ 얄미운 델파이 고수님 ]
전 물론 델파이 고수님들을 존경하고 흠모합니다.
그치만 고수님들을 옆에서 가만히 지켜보면 얄미운 점을
발견하실 수 있습니다.
예론 델파이도 버그가 전혀 없는 것은 아닙니다.
특정 함수가 특정의 상황에서 버그가 발생하는 것을 미리 알고
고수님들은 교묘히 그것을 피해갑니다. 그러나 입문하신 분들은
그것을 모르고 심각한 번민과 고민에 빠져들게 만듭니다.
이렇게 되면 알고리즘에 뛰어난 개발자라도 스트레스가 많겠죠.
[ 기술 전수자와 전수 받는 자 ]
10년 이상을 한가지 툴 델파이를 가지고 꾸준이 코딩하였다면
그 분이 갖고 있는 기술과 경험은 그 가치를 보면 돈으로는
환산 할 수가 없다. 그리고 그러한 경험들은 시중의 참고
서적에도 나와 있지 않습니다.
그래서 아무리 회사내에서 기술전수하도록 지시 되어 있고
계약이 되어 있더라도 보유자도 인간인데 자기의 지적
재산을 전부 나누어 주겠는가?
보유자가 GNU 정신과 LINUX 정신에 투철하면 모르겠지만 ...휴~
이런 경우는 있겠습니다.
개발자직을 포기하고 다른 직업으로 전업을 생각하는 사람이
자기 기술에 애착이 없을 때 모교전산학과 후배가 도움을
요청 했을 때 전부 다 줘 버리는 경우 ....
어떤 경우는 프로젝트 메니저가 상대방을 생각하여 구체적인
기술을 알려 주었는 데 받아들이는 입장에서 "
그것도 기술이라고 가르쳐 주는가 ?"
라고 야유를 하는 경우입니다.
사장님의 지시는 어떻게든 현제 개발 팀에서 부족한 부분은
프로젝트 메니저가 육성하여 프로젝트를 완료하라는 것입니다.
하지만 프로젝트 메니저의 고민은 우리 회사의 이윤 추구와
매출을 위해 신입 개발자를 육성하고 자사에서 교육을 하였는 데
다른 개발 회사의 스카웃 제의에 쉽게 다른 회사로
옮기는 경우입니다.
생계와 자기의 장래를 위해 옮긴다는 데 더 이상 무슨 말이
필요 하겠습니까?
이렇게 돈으로 자사 인력을 빼내가자 나두 다른 회사에서
다른 인력을 빼내오면 되지 않겠는가?
인력양성은 뒷전이고 그러다 보니 고급 기술은 특정인에게
편중되고 오너들은 돈이면 전부 해결 된다는 깊은 신념을 갖게
되고 어떤 특정 문제 해결에 어려움을 느끼는 개발자를 바로
면직시키고 다른 개발자를 돈으로 스카웃해오는 경우도 생깁니다.
일부 개발자는 창녀나 매춘부로 전락하고 맙니다.
정성을 다하여 육성한 인력이 다른 회사로 옮겨 버리자 프로젝트
메니저 생각들은 다시는 기술 전수를 하지 않겠다는
다짐을 하게 됩니다.
이렇게 되면 거시적 안목으로는 소프트웨어 진흥을
기대 할 수 없습니다.
인도의 IT 기술은 세계최고입니다.
우리나라 개발문화와는 좀 다릅니다.
인도에서는 우리가 어려워하는 문제에 대해선 너무나 쉽게
해결한다고 합니다.
자기 개발 팀의 결속력이 강하다고 합니다.
소위 우리나라와 비교해서 컴퓨터 관련 학원 규모의 개발자
양성 및 교육기관에서 개발자를 양성하는 데..
우리 나라와는 많은 차이가 있다고 합니다.
수료 할 시점에 고급 기술은 모두 배우고 나온답니다.
따라서 실무 프로젝트에 곧 바로 투입해도 되고 따로
교육 할 필요가 없다고 합니다. 그 만큼 고급 기술이
공유되고 있다고 생각됩니다.
하지만 프로젝트 메니저를 맘속으로부터 존경하는 의미가
내포되어 있다면 그것은 나쁜 일이란 생각이 들지 않습니다.
[ 개발자와 인간관계 ]
지금의 현실을 본다면 프로젝트가 빠른 기간내에 완료
될 수 있도록 개발자의 실력과 능력을 중요시 합니다.
그것과 더불어 중요시 되는 덕목은 성실성, 책임감 등입니다.
다 그런것은 아니지만 개발자 분들이 내성적인 분도 많고
고집이 세고 자기 주장이 강한 경우가 많습니다.
개발자가 특정회사에 귀속되어 있든지 아님 프리렌서이든지
인간관계가 매우 중요합니다.
지속적인 일거리는 모두 오프라인에서 알음알이로 얻는
경우가 많습니다.
최종사용자와 개발자와의 끈끈한 인간관계도 중요하고
프로젝트 메니저와 개발자간의 인간 관계도 매우 중요합니다.
아무튼 최선을 다하여 나 아닌 다른 분께 좋은 인상을
주도록 합니다.
우리나라에서 델파이 개발님 중에서 알려지지 않는
고수님들이 많습니다.
저의 프로젝트 메니저님도 그런분들 중의 한분이긴 하지만..
아무튼 고수분들을 맘속으로나마 존경합니다.
실력있는 분들을 알고 있다는 사실 하나만으로 유쾌한 일입니다.
[ 프로젝트 메니저로서의 개발자의 통제 ]
개발자와는 연봉 계약을 많이 하실 것인데 다음과 같은
법적 대응력을 갖추기 위해 서류를 준비해야 합니다.
= 퇴사후 1년 내에 동종 업종 경쟁업체에 입사하지 않겠다는
각서 및 계약서
개발회사가 독특한 아이템일 경우 개발자가 경쟁업체에
스카웃되면 심각할 정도로 회사의 경제적 손실이 발생 됩니다.
요즘은 도덕적으로나 양심적이지 못한 개발자도 있어서
이같은 서류를 갖추는 것을 강추드립니다.
= 회사 소유의 컴퓨터로 가공된 자료 또는 저장된 자료는
회사소유의 자료이고 임의로 삭제하지 않겠다는 각서 및
계약서 회사의 컴퓨터는 공적인 일에만 사용하도록 하고
만약 회사 컴퓨터에 개인적인 자료를 보관하면 그 자료에
대해 회사의 권한도 발생한다는 것을 개발자에게
주의 시켜야 합니다.
= 프로젝트 진행 중에 프로젝트에 심하게 영향을 줄 정도로
회사 컴퓨터로 오락, 채팅, 주식시세, 성인 사이트 접속을
않겠다는 계약서 및 각서.
= 개발과 관련된 모든 자료의 보호 및 취급에 대한 회사와
개발자간의 양해각서
* 위의 서류를 모두 갖춘 다음에 법적대응력을 갖추고 공증을
받도록 합니다.
위반시 민형사상 책임관계가 되도록 서류에 명시하고
다만 회사와 개발자간 평등한 계약이 되도록 문건화해야 합니다.
사용자 측에선 개발자가 개발일에 전념하도록 개발과 관련되지
않는 잡다한 일을 지시해서는 안됩니다.
예론, 개발자에게 경리일을 지시하는 것, 개발과 관련없는
단순한 워드 타이핑,자가용 운전사, 물건 나르는 짐꾼,
프린터 복사기 수리, 상품판매 영업 등등
[ 객체의 메모리 해제 Free 와 Nil 포인터 ]
실무에 사용된 소스를 보면 객체를 메모리에서 해제 할 때
Nil 포인터를 할당하는 것을 볼 수가 있습니다. Free를 사용하는
것과 어떤 차이가 있을까 궁금했었습니다.
나이렉스 한델 게시판에 질답란에 질문도 하고 저의 프로젝트
메니저님에게 질문을 드렸으나 속 시원한 답변을 듣지 못햇으나
오늘 [델파이 코리아] 강좌 난의 민성기님의
객체의 해제와 Nil 포인터란 글을 읽고 조금은
이해가 되었습니다.
객체를 메모리에서 해제 할 때 Nil 포인터를 할당하는 방법은
해당 객체의 포인터에 쓰레기 값이 들어 있는 것을 방지하고
포인터가 초기화 되지 않는 이유로 델파이가 객체의 메모리
해제후 포인터가 Nil 포인터가 아니면 다시 해제를 함으로
그것을 방지하는 역할을 하는군요 .
음, 그렇다면 Nil 포인터를 사용을 자신있게 할 수 있을
것 같습니다.
로그파일 초기화에 사용되는 줄 알았는 데 무슨 이유로
실무용 소스에 Free 대신에 Nil 포인터를 사용하는지
궁금햇었습니다.
[ 테이블의 초기화 ]
제일 처음 테이블을 설계한다음 스크립트로 실행 중에 레코드를
기록할때 입문자 분들은 당황하게 됩니다.
[ General SQL error error code 13059 ] message 입니다.
이것은 프라이머리 키나 또는 반드시 값을 입력을 해야하는
NOT NULL 인경우 초기 값이 입력되지 않아서입니다.
이 때는 데이타베이스데스크탑을 이용하여 require data인
필드에 크기 만큼 9999 식으로 값을 입력하시기 바랍니다.
[ SQL문의 최적화 ]
다중 접속 및 많은 접속자가 동시작업이 진행될 때
RDBMS에 접근해서 해당 ROW 추출을 위해 클라이언트로 가져와서는
가져와서는 곤란합니다.
그렇게 되면 지독한 네트워크 트레픽이 발생됩니다.
한가지 방법은 하나의 SQL 문장으로 많은 작업을 하도록하고
관련 데이터를 클라이언트에 가져오지 않고 RDBMS에서
처리하도록 하고 그 결과 값만 클라이언트로 가져오는 것이
네트워크 트래픽을 줄이는 방법입니다.
이 점에 대해선 오라클 RDBMS가 최적화 되어 있습니다.
여러분이 표준 SQL을 사용하시든지 아님 ISQL을 사용하시든지
그건 개발자 맘대로입니다.
그런데 하나의 SQL문에서 서버에서 추출된 자료의 결과에 대해
재가공하는 스크립트라고 해도 그것을 처리할 시점에 BDE가
다시 표준 SQL문으로나누어 버려 결국 다중 SQL문으로 처리되어
개발자를 당황하게 만듭니다.
가능하시다면 데이터를 가공하기 위해 클라이언트로 데이터를
가져오지 마십시요.
[ 데이터펌프의 사용 ]
여러분이 DB 관련 프로그래밍 하실 때 필요에 따라 관계형
데이터 베이스 따라 자료변환을 해야 할 필요가 생깁니다.
RDBMS 종류를 든다면 오라클, 인터베이스, 인포믹스,
사이베이스, MySQL 등등 ...
여러분이 서로 다른 관계형 데이터베이스에 자료를 구성하신다면
예론 인터베이스에서 오라클 아님 오라클에서 인터베이스로 DB를
변환시키신다면 [DATAPUMP]를 사용하실 겁니다.
물론 다른 툴도 많지만...
그런데 데이타 펌프를 사용하시다보면 종종 잘 안돼는
경우가 발생합니다.
이럴 때는 해당 DB를 파라독스 테이블로 일단 펌프하고 이것을
다시 우리가 원하는 DB로 펌프하시기 바랍니다. 이것의 단점은
파라독스 테이블로 변환 할 시점에 한글코드가 올바르게 변환되지
않는 점이 미흡한 점입니다.
예론 인포믹스 RDBMS의 자료를 인터베이스 RDBMS로 변환 할 때
임의의 인터베이스 깡통 user.gdb를 미리 생성하셔야 합니다.
여기에는 전혀 테이블이 없으면 조은 일이고 테이블이 있더라도
어떤 레코드도 저장되지 않아야 합니다.
펌프진행중에 overwrite 할 것인가 메시지 창이뜨는 데
만약 빈깡통 틀을 계속 유지하고 시프시면 [APPEND] 버튼을
선택하시기 바랍니다.
[ 윈도우 부팅할 때 자기회사 로그 화면 보이기 ]
막상 프로그램 개발을 완료하고 보니 광고효과와 자기 회사를
알리는 목적으로 윈도우 부팅 할 때 자사 로그를 넣어 보겠습니다.
먼저 윈도우 탐색기를 이용하여 c:\msdos.sys의 등록정보를 보시면
퍼미션이 숨김, 읽기 전용 체크표시를 해제하시고 확장자를
msdos.txt로 바꾼 다음에 편집기로 이 파일을 오픈합니다.
다음 섹션에 다음과 같이 추가한다.
[Options]
logo=1
파일 이름을 다시 원래 이름 msdos.sys로 변경시킵니다.
그런다음에 BMP 파일을 320*420 크기로 256 칼라로 로고를 만들어
루트 디렉토리에 logo.sys의 이름으로 저장합니다.
[ 자동 네트워크 로그온 ]
로그온은 윈도우 로그온과 네트워크 로그온이 있는 데
가끔 이것을 생략하고 자동으로 로그온 할 필요가 있습니다.
다음과 같이 레지스터리에 추가 시킵니다.
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Winlogon]
"AutoAdminLogon"="1"
"DefaultUserName"="babo"
"DefaultPassword"="0000"
"DontDisplayLastUserName"="1"
[ 부팅시 응용프로그램 자동실행 ]
특정 업무용 프로그램을 자동실행 시킬 필요가 있을 때
autoexec.bat를 이용하는 방법과 win.ini를 이용하는 방법이
있지만 다음과 같은 방법을 추천드립니다.
레지스터리 추가내용
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices]
"MyApp1"="\"C:\\Program Files\\InterBase
Corp\\InterBase\\Bin\\ibserver.exe\""
"MyApp2"="C:\\myproject\\hantech\\asa.exe"
꼭 옳은 것은 아니지만 다른 개발자가 기본 원리를 이해하지
못한다면 다른 개발자가 구현한 최적화된 소스라 할지라도
사장될게 분명합니다. 이 점이 너무 안타까운 일입니다.
[ 페이징과 스와핑 ]
유닉스 명령 중에 [ sync;sync ]가 있습니다.
이것은 동기화를 의미하는지 제가 정확히 모르지만 현제
기억장치에 있는 내용을 메모리에 읽어 드렸던
디스크에 옮기는 작업을 의미합니다.
우리가 SQL을 사용하면 RDBMS는 최적화된 경로를 따라
해당 레코드를 검색하여 질의한 자료를 찾습니다.
하지만 RDBMS가 항상 최선의 경로를 찾는 것은 아니기 때문에
경우 따라 질의 결과에 대한 응답에 상당한 지연시간이
발생됩니다.
이 경우엔 개발자가 최적의 검색 경로를 스크립트로
구현하여 줍니다.
페이징은 디스크에 있는 자료를 메모리에 로드 될 때나 메모리의
내용을 디스크에 쓰는 경우에 그 프레임 단위를 페이지 단위로
읽고 쓰는 것을 말하는 데 많은 분들이 관계형 데이터베이스에서
잘 못 이해하시는 분들이 많으시는 것 같습니다.
또한 스와핑은 메모리가 부족 할 때 디스크에 메모리 연장으로
임시 기록하고 사용하거나 캐쉬 메모리나 임시 버퍼처럼 기능을
하여 자료의 교환이 발생하는 것을 말합니다.
물론 메모리와 관련해서는 스와핑은 페이지 단위로 발생합니다.
[ MDI폼에서 모달폼 사용 ]
입문자 분들께서 고생하시는 게 있는 데 MDI 폼에서 바로 창을
보여줄 때 다음과 같은 스크립트입니다.
procedure TMainFrm.N5Click(Sender: TObject);
var
Form1: TForm;
begin
Form1 := TForm.Create(self);
try
Form1.ShowModal;
finally
Form1.Free;
end;
end;
윈도우 NT에서 ShowModal이 되지 않습니다.
음 바꿔 말하면 SystemModal 폼을 허용되지 않는다는 말입니다.
이것은 공유 위반이 발생하기 때문입니다.
MDI에서 모달폼을 사용하시려면 모달폼으로 사용하려는 폼의
속성중 visible을 false로 설정하셔야 합니다.
이점에 주의하지 않으면 입문하신분들은 SDI 폼에서 습관때문에
계속 에러를 내면서 왜? 안될까? 고생을 많이 합니다.
이럴때는 이렇게 사용해야합니다.
Application.CreateForm(TForm, Form);
Form := TForm.Create(Application);
[대용량 디비 설계의 미묘함]
대용량 디비에서 isql을 사용하든 아님 표준 sql을 사용하든
아님 네티브 드라이버를 사용하든 ODBC 드라이버를 사용하든
그건 개발자맘입니다. 그러나 표준 질의어에서 질의문에 따라
질의 결과에 대한 응답속도가 약간 차이가 나는 것이
그 신묘함이 있읍니다.
아참 그리고 대용량 디비관련 프로그램을 개발하실 때는 꼭
10,000건 이상의 실제 데이터로 시험을 하시길 바라며
그렇지 않으면 의외의 상황이 발생 될 수 있읍니다.
물론 루프를 돌려 가짜 데이터를 입력 할 수 있으나
개발하시면서 실제 데이터로 테스트 하시는 것과는 많은 차이가
있음을 이해하시게 될겁니다.
대용량 처리를 위한 응용프로그램은 여러가지로 개발자에게
스트레스를 주는 것 같습니다.
테이블 설계를 할 때에도 많은 점을 고려해야 하고
또한 동시작업시 수 많은 커넥션에 대응하는 처리도
고려해야 하고 또한 각 폼이 메모리에 로드될때
최소한 자원이 사용되도록 해야하고 ...등등
대용량 디비를 위한 처리에 대해 일종의 즐거움을 있는 것은
내가 원하는 자료를 검색할 때 검색 속도가 1초라도 빠르게
되면 저만의 즐거움에 빠져들게합니다.
각 테이블에 대하여 최악의 검색인 경우는 피해야하니까요 .
[파라독스 테이블에서의 한글 드라이버처리]
[시작-설정-제어판-BDE 관리자]를 클릭합니다.
BDE 관리자를 보면 제일 위의 탭을 보면 왼쪽엔 데이터 베이스
별칭이 있는 데 [databases]페이지 에서 해당 데이타 베이스
별칭을 선택하고 [LANGDRIVER]를 선택하고
[Paradox Korea 949]을 선택합니다.
다음에 [configuration] 탭 페이지를 선택하고 [+]를 누르면
[drivers]하고 [system]이 보입니다.
[system]을 선택하면 [init]와 [formats]가 보이는 데
[init]를 선택하고 [LANGDRIVER]를 선택한다음에
[Paradox Korea 949]를 선택합니다.
[인터베이스에서의 한글 드라이버 설정]
BDE관리자에서 인터베이스 디비 별칭을 클릭하면 오른쪽에
보이는 [LANGDRIVER]난에 어떤 것도 설정 되어서는 안됩니다.
그냥 공란으로 두셔야 디비에 한글이 잘 입력됩니다.
지금은 인터베이스가 버전이 6.0이고 이점이 개선되었는지
모르지만 고생 많이 했음...책에도 안나와서...^^
[디버깅 작업 중에 인터베이스 락킹해소]
일반적으로 인터베이스를 로칼 디비로 사용하면
파일 시스템 개념으로 본다면 독립된 하나의 파일로 운영체제에서
인식해 버립니다.
물론 네트워킹 공유파일 개념이 있지만 종종 디비가 락킹이
발생하고 운영체제에선 공유위반이 발생합니다.
이 때는 인터베이스 디비를 디스 마운트해도 별루
소용이 없습니다.
스크립트 에러가 없는 경우에도 "directory busy"를 발생하여
초보자를 당황하게 합니다. 이 때는 우선 디비를
디스마운트합니다.
윈도우 오른쪽 하단 트레이에 올라 있는 인터베이스에 마우스
포인터를 위치하고 마우스 오른 쪽을 클릭하면 메뉴가 나오는 데
여기서 디비를 내리고 윈도우 98인 경우에는
[시작-...로그오프]하여 다시 로그온 하거나 시스템을 재시작해야
해소됩니다.
로컬 디비에서 데이타베이스 데스크탑이 먼저 디비 서버에
로그인하여 레코드 수정작업을 하면 다른 프로그램에서
디비에 접근 할 때 락킹이 발생됩니다.
SQL Explorer 사용시 주위해야 합니다.
그리고 테이블을 재설계하거나 수정 할 때는
데이타베이스 데스크 탑보다
SQL Explorer를 사용하시기 바랍니다.
예론 필드 추가 삭제시....
[자료변환 함수의 에러]
자료형태 변환함수 [stringtoint]를 사용하다보면 원인불명의
Access violation error 때문에 모두 고생을 하는 데 이때는
[stringtoint] 대신에 [val procedure]를 사용합니다.
서버/클라이언트 네트워크 환경에서 RDBMS에 연결하는 방법이
구체적으로 연결하는 방법이 첵에도 나와있지 않아서
입문자분들이 고생을 많이 하게됩니다.
예론 유닉스에서 인포믹스, 사이베이스, 오라클 RDBMS 붙이는 거...
오늘 저의 PM님이 가르쳐 주셧는 데 장난이 아니네여.
휴우 쉽지가 않네여.
[ 개발자와 소스]
이 소스엔 개발자의 피와 땀과 고뇌가 담겨있어서 맘속에서
애틋한 맘이 피어오릅니다.
10년이상의 노우하우가 고스란이 담겨있어 더 정이 가는지
모르겠습니다.
PM님은 어떻게 생각하실지 모르지만 이런 소스가 처음부터
입문하신 분들께 주어진다면 많은 도움이 되지 않을까
생각해봅니다.
물론 부정적인 시각도 있을 수 있다는 생각입니다.
개성과 창의성을 저해하는 일인지도 모릅니다.
델파이 소스들은 마치 화원에서 아름답게 핀 화초들 같습니다.
한가지 문제에 대하여 모두들 독특하고 개성있게 처리된 것을
보면 여러 생각을 하게 됩니다.
[ 필드명의 결정 ]
데이터 베이스를 설계할 때 제일 고민인게 바로 필드명입니다.
관계형 데이터 베이스에서 사용된 키워드 즉 예약어를
피해야 하고 길이도 생각해야 하구...기타등등...
저의 PM님 충고 ..." 만약 테이블 사양서를 보고 코딩을 할거라면
A 테이블에 대해서 필드명에 특별히 의미를 부여하지 않고
A1, A2, A3, A4, A5...An으로
B 테이블에 대해서 필드명에 B1, B2, B3, B4, B5... Bn
물론 주석이 충실하다면 많이 편리한 것 같다네."
[ 비고 난의 자료형태 ]
여러 가지 이유로 필드의 자료형을 char를 사용한다해도 비고난을
char형을 사용하는 것은 낭비인 것 같아요.
비고난을 검색키로 사용하지 않는 다는 전제하에 vchar형태로
많은 길이를 할당하는 것이 조을 것 같아요
언젠가 검색키로 NUMERIC형을 사용했다가 은사님으로부터
주의를 받은 적이 있습니다.
아무래도 검색키는 char형이 여러모로 조은 것 같아요.
개발자 맘이지만요
물론 설계하면서 상황에 따라 다르겟지만요.
[ 내컴퓨터에 로칼 인터베이스 RDBMS 마운트 하기]
델파이 정품 시디를 넣으면 설치화면이 나오는 데
인터베이스 서버 5.0과 인터베이스 클라이언트 5.11를
설치합니다.
설치하고 나면 인터베이스 서버는 다음과 같습니다.
"C:\Program Files\InterBase Corp\InterBase\Bin\ibserver.exe"
"C:\Program Files\Common Files\Borland Shared\Data\employee.gdb"
ibserver.exe"는 데몬처럼 램에 상주하면서 employee.gdb"를
마운트 시키며 employee.gdb가 RDBMS 역할을 다하도록 도웁니다.
먼저 테이블이 전혀 생성되지 않는 빈 깡통을 만들어 보겠습니다.
로칼 인터베이스 서버를 설치 할 임의의 디렉토리를 만듭니다.
저는 c:\usr 라고 만들겟습니다.
[시작-설정-제어판-BDE Administrator]를 차례대로 클릭합니다.
BDE관리자 메뉴에서
[Object-new]를 차례대로 클릭합니다.
Database Driver Name 화면에서 드라이버 종류를 [INTRBASE]를
선택하고 ok 버튼을 누릅니다.
데이타 베이스 별칭을 임의로 정합니다. 저는 [MyDB]로 정하겠습니다.
오른쪽 화면에서 [LANGDRIVER]에는 아무것도 설정하지 마시고 공란으로
두십시요. 만약 드라이버가 설정되면 한글데이터가 올바르게 입력 및
표시되지 않습니다.
[Server Name]의 오른 쪽을 클릭한다음
위에서 만들어준 임의의 디렉토리를 생각하며 다음과 같이
타이핑 합니다.
c:\usr\DATABASE.GDB
만약 위와 같이 전체 경로명을 적지 않으면 디비를 마운트하는
데 어려움이 있습니다.
[ SQLQRYMODE] 오른 쪽을 클릭하고 [LOCAL]을 선택합니다.
[USER NAME]의 오른 쪽을 클릭하고 [SYSDBA]라고 입력합니다.
창을 닫으면 메시지 창이 뜨는 데 [yes]를 선택합니다.
[시작 - 프로그램- InterBase 5.0- InterBase Server]을 차례로
클릭합니다.
[시작 - 프로그램- InterBase 5.0-InterBase Server Manager]를
클릭합니다.
메뉴에서 [File-Server Login]을 클릭합니다.
User Name 에는 [SYSDBA]를 Password에는 [masterkey]를 입력하고
ok 버튼을 클릭합니다.
메뉴에서 [ File- Database Connect]를 클릭합니다.
["C:\Program Files\Common Files\Borland Shared\Data\employee.gdb"]
입력하고 ok 버튼을 클릭합니다.
반드시 전체 경로를 입력하십시요
메뉴에서 [Tasks-Interactive SQL]를 클릭합니다.
InterBase Interactive SQL 창의 메뉴에서
[Create Database ]를 클릭합니다.
Database 입력난에 [c:\usr\DATABASE.GDB]를 입력합니다.
User Name난에는 [SYSDBA]를 입력하고 Password난에는
[MASTERKEY]를 입력하고 ok 버튼을 누릅니다.
창을 전부 닫고 [c:\usr] 디렉토리를 확인하시면
[database.gdb]가 생성되엇습니다.
[ NT 서버에 인터베이스 RDBMS 설치하기 ]
[클라이언트의 준비]
윈도우 탐색기로 [c:\windows] 디렉토리를 열고 [ hosts]를 찾아
[hosts.txt]으로 이름을 바꾼후 더블 클릭합니다.
다음과 같이 추가합니다. 공백을 반드시 줄 것
127.0.0.1 localhost
210.100.100.1 NTHOST
여기서 210.100.100.1는 NT 서버가 설치된 컴퓨터의
고정 IP 주소 입니다.
여기서 NTHOST는 윈도우 탐색기로 네트워크 환경을 클릭했을 때
나타나는 NT서버가 설치된 컴퓨터의 이름입니다. 즉 도메인이죠
편집을 다했으면 윈도우 탐색기로 원래 파일이름대로
[hosts]환원 시킨다.
위와 같은 방법으로
윈도우 탐색기로 [c:\windows] 디렉토리를 열고 [ Services]를 찾아
[Services.txt]으로 이름을 바꾼후 더블 클릭합니다.
gds_db 3050/tcp # InterBase Server
위를 확인하고 없으면 추가로 입력합니다.
편집을 다했으면 윈도우 탐색기로 원래 파일이름대로
[Services]환원 시킨다.
[시작-설정-제어판-BDE Administrator]를 차례대로 클릭합니다.
BDE관리자 메뉴에서
[Object-new]를 차례대로 클릭합니다.
Database Driver Name 화면에서 드라이버 종류를 [INTRBASE]를
선택하고 ok 버튼을 누릅니다.
데이타 베이스 별칭을 임의로 정합니다.
저는 [NTDB]로 정하겠습니다.
오른쪽 화면에서 [LANGDRIVER]의 설정 부분은 공란으로 둡니다
어떤 언어도 선택하지 마십시요
[Server Name]의 오른 쪽을 클릭한다음
위에서 만들어준 임의의 디렉토리를 생각하며 다음과 같이
타이핑 합니다.
NTHOST:\usr\DATABASE.GDB
여기서 NTHOST는 윈도우 탐색기로 네트워크 환경을 클릭했을 때
나타나는 NT서버가 설치된 컴퓨터 이름이고 : 이후의 것은 NT서버에
임의로 만들어 준 것입니다.
만약 위와 같이 전체 경로명을 적지 않으면 디비를 마운트하는 데
어려움이 있습니다.
[ SQLQRYMODE] 오른 쪽을 클릭하고 [SERVER]을 선택합니다.
[USER NAME]의 오른 쪽을 클릭하고 [SYSDBA]라고 입력합니다.
창을 닫으면 메시지 창이 뜨는 데 [yes]를 선택합니다.
윈도우를 재시작합니다.
[NT 서버에서 준비작업 ]
NT 서버가 설치된 컴퓨터에
델파이 정품 시디를 넣으면 설치화면이 나오는 데
인터베이스 서버 5.0를 설치합니다.
설치가 끝난이후에
윈도우 NT 탐색기로 임의의 디렉토리를 만듭니다.
저는 [c:\usr]를 만들었습니다.
윈도우 NT탐색기로 usr 디렉토리를 선택한후 마우스
오른 쪽 버튼을 눌러 등록정보를 선택합니다.
여기서 공유를 누르고 인터베이스 서버에 접근할 사용자 수를
라이센스에 따라 설정합니다. 예론 5 User ...그리고나서
권한 설정을 합니다.
위에서 만든 클라이언트의 로칼 데이타베이스를 복사합니다.
예를 든다면 위의 경우엔 클라이언트의 [c:\usr\database.gdb]를
NT 서버의 디렉토리 [c:\usr\database.gdb]에 그대로 복사합니다.
그런다음에 NT 서버에서 인터베이스 서버를 실행시키면
"ibserver.exe"와 "employee.gdb" 가 데몬으로 램에
상주하게 됩니다.
위에서 만든 인터베이스 RDBMS를 클라이언트에서 연결 할 때는
NT서버의 컴퓨터 이름:데이터베이스가 설치된 경로:데이터베이스 서버이름
형식으로 접속하게 됩니다.
NT서버의 컴퓨터 이름은 윈도우 탐색기로 네트워크환경을
눌렀을 때 보이는 NT 서버가 설치된 컴퓨터의 이름입니다.
보기를 들면
NTHOST:/usr/database.gdb
인터베이스 서버에 접근은
TCP/IP로 접속하기 때문에 NT 서버의 특별한 계정이 없어도
예론 NT 서버에 로그인하기 위한 사용자 ID와 비밀번호가
필요없고 인터베이스 서버에 접근할 ID와 비밀번호가
필요할 뿐입니다.
이 계정은 인터베이스 서버관리자에서 추가 하실 수 잇습니다.
[ 입문하신 분들에게 추천 할 서적들 ]
여러분이 먼저 시중의 서적을 보시기 전에 델파이 엔터프라이즈
판에 포함되어 있는 개발자 안내서와 개발자를 위한
오브젝트파스칼 이란 책을 꼭 보셔야 합니다.
저작권은 한국 인프라이즈사에게 있습니다.
이 책은 델파이 정품 구입자에게 별도 메뉴얼로 따라 온 것인지는
모르지만 아마도 한국인프라이즈사에서 정품 고객에게
자사 트레이닝 센터를 통하여 교육을 할 때 사용된 교재로
생각됩니다. 무척 두꺼운 책이네요.
일반인들은 쉽게 구하시지 못할 것이란 생각이 듭니다.
차후 인용되는 델파이와 그와 관련된 것들은 인프라이즈 사의
등록상표임을 밝힘니다.
이 두권의 책을 보신 후에는 한델 게시판에 이정욱님이 추천하신
책을 저도 추천드립니다.
* Inside Secrets Delphi4 /Macro Cantu 저 KMK정보산업연구원 윤대원편저
삼각형프레스 1999.2.15. 발행
추가로 다음 책을 추천드립니다.
* 델파이 프로그래밍 바이블 Ver 4.0 / 석봉현, 신문섭 공저
영진출판사 1999. 2. 10.발행
개발관련 서적들은 가능하시다면 번역서를 보시지 마시고
아마존등에서 원서등을 구하여 보시기 바랍니다.
단 번역서중 실무경험을 그대로 옮긴 책은 저도 강추드립니다.
그런 책이 있다면 저에게도 알려 주세여...^^
[ 실제 업무 프로젝트에 들어 설 때]
여러분이 특정 개발회사에 입사하셔서 직접 코딩 하실 때는
기존에 배웠던 습관이나 지식은 보류하시고 그 회사가 보유하고
있는 최적화된 소스를 최대한 수용하십시요.
제가 놀라고 신기하게 생각된 것은 우리가 정석으로 배웠던
델파이 지식이 깨지고 전혀 새롭게 적용되는
경우가 있었습니다.
예를 들면 관계형 디비를 디자인 할 때 반드시 프라이머리키와
포린키를 설정하엿으나 대용량 데이터 처리에선 이것을 둘다
설정하지 않는 경우를 말합니다.
그리고 좀 특이한 것은 표준 SQL과는 달리 ISQL은 파일 기반의
데이터 베이스 처럼 델파이에서 취급하는게 더 편하고
용이하게 되어있다는 점입니다.
오라클 같은 경우는 자체 최적화 되어있으나 델파이 응용
프로그램에서 디비를 취급하는 방법이 왠지 저에게
특이하게 생각됩니다.
우리가 오라클에서 디비 디자인 할 때 자료형태를 CHAR
형태보다도 VCHAR를 사용하라고 배웠습니다.
그것은 기억장소의 절약 때문입니다.
그런데 현제는 저장 매체의 가격이 저렴하여, 이런 자료형태를
사용하는 것은 의미없으며 관계형 데이터베이스를 ISAM방식으로
관리할 때 CHAR 즉 고정길이를 사용하여 인덱스에서 자료를
검색하는 것이 검색 속도가 비슷하다고 합니다.
이것은 PM님의 경험이라고 하는데 전 이해 할 수가 없군요.쩝..
[데이타 모듈 사용에 관련하여 ]
데이타 모듈은 자동 실행 폼 처럼 응용 프로그램 실행중에
데몬처럼 램에 상주합니다.
이 문제에 대해서는 소장님들이 서로 다른 의견을 주셨습니다.
장점으로 보는 시각은
데이타 모듈을 사용하면 데이타 베이스 관련 테이블
통합 관리가 용이하다.
응용 프로그램 실행시 메모리에 로드 됨으로서 별도로 연결을
위한 지연시간이 필요없다.
단점으로 보는 시각은
데이타 모듈은 필요로 하는 테이블 외에 사용되지 않는 테이블과
연결로 인하여 클라이언트의 업무 피크시에 과도한 연결로 인한
과부하가 발생한다 .
윈도우 운영체제의 DLL은 몇 가지 종류가 있는 것으로
알고 있습니다.
공유 *.DLL 같은거...이런 윈도우 실행파일처럼 델파이도
*.bpl이 있습니다.
컴포넌트는 실행시 사용되는 것과 디자인시 사용되는 것으로
분리되는 경우가 있습니다.
보통 실행시 사용되는 콤포넌트 패키지를 c:\window\system
디렉토리에 복사하게 됩니다.
하지만 다양하고 많은 컴포넌트 사용으로 시스템 디렉토리가
파일 크기가 늘어납니다.
물론 다른 디렉토리에 보관하고 autoexec.bat 파일을 편집하여
path를 설정해주면 됩니다.
그런데 다른 분이 제안하여 주신 점이 있어서 소개해 드립니다.
특정 프로젝트와 관련이면 프로젝트 디렉토리 하위에 콤퍼넌트를
저장하고 델파이 IDE에서
[Tools-Environments options-library Tab]의 Library Path에
설치된 컴포넌트 패키지가 있는 곳의 경로명을 추가시킵니다.
컴포넌트를 취급하면서 제가 에러 메시지 만나는 것이 있는 데
'Recursive Used Error" 입니다.
새로운 컴포넌트를 만드실 때 컴포넌트 소스 유닛 이름이
MyCom.pas이라면 콤포넌트 패키지 이름은 MyCom_p.dpk 처럼 다르게
설정하시고 소스 유닛의 procedure Resister 부분에 컴포넌트
파래트 페이지 탭 이름도 위의 이름과는 다른 이름을 설정하시기
바랍니다.
[델파이가 제공하는 기본 컴포넌트 사용에 대하여~]
전 실무에 사용된 소스를 그리 많이 본 편은 아니지만 제가 항상
느낀점은 표준 컴포넌트를 본 모습 그대로 사용한 경우는 극히
드믈었습니다.
델파이 IDE 환경에 있는 기본 컴포넌트는 후손에게 상속하여
주기위한 선조로서의 역할 그러니까 어떤 틀을 제공하여
주는 것 같습니다.
질문 : 왜 있는 그대로 컴포넌트를 나두지 않나요? 소장님 !
답 : 음, 그건 말이야 우선 기본으로 제공하는 컴포넌트가
좀 개성이 없는 것 같고 솔직히 마음에 들 정도로 이쁘지 않아.
음 그리고 그 컴포넌트를 콘트롤 할 때 내가 원하는 행동
그러니까 이벤트가 없는 경우가 많아...
할 수 없이 상속 받아 중복정의 할 수 밖에 없지 ...
그건 또 다른 생명을 불어 넣은 것 같아...
전 그전에도 그렇지만 실무에 사용된 소스에서는 명령을 위한
버튼이나 에티트 등의 컴포넌트에 그렇게 많은 예외 사항을 위한
함수들을 많은 오버라이드 하는 줄은 미쳐 몰랐습니다.
그리고 어떤 분들은 반복된 스크립트라든지 자주 쓰이는 기능을
하나의 컴포넌트로 구현하여 사용하시는 분들도 계시고
또다른 분들은 폼이 들어 있지 않는 유닛 그러니까 공통 유닛을
만들어 참조하도록 하여 사용하시는 분들이 많은 것 같습니다.
얼마전에 델파이 2.0으로 개발된 프로그램을 델파이 4.0으로
포팅을 부탁 받았습니다.
이러한 경우 보통 소스가 없는 *.dcu 형태의 상용 컴포넌트가
사용되면 델파이 2.0에서는 소스를 볼 수 있지만 델파이 4.
소스를 읽어 들이기 어렵습니다.
하는 수 없이 해당 컴포넌트의 선조를 추적하여 찾은 선조
클래스를 가지고 상속 받아 인스턴스를 똑 같은 이름으로 만들어
임시 방편으로 읽어 드리지만 폼에는 어느정도
뿌려지지만 그 컴포넌트가 가지고 있는 이벤트가 문제이군요.
만약 마이그레이션을 고려한다면 콤포넌트를 사용할 때는 기계어
코드 팩키지 형태보다는 꼭 컴포넌트의 *.PAS를 가지고 있어야
한다는 생각을 해봅니다.
[소스 코드에서 사용되는 객체들의 표기 방법]
전 개인적으로 아주 편이한 소스 코드를 조아합니다.
너무 쉬워서 다른분이 보시고 이 정도라면 나두 하겠다
싶을 정도루...^^
이런 편이한 소스 코드의 구현 형태는 원래 개발자가 아닌 다른
개발자가 유지보수를 용이하게 할 뿐만 아니라 그 개발기술을
다음 개발자에게 고스란히 물려 주는 기술 전수의 효과를
가지게 합니다.
또한 복잡한 형태의 업무 로직을 더욱 단순하고 명확하게 합니다.
이런 저의 생각에 제동을 거신 소장님이 계셨습니다.
" 자네가 아무리 그렇게 구현해도 누가 알아주지 않을 뿐더러
그냥 정해진 기간내에 납품하는 것이 제일이지! 역시 회사
오너들은 사업성이 중요 할 뿐이야, 그리고
개발자는 자네 말고두 많이 있어.
자네는 그 수 많은 개발자 중의 한사람 일 뿐이야 ...후후"
" 그래 개발기간 단축이 매우 중요한 셈이야.
돈에 관계가 있으니까..."
[ 오너들의 소프트웨어 개발 마인드]
오늘도 저희 오너의 생각을 경청하였습니다.
다 그런 것은 아니지만 오너들은 개발자가 얼마나 최적화된
코드를 구현한다든지 아니면 다른 개발자들이 흉내내지 못 할
기능을 구현하는지는 전혀 관심이 없읍니다.
다만 그 결과물이 돈이 되는냐 마느냐가 오직 관심사입니다.
그리고 연구 개발직에 종사하는 개발자는 보편적으로 새벽까지
일을 해야만 되는 줄 아시는 고정 관념에 사로잡혀 있습니다.
부족한 기능의 구현이 어려우면 현재의 개발자를 과감히 면직 시키고
그것을 구현 가능한 개발자를 영입하면 그 뿐이라는 생각을 합니다.
돈이라면 만사가 오케이 사인입니다.
오너분들 전부 다 그런 것은 아니지만 ...
[ 개발자와 돈 ]
저를 포함해서 개발자직에 있으면서 경제적으로 곤궁 할 때
특히 결혼하셔서 부양해야 할 가족이 있을 경우엔
더욱 어려움이 있는 것 같습니다.
이 시기엔 마치 헝그리정신으로 불리는 최악의 상황이 될 경우도
있습니다.
프리렌서인 경우에도 일감이 항상 있는 것은 아닌지라 어려움이
있는 경우도 있습니다. 이럴 땐 마당발인 분이 부러울 때도
있었지요
전 개인적으로 이러한 시기에 더욱 연구에 전념하는 계기가 되었지만
나름대로 맘 고통이 심했던 것 같습니다.
고액연봉을 받는 분들도 계시지만 5년이상 경력에도 불구하고
연봉 2천만원 이하에 묵묵히 개발일에 종사하시는 분들이
계셨습니다.
어떤 때는 이러한 괴리감이 자기 자신을 미워하게 만드는 것
같습니다. 분명 돈이 인생의 전부는 아닐 것인 데 말입니다.
[ 폰트 : 글꼴 ]
개발자들이 많이 사용하는 글꼴은 투루타입의 굴림 또는
굴림체입니다.
[ 모니터 해상도 ]
개발자들이 많이 사용하는 해상도는 800*600이며
일반적으로 1024*768를 사용하기도 합니다.
[ 유닉스 관련 ]
[ 참고문헌 : 원저자 소스왕국 김 태 영님 ]
이야기 주제가 델파이 인데 왜 유닉스 이야기 하냐고
반문하실 줄 모르지만
유닉스 서버와 연동해 놓고 델파이로 클라이언트 프로그램을
개발할 때 약간 필요해서 여기다 첨가합니다.
* System booting
1. Power on
전원을 키면 시스템은 자동으로 부팅되며
이때는 multi-user 모드로 된다.
2. 부팅하는 방법
시스템을 shutdown 시킨후 다시 부팅시킬 때에는 ">" 프롬프트
상태에서 다음과 같이한다.
1) multi-user 모드로 부팅할 경우
> b
부팅이 끝나면 "login" 메세지가 나온다.
2) single-user 모드로 부팅할 경우
> b -s
silgle-user로 부팅이 끝나면 "#" 프롬프트가 나오고 자동으로
root 권한을 가 지게 된다.
single-user 모드로 부팅한후 다시 multi-user모드로 전환하고
싶으면 Ctrl+d를 친다.
* System shutdown
1. 시스템 다운전 준비작업
각 사용자들에게 시스템이 다운되는 것을 알린다.
% /bin/wall
(각 사용자들에게 알리는 메세지 type)
Ctrl+d
2. 정상적인 shutdown 절차
% sync;sync
% shutdown now
또는
% shutdown +n (n분후 시스템 다운)
%su root ....... 슈퍼유저로 로그인
#sync;sync
# /etc/halt
3. 시스템을 빨리 re-booting 하고 싶을 때
% /etc/fastboot
fastboot 시에는 memory및 file system(disk) check를 않함
* Host name, Domain name
i. Host Name
각 시스템에 주어지는 고유한 이름
이 host name은 /etc/hostname.(Ethernet Interface 이름) 이라는
화일에 등록되어 있어야 한다.
Ethernet Interface 이름은 보통 "le0", "ie0" 등을 사용한다.
따라서 Ethernet Interface로 le0를 사용한다면
/etc/hostname.le0라는 화일에 host name이 등록되어 있아야 한다.
예) host name이 "soback" 일 경우
% cat /etc/hostname.le0
soback
ii. Domain Name
각 기관에 주어지는 네트웍 상에서 사용하는 이름으로 "."으로
구분되며 형태는 아래와 같다.
ac
co
re
go
mn
ac : 학교 관에서 사용
co : 기업체 연구소에서 사용
re : 연구소에서 사용
go : 정부 출현 기관에서 사용
nm : 각 네트웍 주요 gateway 시스팀에 사용
이 domain name은 /etc/defaultdomain 이라는 화일에
등록되어야 한다.
예) domain name이 "hana.nm.kr"일 경우
% cat /etc/defaultdomain
hana.nm.kr
* Host address(IP address), Network address
1. Host address
각 시스템에 주어지는 고유한 주소로 각각 1byte로 구성되는
4개의 숫자로 만들어 지며 각 숫자는 "."으로 구분된다.
예) 128.134.1.1
2. Network address
network address는 A, B, C 세개의 Class로 구분되며 각각은 2진수로
나타냈을때 아래와 같은 특성을 같는다.
1) A class address
최상위 첫번째 bit가 "0" 인 address로 아래의 범위에 해당하는 address
1.0.0.0 ~ 127.0.0.0
"."으로 구분되는 4개의 숫자중 첫번째 숫자가 network address로 쓰이며
다음 3개의 숫자는 각각 host address로 사용된다. 결국 A class address를
사용할 경우 16,387,064(254*254*254) 개의 host를 LAN 상에 연결할 수 있다.
2) B class address
최상위 두 bits가 "10"인 address로 아래 범위에 해당하는 address
128.0.0.0 ~ 191.255.0.0
"."으로 구분되는 4개의 숫자중 두번째 숫자까지가 network address로
쓰이며 다음 2개의 숫자는 각각 host address로 사용된다. 결국 B class
address를 사용할 경우 64,516 (254*254) 개의 host를 LAN 상에
연결할 수 있다.
3) C class address
최상위 세 bits가 "110"인 address로 아래 범위에 해당하는 address
192.0.0.0 ~ 244.0.0.0
"."으로 구분되는 4개의 숫자중 세번째 숫자까지가 network address로
쓰이며 다음 1개의 숫자는 각각 host address로 사용된다. 결국 C class
address를 사용할 경우254 개의 host를 LAN 상에 연결할 수 있다.
* 새로운 사용자 ID 만들기
1. /etc/passwd 화일에 새로운 ID에 관한 정보를 첨가한다.
첨가사항
ID : 새로 만들 ID 이름
password : 비밀번호. 초기에는 * 로 적고 ID 발급이후 "passwd" 명령으로
원하는 비밀번호로 변경한다.
User-ID 번호 : 숫자로된 사용자 고유 번호.
Group-ID 번호 : 사용자 ID 가 속한 그룹의 번호
Finger Name : 사용자 정보
Home Directory Name : 사용자의 홈디랙토리 이름
Login Shell : 사용자 login Shell 보통 /bin/csh을 사용
위의 사항을 아래의 형태로 첨가한다.
ID:*:User-ID 번호:Group-ID 번호:Finger Name:Home-Directory:Login Shell
2. 사용자 홈 디렉토리 만들기
% mkdir home-dir-name
3. 사용자 홈 디렉토리의 Owner를 그 사용자로 바꾸어준다.
% chown ID home-dir-name
4. 비밀번호 만들기
% passwd ID
위와 같이 치면 입력할 비밀번호를 물어보는데
이때 원하는 비밀를 입력한다.
[이 글에 의견 주신분들의 글 삽입 부분]
[김일영님(iykim71@samsung.co.kr" target=_blank>iykim71@samsung.co.kr)의 글]
본문 중에:
"예를 들면 관계형 디비를 디자인 할 때 반드시 프라이머리키와 포린키를
설정하엿으나
대용량 데이터 처리에선 이것을 둘다 설정하지 않는 경우를 말합니다."
이런 글이 있었습니다.
일일 트랜잭션 5000건 정도면 아주 많은 편은 아닌 것 같고요.
또 어떤 상황이고 어떤 데이터 처리이기에 Constraint 설정을 해제하는지
궁금합니다. 근본적으로 DB로 처리할 일이 아닌, 예를 들어 하루 2억개의
row create가 발생하는 한국통신 ICIS와 같은 프로젝트를 제외하고는
일반적인 RDB 적용에 있어 어떤 성능적인 이유로 Constraint를 해제하여야
한다는 경우는 제게 있어서는 매우 접하기 힘든 사례이기 때문입니다.
(아마도 대부분의 개발자에게 있어 희귀한 사례일 것입니다.)
또 그러한 경우의 DB Modeling은 어떤 식으로 하는지 궁금합니다.
답변 : 안타깝게도 김일영님의 답변을 제가 해드리지 못합니다.
아직 제가 초보자이고 또한 그 이유를 저도 속 시원히 알지 못합니다.
전 옛날에 오라클 RDMS에서 ER-WIN 같은 케이스 툴을 사용하여 관계설정 및 디비
디자인을 하였습니다. 이렇게 제가 배운대로 하지 않고 관계형 데이터 베이스를
그 옛날 ISAM 방식으로 관리한다는 점이 저도 이해하기가 어렵습니다.
저의 PM님 외에도 이렇게 디자인 및 관리를 하시는 소장님들이 몇분 계셔서
저도 어떻게 받아들여야 할지 ....
이런 방식은 정석이 아니고 실무에서 응용하는 한 부분이라고 생각하시고 다만
참고만 하셨으면 합니다.
그런데 더욱 이상한 것은 이런 관리를 하시는 소장님들이 관계형 데이터 베이스에
대하여 깊고 해박한 지식을 갖고 있고 우리들이 알고 있는 디비 디자인 방식에 대해
정통하다는 사실입니다.
[김일영님의 글 ]
중략...
저희 프로젝트는 저희 단독의 DB 구축이 아니고 부산시의 정보화 기본계획에 의거하여
발주되고 개시된 프로젝트입니다. 그러다보니 여러 유관 DB와 연동하여야 하므로
그 DB들의 Schema를 받아다 보기도 합니다. 그중 한 DB의 구조가 다소 특이한 구조입니다.
그 DB는 우선 정규화가 세밀히 되어 있지 않아 어떤 테이블의 한 레코드 구조만 A4로
4장 정도가 되는 분량입니다. 이렇게 되어 있는 연유를 해당 업체에 문의한 바, 원래
그러한 데이터들을 섭렵하는 시스템이 아니었는데 요구사항이 증가하고, 또 저희가
맡은 시스템의 본 사업이 개시되면 새로운 DB가 구축되면서 데이터가 새 DB로 이동될
줄 알았다고 하는 것이었습니다. 그런고로 저희 사업이 개시될때까지만 데이터를 보존하는
역할에 충실하자고 생각한 것이겠지요.
그러나 이와 같은 DB Schema를 가지면 대개 가장 큰 문제는 SGA를 많이 사용하게 되고
그로 인해 DB 성능에 결정적인 영향을 미치는 메모리 캐싱의 효과를 상당히 줄이게 되며
Insert, Update시 무결성 유지를 하기 위해 Trigger를 남용하게 되는 경향이 있습니다.
물론 이와 같은 Schema가 자꾸 필드가 늘어가면서 형성된 것이라고 하면 초기에는
일부 Join을 피하는 효과가 있어 성능이 좋아진 것으로 보일 수도 있으나 결국에는
위와 같은 이유로 성능에 그리 좋지 않은 영향이 발생할 것으로 생각됩니다.
이것이 물리적인 측면에서의, 정규화를 하는 이유 중 하나이겠지요.
대개의 경우 이론상으로는 이러한데... 앞서 저희 프로젝트 유관 시스템의 경우와 같이
어떤 상황, 어떤 목적 하에 구축되느냐에 따라 진정한 최적의 결론의 전혀 다를 수도
있으므로 역시 유솔로몬님의 제언처럼 기존의 체계를 잘 준수함이 좋은 방법일 것입니다...
많은 분께 약간의 참고라도 되었으면 합니다...
[김일영님의 글 ]
중략...
아마도 이런 이야기가 아닌가 합니다... 뭐 거의 차이도 없지만서도...
Varchar의 경우 실제 길이에 맞추어 기억장소의 크기가 변동됩니다.
대신 그 헤더에 기억장소의 크기가 기록되고, 그걸 읽어서 거기에 맞추어 읽어오게
된다는군요. 그래서 그 과정에서 읽기 성능에 모종의 저하 요인이 생긴다 하는데...
Char 대신 주로 Varchar를 쓰는 이유는 여러가지 있고 그것이 주로 어떤 제약 극복이나
(특히 길이) 편리성, 데이터의 길이가 매우 차이날 때 기억용량 낭비 방지 등의 목적
등이 있습니다만... 간혹가다 특히 현업보다는 감리인 중에 따지기 좋아하는 사람이
Varchar를 많이 쓰면 위와 같은 이야기를 하면서 성능상에 큰 영향을 미치는 것처럼
이야기하는 경우를 본 적이 있습니다. 그러나 저희 회사의 DBA들에게 여쭤보면 또
별 차이 없다고 하셔서, 실제 얼마나 영향이 있는지는 잘 모르겠습니다.
[하얀까마귀(kimcherki@hanmail.net" target=_blank>kimcherki@hanmail.net)님의 글]
중략 ....
솔직히 디비관련된 프로젝트 하다보면 초기엔 상당히 좋죠...
하드웨어설계, 데이타베이스 설계, 인덱스 및 각종 쿼리들....
그런데.. 작업 중간중간에 끼어드는 요청들은 이런 설계를 흔들어 놓죠.... ㅜㅜ
너무 슬프다... 그래서 어떤 정석 보다는 약간의 성능저하가 발생하더라도 차후의 이런
부분에 대한 고려와 기타등등의 사유들로 특이한(??) 방식들이 사용되는것 같네요..
음.. 다들 아시는건지도 모르겠는데... 김일영님이 간단하게 언급하셔서 약간 추가
설명을...
제가 알기로는 김일영님의 말씀처럼 varchar는 가변적이기 때문에 약간의 추가 저장공간
을 필요로 하고 그게 약 4byte(이거 다르게 말하시는 분도 계시던데.. 뭐 거기서
거기죠) 정도의 공간이 필요하다고 알고 있습니다.. ( 다들 아시나???)
그런데 문제는 varchar 또는 null로 지정해 놓은 필드가 수정이 발생해서 추가 공간을
필요로 할때 발생을 합니다.
테이블을 생성할때 지정해준 pctFree와 pctUsed에 의해 확보된 여유공간이 있긴 하지만.
( 오라클에서 이 설정으로 테이블 블럭과 디비블럭에 빈공간을 확보합니다.
당연한 이야기 겠지만 null허용과 varchar를 보고 이 값을 결정합니다.. 그리고 테이블
의 용도하고.. )
해당 레코드가 Update될때 이전에 저장된 레코드의 길이보다 커지고 확보해둔 여유공간
이 모자라게 되면 오라클은 이 공간을 할당받기 위하여 다음의 데이타 블록의 공간을
참조하죠.. 그런데.. 그다음 블록에도 충분한 여유가 없으면 그다음.. 그다음...
이렇게 되면... 하나의 레코드를 읽기 위해서 상당히 많은 블럭의 참조를 해야하죠..
이런걸 로우체인이라고 하던가???? ( 음... 확실한 용어는 모르겠네요.. ^^;)
이건 상당한 i/o를 발생시키고 당연히 좀 심각한 성능저하를 가져오기도 합니다..
음.. 말이좀 길어졌는데.. 정리를 하면..
varchar또는 null을 허용하게 되면 레코드의 실제 길이를 예측하기 어렵고 잘못된 예측
은 시스템의 성능저하를 가져올수 있습니다..
그래서 사용하는것이 pctused와 pctfree설정입니다만 설계시의 예측이 오픈했을때도
같다는 보장은 어디에도 없죠..
하지만 그렇다고 이런 여유공간을 최대 레코드 길이만큼 둔다면 이건 차라리 char와
모든 필드를 not null 설정하는게 낫죠..( select할때 null값 고려 안해도 되고..
편하겠네요..)
음..그리고 속도문제.. 실제로 이 두가지 가지고 테스트는 안해 봤습니다만..
이러한 로우체인이 없을때의 char와 varchar의 차이는 거의 없는걸로 알고 있습니다..
단지 4byte짜리 char와 varchar는 varchar가 8byte정도 되니까 이런건 당연히 char이
낫겠죠..
음.. 제 생각은 이러한 varchar의 사용은 시스템에 따라 결정되어야 한다는 겁니다..
그러니까 많은 데이타가 100byte정도이고 예외적으로 이 필드에 200byte정도의 자료가
들어가야 한다면 이 예외적인 필드는 당연히 로우체인을 발생시킬테고 이렇게 저하되는
성능과 전체를 char 200으로 했을때의 늘어나는 용량으로 인한 i/o증가에 따른 성능을
비교할 수 있어야 한다는 거죠.. ( 물론 이건 개발자의 많은 경험과 지식으로...)
당연히 이러한 비교는 예외적인 필드가 얼마나 되느냐 하는것과 pctfree를 얼마로 설정
을 하느냐 입니다..
...중략....
[ 최용일 (zeliard@hanmail.net" target=_blank>zeliard@hanmail.net)님의 글 옮김]
...중략...
Application.CreateForm(TForm, Form);
위 구문은 아래와 같이 하셔도 같습니다.
Form := TForm.Create(Application);
...중략...
[ 김일영 (iykim71@samsung.co.kr" target=_blank>iykim71@samsung.co.kr)님의 글 옮김]
...중략...
[ 필드명의 결정 ]
데이터 베이스를 설계할 때 제일 고민인게 바로 필드명입니다.
관계형 데이터 베이스에서 사용된 키워드 즉 예약어를
피해야 하고 길이도 생각해야 하구...기타등등...
저의 PM님 충고 ..." 만약 테이블 사양서를 보고 코딩을 할거라면
차라리 A1, A2, A3, A4, A5로 하는 것이 ...주석이 있다는 전제하에..."
=> 제가 아는 어떤 IS실의 PM님은 한글을 소리나는대로 영문 표기를
정의해서 아예
IS실 문에다 붙여놓고 그걸로 씁니다. 글자가 너무 길어지지도 않고
영어때문에
머리 굴리지도 않고 나름대로 꽤 실용적이더군요.
예를 들면? 남자 - MAN? 아닙니다. NAMJA입니다. 'ㅈ'은 무조건 J로~
이런 식으로 왕 단순하게 하십니다. 웃겨보이기도 하지만 꽤 유용합니다.
[ 비고 난의 자료형태 ]
...중략
검색키로 NUMERIC형을 사용했다가 욕을 바가지로...ㅠ.ㅠ
아무래도 검색키는 char형이 여러모로 조은 것 같아요
> 물론 설계하면서 상황에 따라 다르겟지만요...
=> 검색키를 어떤 상황에서 NUMERIC으로 하셨기에 그러셨는지 잘 모르겠네요...
일반적으로는 NUMERIC으로 했다고 나쁠 이유를 모르겠는데요...
부연 설명해주시면 감사하겠습니다.
저으기... 유솔로몬님의 연재 분량이 이전 내용에 계속 덧붙여 가는 식으로 진행하시다보니
계속 증가하고 있습니다. 그런데 그러다보니 제가 걱정되는게 하나 생기네요...
한델 게시판은 어떤 구조로 되어 있는지 잘 모르겠지만... 저희 동문회 사이트에서
글이 같은 방식으로 점점 불어나는게 있었는데 텍스트 파일에 넣었더니 나중에는 결국
깨지더군요...
..중략...
********************************************************
끝까지 읽어 주셔서 감사를 드립니다.
사실 필자가 바라는 것은 신문 기사 읽듯이 편안하게 읽기를 바랍니다.
이 글을 쓰면서 느낀게 고급 개발자님들에 대한 생각을 해봅니다.
오늘도 부족한 잠과 싸우며 묵묵히 코딩에 전념하시는 개발자 모든 분들께
경의를 표합니다.
유솔로몬은 이 글을 읽으시는 개발자님이 아무쪼록 유능한 개발자가 되시길 빕니다.
우리나라의 소프트웨어 개발분야가 진흥이 되길 바라는 마음 간절합니다.
이 글을 열람하시는 모든 분께 행운이 함께 하시길 바라며,
항상 행복하십시요.
유솔로몬 드림
'나의 이야기 > 봄노트에 있던 글들' 카테고리의 다른 글
| 항상 즐겁게 사는 31가지 방법 (0) | 2012.12.04 |
|---|---|
| 도공과 아키텍트... (0) | 2012.12.04 |
| 대출받아 아파트 구매한 사람들을 보호해야 하는가? (0) | 2012.12.04 |
| 내가 후회하는 것들의 기록... (0) | 2012.12.04 |
| 가장 멋진 인생 (0) | 2012.12.04 |