JCreator's 『맨땅에 스카이다이빙!』

[Ver 1.51] J-BIS 가 업데이트 되었습니다.

(JCreator) — Wed, 03 Feb 2010 11:40:17 +0900

1년전에 만들었던 J-BIS가 이번에 새롭게 업데이트 하였습니다.

업데이트 된 사항은 다음과 같습니다.

- DB에 저장된 버스 노선 정보를 웹에서 바로 받아와 보여주는 방식으로 변경
- 신규 버스 업데이트
- 종점이 나오지 않는 문제점 해결
- 일부 버스 노선을 잘못 출력하는 문제점 해결 (네이버 스마트폰 카페 아이콜님 의견)
- 버스 노선 앞에 붙는 동 이름 추가, 예) 지원35, 순환01 (네이버 스마트폰 카페 아이콜님 의견)
- 프로그램 상단에 버전 표기 (네이버 스마트폰 카페 와와님 의견)

아주 단순하지만 큰 변화가 아닐 수 없습니다. ^^; 기존 버전은 버스 노선이 추가되거나 버스 정류장이 변경됨에 따라 일일이 DB 수정본을 업데이트해줘야 하는 불편함이 (저에게) 있었습니다.

매번 DB를 업데이트 해서 올리기도 힘들고, 다운 받는 여러분도 불편할 거라고 생각되어 DB를 제거하고 바로 웹에서 받아와 보여주는 방식으로 변경하였습니다.

물론 약간의 패킷 이용료 과금과 초기 정류장 검색이 약간 느리다는 단점이 있지만, 자주 다니는 노선에 대해서는 미리 WiFi 환경이나 컴퓨터에 연결한 상태에서 버스 정류장을 검색하신 후, 즐겨 찾기에 등록하시면 다시 버스 정류장을 검색하지 않고 버스 도착정보를 이용하실 수 있습니다. 요즘은 정액제를 이용하시는 분들도 많고, WiFi 환경이 예전보다 많이 좋아져서 충분히 감당하실 수 있으리라 생각됩니다.

무엇보다도 이번 버전의 가장 큰 장점은 아무래도 업데이트가 필요없다라고 봐야 할 것 같습니다. 웹에 있는 데이터를 그대로 받아오기 때문에 버스 노선이 변경되거나, 새로운 버스가 생겨도 해당 버스 번호를 검색하면 모두 웹에서 최신 정보 그대로를 이용할 수 있습니다. 제가 절대로 업데이트하기 귀찮아서가 아닙니다.;;;

아직 M4650이나 M4655 사용자가 있지도 않을까 하는 마음에 역시 버전을 나누어서 배포합니다.

J-BISi(OZ)_1.51.CAB

M-4650, 55 전용 배포 파일

J-BISi_1.51.CAB

보통 스마트폰용 배포 파일

History

v.1.51 (2010,02.03)
- 종점이 나오지 않는 문제점 해결
- 일부 버스 노선을 잘못 출력하는 문제점 해결
- 버스 노선 앞에 붙는 동 이름 추가, 예) 지원35, 순환01
- 프로그램 상단에 버전 표기

v 1.5 (2010.02.02)
- DB에 저장된 버스 노선 정보를 웹에서 바로 받아와 보여주는 방식으로 변경
- 신규 버스 업데이트

p.s.1 Windows Mobile 6.0 Emulator에서 테스팅하였고, 실제 기기 동작여부는 아직 확인하지 못했습니다.
p.s.2 기타 사용 방법에 대해서는 http://www.jcreator.co.kr/216 를 참고해주세요.

Chapter 1 - 소프트웨어 품질이란 무엇인가?

(JCreator) — Tue, 12 Jan 2010 21:21:49 +0900

1.1 품질에 관한 대중적인 관점

품질에 관한 일반적인 관점은 무형의 특성을 가지고 있다는 것이다.
품질에 대해서 거론되고, 느끼고, 심판할 수는 있지만 그 무게를 잰다거나 측정할 수 없다.
품질이란 것을 보기 전까지는 알 수 없다.
또한 품질을 바라보는 관점이 품질은 고급스럽고, 우수하며, 맛이 좋다라고 보는 것이다.
비싸고 정교하며 보다 복잡한 제품들이 높은 수준의 품질을 가지고 있다고 생각한다.
결과적으로 비싼 제품이 품질이 높다고들 생각하는 것이다.

1.2 품질을 바라보는 전문가의 관점

산업에서는 대중적인 관점에서 어긋난 품질의 개념과 막연함은 품질 개선에 전혀 도움을 주지 않는다.
Grosby (1979)는 품질을 '요구사항의 준수'라 정의하였고, Juran과 Gryna (1970)는 '사용목적의 적합성'이라 정의하였다.

'요구사항의 준수'는 요구사항이 오해 없이 명백하게 정의되어야 함을 내포하고 있다. 그런 다음 개발이나 생산 단계에서 그러한 요구사항들의 준수를 확인하기위해 규칙적으로 측정하는 활동들이 행해진다. 요구사항을 준수하지 않는 것은 곳 결함이며, '품질의 부재'라고 할 수 있다.
예를 들어, 리무진이 리무진의 모든 요구사항을 만족한다면, 이 차는 Quality Car라고 할 수 있다.
만약 티코가 티코의 모든 요구사항을 만족한다면, 이 티코 역시 Quality Car라고 할 수 있다.
그러나 리무진과 티코는 매우 다른 스타일, 성능, 경제성을 가지고 있다. 하지만 이 두 차가 각기 자신만의 표준을 준수하고 있다면 이 두 차 모두 Quality Car라고 할 수 있는 것이다.

'사용목적의 적합성'이란 정의는 어떤 제품이나 서비스가 고객의 사용 목적에 적합한가를 포함하고 있는 고객의 요구사항과 기대를 고려한다. 다른 고객들이 각자 다른 방법으로 제품을 사용하기 때문에 제품은 사용목적의 적합성의 다양한 요소를 지니고 있다. Juran은 이러한 요소들 각자가 품질 특성이며 이러한 특성들은 사용목적의 적합성의 매개변수로 구분되어질 수 있다고 하였다. 가장 중요한 두 매개변수가 바로 '디자인의 품질'과 '적합성의 품질'이다.
디자인의 품질은 제품의 등급이나 모델로 잘 알려져 있다. 이는 곧 구매력의 범위와 관련되어 있다. 등급의 차이는 의도되고 디자인된 차이점의 결과로써 차를 다시한번 예로 들자면, 모든 자동차는 사용자에게 운송이라는 서비스를 제공해주지만 이러한 차의 모델에 따라 크기, 안락함, 성능, 스타일, 경제성, 그리고 상태가 다르다.
반대로 적합성의 품질은 제품이 디자인을 준수하는 정도이다.
다시 말해, 디자인의 품질은 요구사항과 명세의 결정으로 여겨질 수 있고, 적합성의 품질은 요구사항의 준수라고 할 수 있다.

이런면에서 '요구사항의 준수'나 '사용목적의 적합성'은 비슷한 정의를 가지나, 다른 점이 있다면 사용목적의 적합성이란 개념은 소비자의 요구사항과 기대를 위한 보다 더 확실한 역할을 함축하고 있다는 것이다.

1.3 소프트웨어 품질이란?

상품 품질의 관점으로 보자면 '버그'가 없다라고 할 수 있다. 이 말인 즉슨, 만약 소프트웨어가 너무 많은 기능적 결함을 가지고 있다면 기본적인 기능조차 만족하는 요구사항을 만족할 수 없으므로, 품질이란 '요구사항의 준수'라고 할 수 있다.
이러한 정의는 결함율(예를 들어, 소스코드 백만줄 당 결함의 수 또는 단위), 신뢰성(예를 들어, 작업 n시간 당 실패 갯수, 실패한 평균 시간 또는 특정 시간 동안 실패하지 않을 확률)으로 표현할 수 있다.

고객 요구사항은 설문 조사를 통하여 '만족', '불만족'을 %로 표현할 수 있는데 IBM은 이를 CUPRIMDSO (Capability[functionality], usability, performance, reliability, installability, maintainability, documentation/information, service, and overall)의 레벨로써 측정하고, HP는 FURPS(functionality, usability, relability, performance, and serviceability)로 측정한다.

전반적인 고객의 만족도와 다양한 품질 특성(Quality Attributes)를 상승시키기 위해서는 품질 특성이 계획(Planning) 및 디자인 단계에서 고려되어야 한다. 하지만 품질 특성이 서로 다른 품질 특성에 영향을 끼칠 수 있다. 예를 들어, 소프트웨어의 높은 기능적 복잡도는 유지보수성을 달성하기 어렵게 만든다. 소프트웨어의 유형이나 고객에 따라 다른 품질 속성의 가중치가 부여된다. 예를들어 복잡한 네트워크나 실시간 처리를 다루는 고객은 성능이나 신뢰성에 가장 높은 가중치를 줄 수 있지만, 독립 시스템이나 간단한 작업을 다루는 고객의 경우 편의성이나 설치, 그리고 문서화에 가장 높은 가중치를 줄 수 있다. 그러므로 다양한 고객이 사용하는 소프트웨어의 다양한 품질 속성을 위한 목표를 설정하기 위해서 고객의 요구사항을 만족하기란 쉽지 않다.
모든 소프트웨어의 결함의 15% 이상이 요구사항의 오류로부터 비롯된다. 개발 프로세스는 요구사항 품질이 저품질의 소프트웨어를 생산한다고 생각하지 않는다.

또다른 소프트웨어 품질을 바라보는 관점은, 프로세스 품질과 최종 산출물 품질이다. 고객의 요구사항으로부터 소프트웨어 상품의 완성까지 개발 프로세스는 복잡하고 종종 몇 개의 단계를 포함하고 각각 피드백을 할 수 있다. 각 단계에서 중간 산출물이 다음 단계를 위해 생산되며, 다음 단계에서 이러한 중간 산출물을 받는다. 이 때, 중간 산출물은 각각 최종 산출물의 품질에 영향을 줄 수 있는 품질 속성을 갖는다.

흥미롭게도 우리가 외부 고객, 그리고 개발 절차의 다음 단계를 위한 내부 고객까지 포함한 품질의 정의로 고객의 개념을 확장시키면, 프로세스 품질 역시 이 정의에 적용될 수 있다. 만약 개발 프로세스의 각 단계에서 다음 단계의 고객을 위한 요구사항을 만족한다면 최종 산출물 역시 특정 요구사항들을 만족할 것이라고 생각하지만 이는 현실을 너무 단순화한 것이다. 왜냐하면 개발 프로세스의 각 단계에서 매우 다양한 요소들이 존재하며, 이는 각 단계들의 요구사항을 만족하는 능력에 영향을 줄 것이다. 개발 중에 품질을 향상시키기위해서는 개발 프로세스 모델이 필요하며, 우리는 그러한 프로세스 안에서 일정한 방법이나 접근법등을 선택하고 배치할 필요가 있다. 또한 적절한 도구와 기술들을 사용해야 한다. 우리는 개발 프로세스와 그에 속하는 단계의 특성들과 매개변수들의 측정이 필요할 뿐만 아니라, 개발 프로세스가 상품의 품질 목표들을 향해 제어되고 이동하고 있다는 확신을 심어주기 위한 측정지표(metrics)과 모델이 필요하다.

metrics의 확실한 정의가 애매모호하다. 앞으로 공부하면 나오겠지만, 내가 이해하기로는 단순히 실험을 통해 측정된 Raw 데이터는 measure라고 하고, 이런 measure를 통해 새로운 사실을 계산하는 것이 metrics라고 알고있다. 예를 들어, 시간과 거리는 measure지만 이를 통해 구할 수 있는 속도는 metrics라는 것이다. 이 정의가 맞는 것일까?

1.4 전체 품질 관리(TQM: Total Quality Management)

전체 품질 관리란 용어는 원래 1985년 Naval Air Systems Command에서 자신의 품질 향상을 위한 일본식 관리 기법을 표현하기 위해 만들어 졌다. 이 용어는 많은 뜻으로 해석될 수 있으나 일반적으로 품질과 고객의 만족을 관계지음으로써 지속적인 성공을 달성하기위한 관리 스타일이라고 표현한다. 이런 접근법의 기반은 조직의 모든 구성원들이 프로세스와 상품, 그리고 서비스의 향상에 참여하는 문화의 창조라고 할 수 있다.

1980년 이래로, 미국의 많은 회사들이 TQM을 품질에 적용하고 있다. HP의 TQC(Total Quality Control), 모토로라의 Six Sigma Strategy, 그리고 IBM의 Market Driven Quality가 그것들이며, 기타 다른 회사들도 각기 자신들만의 품질에 적용하고 있다. 자세한 사항은 책을 참고하시라.

이러한 다양한 방법론에도 불구하고, TQM 시스템의 핵심 요소는 다음과 같이 요약할 수 있다.

- 고객 중심: 목표는 전체 고객 만족도를 달성하는 것이다. 고객 중심 요소는 고객의 요구를 연구하고 고객의 요구사항을 수집하며, 고객의 만족도를 측정하고 관리하는 것이다.
- 프로세스: 목표는 프로세스의 변수를 줄이고 지속적으로 프로세스 향상을 꾀하는 것이다. 이 요소는 비지니스 프로세스와 상품 개발 프로세스를 포함하고 있으며 비지니스 프로세스 향상을 통해 상품 품질이 향상 될 것이다.
- 품질의 인간적인 측면: 목표는 회사 전체적으로 품질 문화를 창조하는 것이다. 집중 영역으로써 리더쉽, 관리 방침, 전원 동참, 직원 우대, 그리고 다른 사회적, 심리적, 그리고 인간적 요소들이 있다.
- 측정 및 분석: 목표는 목표 지향 측정 시스템에 의한 모든 품질 매개변수들의 지속적인 향상을 이끌어 내는 것이다.

아래 그림이 이러한 핵심 요소를 설명해 주고 있다.

다양한 조직적 프레임워크들이 TQM 철학을 입증하는 품질의 향상을 위해 제시되고 있다. Plan-Do-Check-Act, Quality Improvement Paradigm/Experience Factory Organization, SEI Capability Maturity Model, Lean Enterprise Management 등이 있으며 자세한 사항은 역시 책을 참고하시길.

간단히 설명하자면, Plan-Do-Check-Act는 단일 프로세스 또는 생산 라인을 최적화하기 위한 피드백 사이클에 기반을 두고 있다. Quality Improvement Paradigm/Experience Factory Organization은 지속적으로 조직의 향상을 꾀하는 것이 목표이다. 그들의 점진적 목표와 그 목표들의 상태를 평가하는데 기반을 두고 있다. SEI의 CMM은 레벨 4에 도달할 때까지 핵심 프로세스영역의 평가에 기반을 둔 단계적 프로세스 향상 모델이다. 이 모델의 목적은 결함 예방, 기술 혁신, 그리고 프로세스 변경 관리를 통해 지속적인 프로세스 향상을 달성하는 것이다. Lean Enterprise Management는 부가가치 활동들과 아닌 활동들의 제거나 축소 상의 상품의 집중 이론에 기반을 두고 있다. 목표는 소프트웨어를 만드는데 필요한 활동들을 최소화하고, 생산자의 요구사항에 맞도록 프로세스를 수정하는 것이다.

1.5 결론

품질의 가장 적합한 정의는 '고객의 요구사항의 준수'이다. 사실상 운영상 품질의 정의는 두가지 수준으로 이루어져 있다. 하나는 고유한 상품 품질(q)와 다른 하나는 고객 만족도(Q)이다.

TQM 철학은 품질과 고객의 만족을 관계지음으로써 지속적인 성공에 목표를 두고 있다. 위에서 언급한 4가지 핵심 요소인 (1) 고객 중심, (2) 프로세스 향상, (3) 품질의 인간적인 측면, (4) 측정 및 분석으로 이루어져 있다.

Metrics and Medels in Software Quality Engineering - Preface

(JCreator) — Tue, 05 Jan 2010 18:36:23 +0900

앞으로 공부해보게 될 책에 대한 정리를 스스로를 위해서 오늘부터 시작한다..

[ Metrics and Models in Software Quality Engineering ]

- 머릿말 -

시대별로 바라본 소프트웨어 공학의 관점은..

1960년대 이전 : 기능의 관점
1970년대 : 스케줄의 관점
1980년대 : 비용의 관점
1990년대 이후 : 품질과 효율성의 관점

1990년도부터 품질은 소프트웨어 개발 프로세스의 핵심으로 자리잡았으며 소프트웨어 벤더의 관점에서 품질은 시장에 성공적으로 경쟁하기 위해서 더이상 경쟁력이 아닌 필수 조건이 되가고 있다.
"Quality is no longer an advantage factor in the marketplace; it has become a necessary condition if a company is to compete successfully"

이 책의 구성은...

챕터 1: 소프트웨어 품질이란?
품질과 소프트웨어 품질의 정의에 대해 다루고, 이런 정의를 통해 바라본 소비자의 역할.
품질 속성과 이들의 관계. TQM (Total Quality Management)와 품질의 소비자 관점에 대해서 다룸

챕터 2: 소프트웨어 개발 프로세스 모델
소프트웨어 산업에서 사용되고 있는 다양한 개발 프로세스 모델의 검토.
간략하게나마 소프트웨어 성숙 평가의 두가지 방법에 대해 서술. - SEI (Software Engineering Institute) 프로세스 능력 성숙도 모델인 CMM과 SPR (Software Productivity Research, Inc.)의 SPR 평가 방법

챕터 3: 측정 이론의 기본(Fundamental of Measurement Theory)
실제 소프트웨어 측정에 상당히 중요한 측정이론의 기본적인 사항에 대해 고찰
운용상의 정의 개념과 그 중요성이 예제와 함께 표현 - 측정의 수준, 약간의 기본 측정, 그리고 6 시그마의 개념
측정 품질, 신뢰성, 그리고 검증성, 마지막으로 측정 오류의 발생과 관련된 두 가지 주요 기준에 대해 알아보고 그들의 중요성이 표현.
관측적 데이터를 기반으로한 인과관계 설립에 필요한 기준에 대한 상관관계와 주장들에 대한 논의 또한 제공

챕터 4: 소프트웨어 품질 메트릭스의 개요
최종 산출물, 진행 중, 그리고 유지보수 3가지 소프트웨어 생명주기와 관련된 메트릭스의 분류를 위한 품질 메트릭스의 예제들을 표현
몇몇 대규모 소프트웨어 회사들에 대한 메트릭스 프로그램의 서술 및 소프트웨어 공학 데이터의 수집에 관한 논의

챕터 5: 소프트웨어 개발의 7개의 기본 품질 도구의 적용
소프트웨어 개발상에서 Ishikawa의 7가지 기본 도구로 알려진 품질 제어를 위한 기본 통계 도구 어플리케이션의 소개
소프트웨어 환경상에서 제어 차트를 적용함에 따른 잠재력과 도전과제들.
추가로 브레인 스토밍과 복잡한 인과관계의 표현-관계 다이어그램-을 위한 정량적 도구의 논의

챕터 6: 결함 제거의 유효성(실효성)
상위 5개의 챕터에 모델과 메트릭스에 관한 소프트웨어 개발의 품질 역학을 서술
두 가지 형태의 모델(품질 경영모델과 소프트웨어 신뢰성 및 추정 모델)을 통해, 소프트웨어 개발의 품질이 계획되고, 지냉되며 관리되고, 목표화
품질 계획에 있어서 결함 제거 유효성 및 그 측정, 그리고 역할의 중심 개념을 고찰

챕터 7: Rayleigh 모델
Rayleigh 모델을 설명하고 신뢰성과 예측 모델로서의 구현에 대해 서술.

챕터 8: 지수 분포와 신뢰성 성장 모델
지수분포와 주요 소프트웨어 신뢰성 성장 모델에 대해 논의
개발이 완료되어 소프트웨어가 소비자에게 전달되기 전에 Rayleigh와 같은 모델들은 품질 예측을 위해 사용
이 모델들은 역시 현장에서 실패 패턴 또는 결함 발생 패턴의 모델링을 위한 유지보수 계획에 사용

챕터 9: 품질 경영 모델들
전체 개발 주기를 관장하는 몇몇 품질 경영모델에 대한 서술
In-Process 메트릭스와 모델들이 보여지고 다뤄지는 것을 지원하는 보고서
In-Process 메트릭스와 In-Process 품질 상태-노력/결과 모델-을 해석하기위한 프레임워크 표현

챕터 10: 소프트웨어 테스팅을 위한 In-Process 메트릭스
소프트웨어 테스팅을 위한 메트릭스에 집중
벤더에 의해 개발된 소프트웨어를 평가하는 수락 테스팅을 위한 후보 메트릭스와 어떻게 당신의 상품이 출하할만큼 충분하게 좋은지 알수 있는 중요한 질문에 대해 논의

챕터 11: 복잡도 메트릭스와 모델들
소프트웨어 공학ㅇ에서 메트릭스와 모델의 세번째 타입에 대한 논의
품질 경영 모델과 신뢰성 및 예측 모델들이 프로젝트 경영과 품질 경영을 위한 반면, 복잡도 메트릭스와 모델들의 목적은 소프트웨어 엔지니어들이 그들의 디자인과 소프트웨어의 구현이 향상될 수 있게 함

챕터 12: 메트릭스와 객체 지향 프로젝트에서 얻은 가르침
디자인과 복잡도 메트릭스, 생산성 메트릭스, 품질과 품질 경영 메트릭스, 그리고 객체지향 프로젝트의 구현 및 배포와 구현에서 배운 가르침을 다룸

챕터 13: 가용성 메트릭스
시스템 가용성과 단전(outage) 메트릭스의 논의 및 가용성, 신뢰성, 그리고 기존 결함율 측정 사이의 관계에 대한 탐색
가용성 메트릭스와 소비자 만족 측정들은 4번째 소비자 지향 메트릭스와 모델 형식이다.

챕터 14: 소비자 만족의 측정과 분석
소비자 만족 데이터 수집 및 측정, 그리고 이를 분석하기 위한 테크닉과 모델들을 논의
챕터 3부터 이 챕터까지 메트릭스와 모델의 전체적인 범위를 관장

챕터 15: In-Process 품질 평가 수행
좋은 프로젝트 품질 경영의 통합된 요소로써 in-process 품질 평가 수행을 설명
품질 평가들은 이전 챕터와 정량적인 정보들과 같이 정량적인 지표를 기반

챕터 16: 소프트웨어 프로젝트 평가 수행
소프트웨어 프로젝트 평가 방법에 대한 제안
프로젝트 수준과 실무자의 관점으로부터의 논의에 집중

챕터 17: 소프트웨어 프로세스 향상의 규칙들
소프트웨어 프로세스 향상 전문가를 위한 실제적인 조언
챕터 2의 프로세스 성숙도와 관련

챕터 18: 기능 점수 매트릭스를 소프트웨어 프로세스 향상 측정에 이용
소프트웨어 프로세스 향상의 6단계에 대한 논의
경험에 의한 데이터의 상당 부분을 기반으로 프로세스 향상의 비용과 효과를 측정
비용, 스케줄, 생산성, 그리고 품질에 관한 정량적인 분석 결과를 제공
기능 점수 매트릭스의 가치를 분명하게 표현
마찬가지로 챕터 2의 프로세스 성숙도와 관련

챕터 19: 결론
일반적인 소프트웨어 측정과 특정 소프트웨어 품질 메트릭스와 모델들의 관찰 결과를 제공
소프트웨어 공학 측정의 미래에 대한 관점 제공

부록: 프로젝트 평가 설문지의 실제 예제 제공
챕터 16에서 논의된 메소드와 테크닉에 대하여 독자들이 그들의 프로젝트 평가 활동을 위한 설문지 커스터마이징 가능

아키텍처 패턴

(JCreator) — Tue, 04 Aug 2009 16:08:55 +0900

"요소와 그들과의 관계를 특정 목적에 맞도록 사용하게 하는 제약 사항"

이라고 책에서 정의하고 있다.

아키텍처의 요소들이 워낙 방대하고, 그 관계 또한 복잡하다보니 마치 프로그래밍에 있어서 디자인 패턴처럼 중요하고 자주 사용되는 패턴들에 대해서 일반화 시켜놓은 아키텍처 요소들과 관계의 패턴이라고 말할 수 있다.

솔직히 이 패턴은 그 패턴(?)이 아님을 알고 있다 ㅡㅡ땀

말이 일반화지 아키텍처 자체가 모든 이해관계자(stakeholder)들 간에 공유할 수 있는 일종의 언어가 될 수 있어야 하기 때문에 서로가 공감할 수 있도록 제약을 걸어 놓은 패턴이라고 해야 옳은 표현 일 수도 있겠다.

책에서와 같이 클라이언트/서버 구조라는 아키텍처 패턴이 있을 수 있다. 물론 무수히 많은 구조가 아키텍처에 존재할 수 있지만, 이 모든 것을 한꺼번에 다루기에는 힘들고 클라이언트/서버라는 구조가 일반적이고 범용적으로 사용되기 때문에 이를 하나의 패턴으로 정해놓은 것이다. 하지만 이게 '정의고 진리'인 패턴은 절대 아니다.

그렇다고 무작정 나만의 패턴을 만들어 사용하는 것 보다는 이렇게 수 십년 동안 사용되어 오고 정의되어 뿌리 내린 패턴에 대해서는 그만큼 엄격한 검증과 사례들이 이 패턴의 정당성을 뒷받침해주기 때문에 우리는 아무런 의심의 여지가 없이 사용할 수 있다.

특히 패턴은 품질 속성(Quality Attribute)를 명확히 대변해준다는 점에서 큰 의미를 지니고 있다. 어떤 패턴을 적용해도 상관없는 경우라도 패턴별로 대변하는 품질 속성이 다르기 때문에 패턴을 선택함에 있어서 신중을 기해야 할 것이다. 마치 디자인 패턴 중, 생성 패턴에 '싱글턴, 추상 팩토리, 팩토리 메소드, 빌더, 프로토타입'등의 다양한 패턴이 존재하지만, 각 패턴이 갖는 특징이 다른만큼 내 시스템에 맞는 적절한 패턴을 선택하는 것이 중요하다.

옵간지 옵티머스 프라임 Transformers: Defiance의 표지(?)

(JCreator) — Mon, 29 Jun 2009 16:31:32 +0900

정말 간지 작살입니다.
다만 옵간지 형님이 고자라는 소문이...

노무현 대통령님의 서거를 추모합니다

(JCreator) — Sun, 24 May 2009 21:15:17 +0900

제 마음속의 이성과 감성이 요동치고 있습니다.
분명 이 정권을 타파하기위해서는 이성이 필요하지만, 그렇게 이성만을 갈구하다 결국 이런일 생겨버렸습니다.
반드시 제가 할 수 있는 일을 찾겠습니다.
제 가슴에 이성을 가지고, 감성의 머리로 이 나라, 이 정권에 항거하겠습니다.

[버젼업] 모바일 어학 반복 학습 플레이어 J-Repeater 1.03

(JCreator) — Tue, 27 Jan 2009 11:06:15 +0900

JCreative 시리즈 - 최근 업데이트 09.01.27

[J-Repeater 1.03]

J-Repeater Mobile.CAB

J-Repeater 1.3

토익 LC를 위해서 개인적으로 만들어서 사용하다가 제법 틀이 갖춰져서 한번 배포해 봅니다.

제가 M4650 스마트 폰을 사용하는 관계로 Pocket PC 용으로 반복 학습 플레이어를 만들어보면 어떨까 싶어서 만들었습니다. 물론 Windows Mobile 5 PPC 이상 사용가능하며 터치가 지원되지 않는 다른 기종에서의 사용은 조금 불편하실 수도 있습니다. 반응이 좋으면 버젼
업을 통해서 Smart Phone도 사용할 수 있게끔 버젼업을 할 계획입니다.

사용법은 아주 간단합니다. 인터페이스가 알송의 어학 기능의 그것과 매우 흡사합니다. 한번쯤 사용해 보신분은 쉽게 적응하실 수 있습니다.

그럼 차근차근 설명을 드리죠.

1. 듣기용 파일 열기

우선 [메뉴]를 클릭하여 [열기]를 선택합니다.

J-Repeater는 기본적으로 mp3와 Wave 파일만을 지원합니다. 보통 듣기용 문제들이 mp3로 제공되기 때문에 아직까지는 별다른 문제가 없을 듯 합니다.

2. 파일 선택

원하는 파일을 선택합니다. 기존 버젼은 CF에서 자체적으로 지원되는 파일 열기 폼을 사용했으나 루트로부터 하위 한 단계 폴더만 검색할 수 있는 단점이 있어서 J-Reworder에서 만들었던 자체적인 파일 열기 폼으로 대처 했습니다.

기본적으로 지원되는 형식은 다음과 같습니다.

mp3 : mp3 파일
wave : wave 파일
pl : Playlist 파일

각 폴더간의 이동은 [더블 클릭]이나 [확인 버튼(Enter)], [오른쪽 소프트키 버튼]을 이용하며, 마찬가지로 파일에서 [더블 클릭]이나 [확인 버튼], [오른쪽 소프트키 버튼]을 이요하면 해당 파일이 열리게 됩니다.

3. 재생, 정지 등 기본 조작

기본 적인 조작법은 너무나 쉽기 때문에 간단히 설명만 하겠습니다.

[<] : 앞으로 5초 이동합니다. ->(변경) 다음 플레이 리스트 항목으로 이동합니다.
[>] : 뒤로 5초 이동합니다. ->(변경) 이전 플레이 리스트 항목으로 이동합니다.
[▶] : 재생
[■] : 정지
[||] : 일시 정지

원하는 구간으로 이동하기 위해서는 위의 막대를 마우스로 드래그하면 됩니다.

다음으로 상,하,좌,우 방향키의 용도에 대해 설명 드리겠습니다.

[좌←] : 앞으로 1초 이동합니다. ->(변경) 설정에서 변경 가능합니다.
[우→] : 뒤로 1초 이동합니다. ->(변경) 설정에서 변경 가능합니다.
[상↑] : 볼륨을 올립니다. ->(변경) 설정에서 변경 가능합니다.
[하↓] : 볼륨을 내립니다. ->(변경) 설정에서 변경 가능합니다.

4. 구간 반복

예를 들어 16초부터 20초를 구간 반복 하고 싶다면, mp3가 재생중일 때,

1. 16초가 되면 [반복 시작]을 클릭하고,
2. 20초가 되면 [반복 끝]을 클릭합니다.
3. 왼쪽에 시간이 16초, 20초로 각각 표시되고,
4. 반복 모드가 [켜짐]으로 변경되면,

비로소 구간 반복이 시작됩니다.

다음 동영상을 보시면 쉽게 이해가 되실 겁니다.

이때 반복 되는 구간에 변경을 가하고 싶다면, 각 시간 옆에 있는 [▲]나 [▼] 버튼으로 조절해주면 반복 되는 구간을 변경 할 수 있습니다.

또한, 맨 아랫부분에 있는 반복 횟수를 지정해 주면, 반복 횟수만큼 반복하고 반복 모드가 꺼집니다. 기본값으로 0이 지정되어 있으며, 0으로 지정할 경우는 무한 반복이 됩니다.

왼쪽 소프트 키를 이용해 구간 반복을 할 수도 있습니다.
소프트 키는 누를 때마다 세 가지 기능(1.반복시작 →2.반복 끝→3.반복 정지)이 돌아가면서 실행됩니다.
그러므로 화면으로 버튼을 터치할 필요없이 소프트 키만으로 구간 반복이 가능합니다.

[반복 시작] 상태에서 클릭을 하거나 왼쪽 소프트 키를 누르면,
반복 시작 시간에 현재 시간이 등록되고,

[반복 끝] 상태에서 클릭을 하거나 왼쪽 소프트 키를 누르면,
반복 끝 시간에 현재 시간이 등록되어 구간 반복 모드가 시작됩니다.

구간 반복 상태에서 [반복 정지] 를 클릭하거나 왼쪽 소프트 키를 누르면,
반복 횟수와 상관없이 구간 반복 모드가 종료됩니다.

이 소프트키 하나로 쉽게 구간반복을 할 수 있겠죠? ^^

5. 재생 목록

플레이리스트 입니다. 기본적으로 이전에 재생된 목록들이 자동으로 나옵니다.
재생 목록에 있는 항목을 더블클릭하게 되면 해당 항목이 바로 재생됩니다.

각 버튼의 의미는 다음과 같습니다.

[+F] : 음악 파일을 재생 목록에 추가합니다.
[+D] : 음악 파일이 포함된 폴더를 한꺼번에 재생 목록에 추가합니다.
[-F] : 재생 목록에 체크된 음악파일을 제거합니다.

[리스트 저장] : 해당 리스트를 저장할 수 있습니다.

[재생 옵션] : 재생에 관련된 옵션들이 있습니다.
- 전체 : 재생 목록 전체를 반복해서 듣습니다.
- 한곡 : 한곡만 반복해서 듣습니다.
- 무작위 재생 : 여러 항목을 무작위로 듣습니다.

또한 재생 목록의 헤더 컬럼을 선택하면 전체 선택 및 전체 선택 해제가 가능합니다.

6. 설정

설정을 통해서 방향키의 역할을 바꿔 줄 수 있습니다.
아직, 재생 시간 이동과 볼륨 조절의 역할 밖에 없지만 기능이 점차 추가됨에 따라 유용하게 사용될 수 있으리라 생각됩니다.

[변화값]은 해당 방향키를 눌렀을 경우 변화되는 수치입니다. 예를 들어 좌, 우 방향키로 재생 시간을 조절 할 수 있는데 기존에는 1초 간격으로 고정 이동 되었으나 이제는 자신이 원하는 값으로 이동할 수 있습니다.

수치나 역할을 변경 한 후에는 반드시 [적용] 버튼을 누르셔야 적용이 됩니다.
그렇지 않으면, 기존 설정값이 그대로 유지 됩니다.

7. 조명 끄기

간단히 메뉴를 통해 [조명 끄기]를 선택하면, PDA의 백라이트가 꺼집니다.
다시 복귀하시려면 전원 버튼을 누르셔야지만 복귀됩니다.

8. 조명 항상 켜기

J-Repeater를 오랜 조작없이 오로지 듣기용으로만 사용하실 경우에는 해당 스마트폰에 설정된 전원 옵션에 따라서 일정 시간이 되면 화면이 저절로 꺼지게 됩니다.

이를 방지하기 위해서 [조명 항상 켜기]를 체크하면, 전원 옵션에서 설정된 시간에 상관없이 항상 백라이트가 켜져있게 됩니다.
물론 백라이트가 항상 켜져있으면, 밧데리 소모가 심하므로 반드시 필요할 경우에만 사용해야겠죠?

이상 J-Repeater의 설명이었습니다.

다시 한번 말씀 드리지만 개인적인 필요로 인해 만든 프로그램이라 다소 엉성하고, 불편하실 수도 있습니다. 하지만 여러분들이 소중한 의견을 보내주시면, 제대로 한번 키워 보려고 합니다.
잘 쓰세요~! ^ㅁ^

- History -

[08.06.30] - v1.01

설정(Option) 페이지 추가 : 방향키 설정 및 재싱 시간 변화값 조절 가능
조명 끄기 기능 추가 : 메뉴를 통해 조명을 끄고 청취 가능
약간의 GUI 변경 : 각 종 정보 위치 조정 및 버튼 크기 조정

[08.07.30] - v1.02

반복 횟수가 10으로 고정되 있었던 버그 수정
파일 열기 시, 루트 바로 아래 한단계의 폴더에서만 파일을 읽는 문제점 수정
플레이리스트 및 리스트 파일 관리 기능 추가
한곡, 전체, 무작위 재생 기능 추가
기타 자잘한 버그 수정

[08.07.31] - v1.02.4

Wave 파일 재생 및 추가 시 오류 수정
재생목록 파일 추가 시 오류 수정
재생목록 저장 할 때마다 뜨던 디버그 메시지 박스 제거
잘못된 폴더명을 읽는 버그 수정
대문자로 된 확장자(MP3, WAV)를 읽지 못하는 버그 수정(오호님 의견)
mp3 tag 정보가 없을 경우 발생하는 오류 수정

[09.01.27] - v1.03

소프트 키를 사용한 구간 반복 모드 시, 반복 정지 기능 추가로 3단계 토글 방식으로 변경(라끄벨님 의견)
조명 항상 켜기 기능 추가(라끄벨님 의견)
방향키 조작 시 반복 횟수 변경 버그 수정(라끄벨님 의견)
부분적으로 부적합한 명칭 수정

p.s. 받아가시면 격려의 댓글 부탁드릴게용~

[PPC] 광주 광역시 버스 운행 정보 서비스 J-BIS

(JCreator) — Wed, 24 Dec 2008 11:36:49 +0900

광주광역시 버스 도착정보를 조회할 수 있는 J-BIS가 출시되었습니다.

광주광역시에서 일반 핸드폰으로는 이미 제공되는 서비스지만 이용하기도 복잡하고,
사용하기 위해서는 추가적인 데이터 요금이나 전화요금이 나가는 관계로
알면서도 사용하기 쉽지 않습니다.

하지만 J-BIS는 정액으로 데이터 요금제를 이용하는 사용자나 WiFi를 이용하시는 분들에게는
정보 이용료가 거의 '무료'라고 볼 수 있습니다.

J-BIS는 다음과 같은 특징이 있습니다.

- PPC 기반 스마트폰 전용(블랙잭 미지원)
- 저용량(약 200k 초반)
- 언제 어디서나 이용 가능
- 손쉬운 이용법
- 최소한의 데이터 송수신
- 버스 번호를 통한 노선 검색
- 해당 정류장의 실시간 버스 도착 정보 제공
- 해장 정류장의 특정 버스 도착 정보 즐겨찾기 등록 및 관리
- 즐겨찾기를 통한 신속한 버스 도착 정보 조회

간단한 사용법을 알려드리죠.

1. 프로그램을 실행하면 다음과 같은 메인화면이 뜹니다.

2. 검색란의 화살표를 클릭하면 미리 등록된 버스 번호 리스트가 있기 때문에,
일일이 쳐서 검색하지 않아도 됩니다.

3. 예를 들어 17번을 선택하고 검색해보겠습니다.
버스 노선에 대한 DB는 웹에 접속하지 않고 J-BIS가 Text DB를 포함하고 있기 때문에 추가적인 데이터 요금없이 빠르게 검색할 수 있습니다.

물론 변경되는 노선에 대해서는 다시 DB를 업데이터해야 하는 수고로움이 발생할 수 있으나, 추가적인 데이터 요금을 피하고, 빠른 검색을 위해 이와 같은 정책으로 구성하였습니다.

4. 왼쪽의 상행과 하행을 통해 자신이 타고자 하는 정류장을 선택할 수 있습니다.

5. 하행에 있는 '백운 광장'을 더블 클릭하거나 확인키를 눌러 보겠습니다.

6. WiFi나 직접 인터넷에 연결 되어 있다면 얼마 지나지 않아, 다음과 같은 화면을 보실 수 있습니다.
그렇지 않다면 각 통신사에 따른 데이터 이용 접속과정을 통하므로 약간의 시간이 걸릴 수 있습니다.

7. 왼쪽 소프트 키를 이용해 새로 고침을 이용해 정보를 새로 갱신할 수도 있습니다.

갱신 후 화면

8. 바로 즐겨 찾기 버튼을 누르면 검색했던 17번이 해당 정류장의 즐겨찾기로 등록이 됩니다.
이 후에 메인화면의 즐겨찾기 메뉴를 통해 버스 검색없이 바로 정보를 받을 수 있습니다.

9. 혹시 해당 정류장의 다른 버스도 즐겨 찾기로 등록하고 싶다면, 해당 버스를 클릭한 후 똑같이 즐겨 찾기 버튼을 클릭해 줍니다.

10. 닫기를 통해 창을 닫고 메인의 즐겨찾기 메뉴에 잘 등록이 되었는지 확인해 봅니다.

위에서 등록 했던 데로 잘 등록 되어 있음을 볼 수 있습니다.

11. 그럼 즐겨 찾기를 통해 바로 버스 도착정보를 확인해 보죠.

백운광장에서 75번 조회 결과

백운광장에서 17번 조회 결과

12. 등록된 즐겨 찾기는 삭제 할 수도 있습니다. 75번을 지워보도록 하죠.

13. 최근 검색했던 버스는 프로그램을 종료하고 다시 실행 해도
계속 남아있기 때문에 다시 검색 하기 쉽습니다.

배포 버젼은 2가지로 나뉩니다.

- OZ폰(M4650, M4655, 기타 앞으로 LGT에서 나올 OZ 스마트폰들)
- 기타 다른 스마트폰

OZ폰의 경우 데이터 이용요금 경고창 때문에 따로 처리한 부분이 있어서 따로 제작했습니다.
하나로 합쳐서 해보려고 했으나 다른 기타 폰들에서 오류가 발생하여 할 수 없이 따로 제작하였습니다.

J-BIS(OZ).CAB

OZ폰 전용 배포 파일

J-BIS.CAB

기타 다른 스마트폰용 배포 파일

J-BIS 시연 화면

(JCreator) — Mon, 08 Dec 2008 22:35:37 +0900

M4650, M4655 데이타 이용 요금 메시지 없애기(2)

(JCreator) — Sat, 06 Dec 2008 23:52:48 +0900

http://www.jcreator.co.kr/212 글에 이어, 이번에는 어플리케이션을 개발함에 있어서
자동으로 이 데이타 이용 요금 메시지를 없앨 수 있는 방법을 알려드리고자 합니다.

보통 이런 설정들은 레지스트리에 저장되어 있는데, SOTI Pocket Controller 란 프로그램을 통해서
값을 변경해가며 변화되는 레지스트리 값이 있는지 몽땅 뒤졌습니다.
어떻게 보면 좀 구식적인 방법이죠.
하지만 대충 레지스트리의 키를 보면 어느정도 유추가 가능하기 때문에 쉽게 찾을 수 있었습니다.

특이하게 1이 해제 상태입니다.
아마도 0이 기본값이다보니 그렇게 되어있나봅니다.

Compact Framework(C#) 개발자는 다음과 같이 쉽게 값을 바꿀 수 있습니다.(M4650 기준)

- 메시지 해제 시
Registry.SetValue("HKEY_CURRENT_USER\\Software\\Samsung\\Phone", "UserCfrmWarningUI", 1, RegistryValueKind.DWord);

- 메시지 설정 시
Registry.SetValue("HKEY_CURRENT_USER\\Software\\Samsung\\Phone", "UserCfrmWarningUI", 0, RegistryValueKind.DWord);