마비노기 팔아야할 아이템
승코 위스보위군
얼마에 팔지..
폭코 위스보위군 모자
희생 바람 에나멜 슈즈
연구실의 내 책상.
으음..
가장 왼쪽엔 책볼때 쓰는 독서대..와
그리구 그옆에는 중국에서 사온. 우롱차, 쟈스민차, 보이차 3종 셋과 내 핸드폰(완소 초코렛2)
가장 오른쪽에는 빨간색 커피전용 머그컵과. 차 전용 컵(걸러내는거 있는거)
그옆에 작년 생일(12. 31일 -_- 음력이라) 선물로 받은 달력. 달력 밑에는
무려 3년전에 용산에서 받은 마비노기 마우스 패드.
음 그리고.. 노트북 스타일의 그.. 이름은 모르겠고 아무튼 노트북 스타일 키보드 -_-;
듀얼 모니터와.. 모니터 위에 앉아있는 '마소 라이프캠'(화상채팅 환영 0ㅁ0)
그리고.. 사진 왼쪽 상단에.. 코르크 보드와 코르크 보드에 꽃혀있는 영화 티켓들. -ㅁ-ㅋ
그위에 나무판으로 된건 나무판으로된 캐나다 엽서(캐나다 다녀온 이가 선물한것.)
그리고. 오른쪽 가운데쯤에 거울 뒤에.. 살짝 보이는 인스탁트 미니와 미니용 필름들 ㅋ
후훗.. 너저분 하군요 @_@
다음주 부터 해야 할일. 이미지 색인 프로그램 만들기.
1. 간단한 계획 수립
2. 일단 GUI 구성하기(확장 가능하게)
3. 간단한 이미지로부터 이미지 자료 추출(RGB값등..)
4. 히스토그램등 이미지 데이터 출력
5. 샘플 이미지들로부터 이미지 데이터 뽑아서 데이터 베이스화하는 기능 추가
6. 제공 이미지로 비슷한 이미지 찾는 기능 추가(검색은 어떻게 해야하나...)
7. 프로그램 테스트.
디자인 패턴의 정의
패턴이란 특정 컨텍스트 내에서 주어진 문제에 대한 해결책이다.
컨텍스트(context)란 패턴이 적용되는 상황을 뜻한다. 반복적으로 일어날 수 있는 상황이어야만 한다.
ex) 객체들의 컬렉션이 주어져 있다.
문제(problem)란 그 컨텍스트 내에서 이루고자 하는 목적을 뜻한다. 하지만 컨텍스트 내에서 생길 수 있는 제약조건도 문제에 포함된다
ex) 컬렉션의 구현을 드러내지 않으면서 그 안에 있는 각 객체들에 대해서 순환 작업을 할 수 있어야 한다
해결책(solution)이 바로 우리가 찾아내야 하는 것이다. 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인을 뜻한다.
ex) 반복 잡업을 별도의 클래스로 캡슐화시킨다.
어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을 수 있는 문제에 봉착 했다면, 그 제약 조건 내에서 목적을 달성하기 위한 해결책을 찾아낼 수 있는 디자인을 적용하면 된다.
패턴이 아닌 디자인에 정신을 집중해야 한다. 반드시 필요한 경우에만 패턴을 사용해야 하고 더 간단한 해결책이 있다면 그 방법을 쓰는 것이 옳은 것이다.
네이버 블로거 휴이님 글 펌
OSGi(Open Service Gateway initiative) Alliance는 1999년에 선 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 후 몇 년 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 이 표준 사양의 핵심은 어플리케이션의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.
OSGi 프레임워크는 독립적인 Java/VM 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 어플리케이션 또는 컴포넌트(번들, Bundle)은 재부팅 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled)될 수 있다
OSGi는 Embeddable(어플리케이션 내부로 포함될수 있는) SOA를 구현하고 있다. 이를 통해 어플리케이션 개발에 있어 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)
1. Technology Problem
현재 홈 네트워크를 구성하는데 있어 해결해야 할 많은 난제들이 있으나 기술적으로 가장 우선시 되어야 할 사항은 바로 홈 네트워크를 구성하는 기술의 표준화 이다. 실제 홈 네트워크를 구성하는데 있어 다음과 같은 문제가 있다.
- 서로 다른 적용 분야 (데이터, 엔터테이먼트, 제어 네트워크 등)에
- 서로 다른 통신 방식 (고속, 저속, 유선, 무선, 전력선, CAT5, 2-Wire 등)
- 서로 다른 네트워크 (Ethernet, HomePNA, Bluetooth, HomeRF, IEEE1394, LonWorks 등)과
- 다양한 방법(ADSL, Cable, Phone, PSTN, 위성 등)으로 접속할 수 있어야 하고
- 그럼에도 일관된 홈 네트워크 서비스 (정보검색, 검침, 의료, 보안, 에너지 관리 등) 를 제공할 수 있어야 할 뿐만 아니라.
- 현존하지 않는 새로운 네트워크 기술과 새로운 홈 네트워크 서비스가 등장하더라도 모두 수용할 수 있어야 한다.
이를 가능하게 하는 홈 네트워크 시스템의 핵심은 주거용 게이트웨이(=홈 게이트웨이)이다. 하지만 현재의 주거용 게이트웨이들은 몇 가지의 고정된 기술과 네트워크 기술을 지원하거나 특정 회사의 독점적 기술들을 사용하고 있다. 또한 홈 네트워크 서비스도 고정되어 있거나 자사의 제품에서만 동작한다. 따라서 각기 다른 제조사들의 홈 네트워크 시스템과 제품들은 호환되지 않으며 미래에 등장할 새로운 기술과 서비스를 수용할 방법이 없다.
2. OSGi 설명
OSGi 표준은 번들(Bundle)이라고 불리는 모듈화 된 소프트웨어를 동작하도록 하는 소프트웨어적 프레임워크(Framework)와 번들이 프레임워크와 통신하도록 하는 인터페이스(Interface)를 정의하고 있다. OSGi 프레임워크는 게이트웨이 상의 이기종 기술 또는 타 벤더의 서비스 간에도 통신이 가능하게 하는 표준 기술을 제공한다. 이는 새로운 기술이나 서비스를 제공하는 장치가 추가 되더라도 장치 설비자의 요구 또는 거주자에 의한 간섭 없이도 인터넷을 통해 새로운 소프트웨어 모듈을 손쉽게 설치 및 업그레이드, 교환 시키는 것을 가능하게 한다. 따라서 소비자는 얼마든지 다른 제조사의 이기종 기술을 사용하는 기기를 구입해도 문제 없이 사용할 수 있다. 단지 이것을 가능하게 하기 위해 그 장치에 해당하는 번들을 원격지에서 전송 받기만 하면 되며, 새 장치를 설치하더라도 이전의 이기종 기술을 사용하는 장치들과도 통신 할 수 있다. 이와 같은 특징 때문에 OSGi는 외부망과 내부망, 각 기술과 서비스들간의 “교량”이자 “관문”의 역할을 수행하게 된다.
OSGi를 구성하는 중요 엔터티는 다음과 같다.
하악...
=ㅁ=;;;
RCP 세미나 끝나면 읽고있는 HEAD FIRST Design patterns.. 책 내용 정리해야겠다.
스트래티지 패턴(strategy patten)
알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다.
스트래티지을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
디자인 원칙
1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로 부터 분리 시킨다.
- 달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 '캡슐화' 한다. 그러면 코드를 변경하는 과정에서 의도하지 않는 일이 일어나는 것을 줄이면서 시스템의 유연성을 향상시킬 수 있다.
2. 구현이 아닌 인터페이스에맞춰서 프로그래밍 한다.
3. 상속보다는 구성을 활용한다.
ActiveX and VBScript support in Opera
아래 사이트 가서 Neptune 플러그인을 다운 받은 후 설치 한 다음에 순서대로 파일을 카피 하면된다.
원문 보기
직렬화
2. 맞춤 직혈화 형태를 사용하라
3. readObject 메소드는 모든 공격을 방어할 수 있도록 작성하라..
4. 필요하다면 readResolve 메소드를 제공하라
스레드
1. 변경가능한 공유 데이터에 접근할 때 동기화하라
2. 지나친 동기화는 피하라
3. wait 메소드는 반복문 안에서만 호출하라
4. 스레드 스케줄러에 의존하지 마라
5. 스레드 안정성을 문서화 하라
6. 스레드 그룹을 쓰지 마라
예외처리
2. 처리해야 하는 예외와 런타임 예외를 구분해서 던져라
3. 처리해야 하는 예외는 꼭 필요할 때만 던져라
4. 표준 예외를 써라
5. 예외를 적절하게 추상화하라
6. 메소드가 던지는 모든 예외를 명세문서에 기술하라
7. 실패에 대한 자세한 정보를 상세 메시지 문자열에 담아라
8. 실패의 원자성을 얻기 위해 노력하라
9. 예외를 잡아서 버리지 마라
