2012년 5월 23일 수요일

Spring framework의 싱글턴 인스턴스에 대한 동시다중액세스 상황과 관련하여 생각해 봄직한 의문..

참고 : http://stackoverflow.com/questions/4617437/when-multiple-access-spring-singleton-instance-at-same-time

Springframework의 bean 객체는 기본적으로 싱글턴 인스턴스를 갖습니다(물론 변경도 가능합니다!). 이 싱글턴 객체에 대해 액세스가 동시에 무한히 증가하는 상황이라면 어떻게 될까? 라는 의문을 갖게 된적이 있었는데 이런 상황에 대해 정리를 한번 해보고자 합니다.

생각해 보고자 한 상황을 정리해 보면 다음과 같습니다.
  • Spring framework에서 서비스 객체를 싱글턴 스콥으로 설정하고 컨트롤러에서 DI(Dependency Injection)를 통해 객체를 생성하였을 때 해당 싱글턴 객체에 동시에 다수의 사용자가 접근을 시도하면 충톨이 발생하거나 하는 염려는 없나? 그게 아니라면 IoC(Inversion of Control) 컨테이너가 좀더 나중에 호출 된 작업을 앞서 호출된 작업이 완료될 때 까지 기다렸다가 호출하는 것 인가? 만약 이게 맞다면 퍼포먼스에 심각한 영향을 주는것은 아닌가?
이에 대한 답변은 다음과 같습니다.
  • 싱글턴 객체는 동시에 수차례 액세스 될 수 있습니다. 그리고 이러한 상황에서 충돌을 피하기 위해 thread-safe 하게 만들어져야 합니다. 만약 해당 빈이 thread-safe 하지 않다고 판단되면 싱글턴 스콥이 아닌 다른 영역을 사용하는 것을 고려해야 할 것 입니다.
결론은 thread-safe하게 코드를 작성하는게 프로그램의 동시성(Concurrency)을 보장해준다는 것을 알게 되었는데 만약 이런 것이 여의치 않은 상황에서의 조치나 thread-safe한 프로그램의 요건들이 또 다른 연구 과제로 남게된 것 같습니다 :)

2012년 5월 17일 목요일

Java 7이 개발자를 위해 준비한것은?



자바가 오라클로 넘어간 후 첫 메이저 업데이트 버전인 자바 7에서 바뀐 점은 무엇일까? 그리고 앞으로 변하게 될 방향은 무엇인가?에 대해 생각해보는 글 입니다. Java SE 7 발표 후 심각한 버그 덩어리(?)를 안겨주었지만 개선되고 변화된 점들도 많고 앞으로 Java가 추구하게 될 방향에 대한 시발점이 될 것으로 보입니다. 물론 이 내용들이 국내에서 실무상에 일반적으로 논의 되는건 몇년 뒤의 이야기가 될 수도 있겠지만 우리나라에서만 평생 일하게 될지 어떨지 알수도 없고 개인적으로도 그건 바라지 않기에 :) 한번 짚고 넘어가 보도록 합시다!

자바 커뮤니티 내부의 정치적 문제와 연기된 다수의 신기능들

자바의 아버지 제임스 고슬링의 2010년 오라클 퇴사 그리고 아파치 재단과의 불화 및 각종 커뮤니티 내부의 갈등 등으로 별다른 진전없는 5년을 보낸후 마침내 Java SE 7이 발표 되었습니다. 어찌 되었건 오라클은 이런 문제들을 이제는 어느정도 정리하고 극복해 낸 것으로 보입니다.

5년의 노력에도 불구하고 Java SE 7은 처음 계획되었던 것과는 많이 다른 모습으로 발표되었습니다. 최초 JDK 7에서 계획 되었던 수많은 계획들은 2012년 발표 예정(?)인 JDK 8으로 연기되었으며 Java SE 7은 어쨌든 2파트로 나눈 릴리즈의 첫번째 제품이 되었습니다. 상황이 이렇다 보니 Java SE 7은 잠시 거쳐가는 버전으로 보이는건 어쩔 수 없는듯 합니다.

연기된 기능들 중에는 멀티코어 프로그래밍을 위한 자바의 람다표현식이나 클로저기능, 모듈러 프로그래밍을 위한 언어와 VM 지원 그리고 JDK의 모듈 시스템들이 있습니다. 많은 기능들이 빠진것에도 불구하고 Java SE 7은 유용한 새 기능들을 제공하고 있습니다.

다음에 언급할 내용은 Java SE 7에서 제공하는 새로운 주요 기능들 입니다.

동적 언어들의 지원

Java SE 7의 주요 기능으로는 JRuby와 Groovy 같은 언어의 출현으로 인해 최근 JVM에서 눈에 띄게 된 동적 언어에 대한 편의성 제공을 들 수 있습니다. 예를 들어 새로운 InvokeDynamic 기능은 동적인 형태로 정의된 객체 지향 언어들의 구현을 지원합니다. JSR-292에 따르면 InvokeDynamic 바이트코드는 정적인 형태의 정보 없이도 효율적이고 유연한 메소드 호출을 수행할 수 있다고합니다. 이러한 동적 언어의 지원은 Java 생태계를 확장하는데 있어 Java SE 7의 매우 중요한 기능으로 볼 수 있습니다.

향상된 멀티코어 그리고 병렬처리 지원

Fork/Join 프레임웍으로부터 시작된 멀티코어 대응의 API는 개발자들이 작업을 다중 프로세서 코어를 이용하여 병렬 수행하는데 있어 좀더 손쉽게 작업을 분배할 수 있도록 도와줄 것입니다. 이는 개발자들이 다중 코어 프로세서를 좀더 잘 활용할 수 있도록 도와줄 것입니다.

개발자 생산성을 위한 컴파일러 최적화

개발자의 생산성 향상에 대한 지원으로 Project Coin을 통한 일반적인 프로그래밍 작업의 단순화와 줄어든 코드와 같은 언어상의 변화가 제공됩니다. 이는 구문을 명확히 하고 코드의 가독성을 높여줄 것이라고 합니다.

Project Coin의 생성자 호출을 위한 다이아몬드 구문은 컴파일러가 타입변수를 명시적으로 기술하지 않더라도 추론을 통해 찾을 수 있도록 하며 try-with-resources 문(하나 이상의 자원을 선언하는 try 구문, 여기서 자원은 프로그램이 끝날때 반드시 닫혀야 하는 객체임)은 파일, 소켓 그리고 DB커넥션과 같은것을 닫는걸 잊더라도 컴파일러에서 자동으로 닫힌 안정적인 코드를 생성합니다.

* Project Coin과 관련하여 별도의 게시물을 작성할 생각입니다.

File I/O, 그래픽 그리고 사운드 향상

Java의 아버지 제임스 고슬링은 파일 시스템 기능중 하나인 NIO2를 특별히 좋아한다고 밝힌적이 있었습니다. 새로운 NIO2의 기능으로 파일 시스템상 좀더 다양한 파일 속성의 작업에 대한 인터페이스를 제공하고 에러와 관련해서도 좀더 많은 정보를 제공한다고 합니다.

네트워크 파일 I/O에 있어 Socket Direct Protocol(SDP) 기능을 중요하게 꼽고 있는데 iSCSI의 경쟁자인 Infiniband에 있어 가상화 환경에서의 진전을 위한 향상된 지원을 할 것이라고 합니다.

Java SE 7은 2D 그래픽 렌더링을 위한 XRender 파이프라인 기능을 제공하며 이는 XWindow 시스템 최상위에서 동작하며 최신 그래픽 프로세서에 접근할 수 있습니다.

Gervill이라 불리는 새로운 사운드 엔진은 리눅스 상에서 다중 어플리케이션이 Audio Synthesis Engine Project MIDI synthesizer를 이용하여 소리를 낼수 있도록 합니다.

마치며..

복잡한 환경속에서 새로운 기능들이 추가된 Java 7이 발표 되었지만 여전히 주변에는 많은 문제가 산재해 있는것 같습니다. 오라클과 구글의 소송에 대한 뭔가 명확하지 않은 상황, 아파치 재단과의 불화 그리고 래리 아저씨의 탐욕은 승리할 수 있을것인가? 이런 사실들은 분명 많은 사람들이 Java에 대해 긍정적일수 만은 없는 상황을 만들고 있는 것 같습니다.

2012년 5월 15일 화요일

차세대 메모리 Hybrid Memory Cube



DDR3 이후 메모리 시장은 어떻게 변할 것인가? 꽤 지리하게 이어져온 DDR 시장의 다음은 DDR4가 아닌 HMC가 될 가능성이 높아지는 국면으로 접어 들게 되었다. 인텔-마이크론, 삼성의 컨소시엄 참여 그리고 얼마전 MS도 참여했다는 소식도 들리는 것으로 봐서 램버스 라이센싱의 DDR 메모리 시대도 이제 저무는게 아닌가 싶다.(MS가 참여한건 HMC의 시스템 드라이버 개발이 필요해서가 아닐까 추측중.. 물론 XBOX에 채용하는 것도 염두에 뒀을듯..)

대규모 분산 네트웍 시스템과 차세대 HPC 시스템의 성능 향상을 위해 개발된 HMC이다보니 왠지 병렬성하면 GPU 또한 빼놓을 수 없고 시장에 도입되게 되면 PC를 비롯해서 VGA카드 등 기타 여러 기기에 사용될 것으로 예상된다.

HMC 공식 페이지에서 소개하는 특장점을 보자면 다음과 같다.
  • HMC는 메모리 다이를 TSV(through-silicon-via)로 묶어 쌓아올린것에 고속의 논리 처리 기술을 조합한 것이다.
  • 기존 메모리의 제약사항을 뛰어넘는 엄청난 성능과 대역폭 향상을 제공한다. 단일 HMC는 DDR3 모듈의 15배에 해당하는 성능을 제공함
  • 현재 사용되는 메모리 대비 엄청난 효율성을 제공함. DDR3 DRAM과 비교할 경우 비트당 에너지 소모가 70% 정도 줄어듬
  • HMC는 비트당 밀도가 증가해서 폼팩터(쉽게 말해 부품이 차지하는 공간)를 줄이고 이를 유지하는데 들어가는 총 비용을 감소시키는데 기여하게 된다. 오늘날 사용되는 RDIMM에 비해 90% 정도 사용 공간이 줄어들고 이로인해 더 많은 메모리를 탑제할 수 있게 됨.
HMC의 시장 도입이 언제쯤 될지 아직 모르겠지만 폼팩터 부분에 있어서 꽤 많은 변화가 있을것으로 예상된다. 마지막으로 Micron에서 제공하는 홍보영상으로 글을 마친다.

2012년 5월 9일 수요일

NAND Flash, Synchronous vs Asynchronous

참고 : http://www.hardocp.com/article/2011/08/07/nand_flash_faces_off_synchronous_vs_asynchronous/1 , http://www.tomshardware.com/reviews/tests-ssd-review-solid-state,3103-7.html


태국 홍수의 여파로 HDD의 가격이 상승하고 SSD의 가격이 점차 저렴해 지는 추세가 되자 SSD의 구매를 시도하는 사용자는 점차 증가하는 추세인데. SSD구매 시 쉽게 놓칠 수 있는 부분인 NAND의 동작 방식에 대해 이야기를 해볼까 한다.

동기식 vs. 비동기식

SSD가 대중에 선보인 초기에만 하여도 보통 NAND의 타입이 SLC인지 MLC인지로 구분을 많이 하였는데 최근에는 MLC타입이 주를 이루고 MLC에서 타입이 한번 더 분류되는 상황으로 변화하게 되었다. SSD를 구매하기 위해 제품을 살펴본 적이 있다면 아마도 스펙시트를 유심히 살펴본 적이 있을것인데 NAND 타입 항목에 Synchronous 혹은 Asynchronous라는 문구를 본적이 있을 것이다. ONFi(Open NAND Flash Interface)라는 기구가 있어서 NAND Flash에 대한 인터페이스를 정의하고 있는데 비동기식은 ONFi 1.0 스펙을 따르고 있고 동기식의 경우 ONFi 2.x이후 부터 언급되고 있다.

간단히 이해를 돕기 위해 제품을 하나 언급 하자면 OCZ의 경우 Vertex 3(이미 Vertex4가 나왔지만 앞세대 제품을 예로 들기로 하겠다.)는 동기식을 Agility 3는 비동기식 NAND를 사용한 예로 들 수 있다. 두 제품은 동일한 샌드포스 SF-2281 컨트롤러를 사용하고 25nm 공정의 NAND Flash를 사용하였다. 다른점은 NAND의 타입이 하나는 동기식이고 하나는 비동기식인건데 ONFi 2.x가 이전 버전과 다른점을 대표적으로 꼽자면 중앙 타이밍 서킷을 채용한 점과 클럭의 상승과 하강에 모두 데이터가 전송될 수 있다는 점이다. 이는 DDR RAM의 동작 방식과 비슷하며(SDR RAM과 비교하자면) 스펙 문서상으로는 두배 이상의 최대 전송속도의 차이가 있는것으로 알려져 있다.

그렇다면 문제는 무엇인가?

일반적으로 제조사에서 제공 되어지는 스펙에는 이야기되지 않은 부분이 많다. 최근의 벤치에서 비동기 방식의 NAND Flash에 샌드포스 SF-2281 컨트롤러를 사용할 때 성능에 영향을 주는 것은 압축할 수 없는 데이터 그게 아니라면 샌드포스 컨트롤러로 넘겨지기 전에 이미 압축된 데이터(예를 들면 .jpeg나 .mp3 파일 같은)에 한정되어 있다고 이야기 하고 있지만 실은 그것만이 전부는 아니다. 그럼에도 불구하고 제조사에서 제공하는 최대(?) 스펙에는 동기식과 비동기식의 차이가 그다지 크지 않다는 것을 발견할 수 있을것이다.

샌드포스 컨트롤러의 핵심은 데이터 압축을 통한 퍼포먼스 향상에 있으며 이를 위해 여러 방식을 이용하고 있지만 가장 큰 역할을 하는 것은 역시 압축 기술이다. 샌드포스 컨트롤러를 채용한 비동기 방식의 플래시 드라이브의 퍼포먼스가 압축할 수 없는 데이터의 흐름에만 영향을 받는다고 잘라 말할 수는 없다 왜냐하면 모든 데이터는 플래시에 기록되는 순간에 압축되기 때문이다. 이에 있어 플래시에 기록되는 모든 데이터는 압축되어 기록되기 때문에 데이터가 파일타입으로 인해 압축된 건지 컨트롤러에 의해 압축되는 건지는 중요하지 않다. 이로 인한 퍼포먼스 감소는 최대 60%까지 발생할 수 있는데 이에 대한 언급을 하는 리뷰는 보기 쉽지 않다.
 
다음은 실 사용과 관련한 벤치마킹 결과의 자료이다. 좌표의 그래프들을 참고하기 바란다.

결론

동기식과 비동기식의 SSD 드라이브의 퍼포먼스에는 상당한 차이가 있음을 알게 되었을 것이다. 그렇다면 어떤 제품을 구매할 것인가?의 문제가 남게 되는데 최근에 그나마 많이 하락 하기는 했지만서도 의외로 둘 사이의 가격차이는 아직 상당한 편이다(개인적으로도 아직까지는 합리적인 가격 차이는 아니라고 생각한다). 만약 RAID0 구성시의 리스크에 대해 별로 신경쓰지 않는다면 고용량의 동기식 SSD를 구매하는 것보다는 저용량의 비동기식 SSD를 구매하여 RAID를 구성하는 것이 이득일 수도 있다는 것이다.

2012년 5월 3일 목요일

Eclipse & JVM 튜닝을 위한 기초지식


개요


Eclipse의 시작은 $ECLIPSE_HOME/eclipse.ini파일에 정의된 옵션으로 제어된다. 만약 $ECLIPSE_HOME이 정의되지 않았다면 Eclipse가 설치된 디렉토리(맥을 사용하고 있다면 Eclipse.app/Contents/MacOS 디렉토리를 참조하게 된다)의 eclipse.ini파일을 참조하게 된다.

eclipse.ini는 커맨드라인 옵션을 포함하는 텍스트 파일로 커맨드라인에 추가된 명령어들은 Eclipse가 시작되었을 때 사용된다. 여기에는 많은 옵션들이 존재하며 다음의 좌표를 참고할 수 있다.

*중요
  • 각옵션과 옵션에 해당하는 각각의 변수들은 반드시 해당 라인에 위치해야 한다.
  • -vmargs다음의 라인들은 JVM의 변수로 통과되어 지기 때문에 eclipse를 위한 변수나 옵션들은 반드시 -vmargs 앞에 위치해야한다(1번의 규칙과 비슷하다고 볼 수 있음)

JVM 지정하기


Eclipse 튜닝을 위해 가장 추천되는 방법으로는 Eclipse를 실행하기 위한 특정 JVM을 지정하는 것 이다. 이렇게 하는 것은 정확히 어떤 JVM에서 Eclipse가 동작하고 있는것인지를 보장해주며 시스템에대한 표준 JVM이 변경되는 것과 같은 시스템 변화에 대한 영향을 받지 않도록 하여준다(JVM은 여러개가 설치될 수 있고 어떤것을 시스템 표준으로 사용할지는 설정하기 나름임). 많은 사용자들이 기본값으로 어떤 JVM이 사용될거라는 것을 알고 있다고 생각하기 때문에 당황스러운 실수를 하기도 한다. eclipse.ini는 그런 문제에 대해 확신을 갖을 수 있도록 해줄 것 이다.

다음의 eclipse.ini의 예시는 -vm 옵션의 정확한 용법의 예를 보여주고 있다.
*주의 -vm 옵션의 형식과 관련해서 정확하게 기술하는 것이 무엇보다 중요하다.
  • -vm 옵션과 해당하는 값(경로)는 반드시 다른 라인에 위치해야 한다.
  • 값은 반드시 Java 홈 디렉토리만이 아닌 Java 실행을 위한 절대경로 혹은 상대경로이어야 한다.
  • -vm 옵션은 반드시 -vmargs 옵션의 앞에서 선언 되어야 하며 -vmargs 다음에 오는 모든 값은 JVM으로 곧바로 전달된다.
다음은 eclipse.ini에 -vm 변수를 추가하고 최대 힙 공간을 증가시킨 예제이다.

        -startup
    plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
    --launcher.library
    plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20110502
    -product
    org.eclipse.epp.package.java.product
    --launcher.defaultAction
    openFile
    --launcher.XXMaxPermSize
    256M
    -showsplash
    org.eclipse.platform
    --launcher.XXMaxPermSize
    256m
    --launcher.defaultAction
    openFile
    -vm
    C:\Java\JDK\1.6\bin\javaw.exe
    -vmargs
    -Dosgi.requiredJavaVersion=1.5
    -Xms40m
    -Xmx1024m

한가지 기억해야 할점은 이러한 옵션들에 대한 적절한 값이 운영체제나 Eclipse 패키지 버전에 따라 다를 수 있다는거다.

Java HotSpot VM 옵션


Java HotSpot VM 옵션들의 범주

Java HotSpot VM이 인식할 수 있는 표준 옵션에 대한 설명은 윈도우즈, 솔라리스 그리고 리눅스에 대한 Java Application Launcher 참고 페이지에서 확인할 수 있다. 다음에 다를 내용들은 Java HotSpot VM에서 인식할 수 있는 비표준 옵션에 대한 이야기이다.
  • -X로 시작되는 옵션들은 비표준(모든 VM에 대해 지원되는 것을 보장하지 않음)이며 추후 JDK 릴리즈에서 별다른 공지 없이 변경될 수 있다.
  • -XX로 정의되는 옵션들은 불안정한 옵션이며 마찬가지로 별다른 공지 없이 변경 될 수 있다.
1.3.0 이전의 JDK 사용자의 경우 Exact VM 플래그를 참고하여야 한다(Java HotSpot VM은 1.3.0이후에 도입되었음).

일부 유용한 -XX 옵션들

기본 값들은 Java SE6의 Solaris Sparc 버전에서 -server옵션 목록에 포함되며 일부 옵션들은 아키텍쳐/OS/JVM 버전에 따라 다양할 수 있다. 플렛폼 별로 갖는 다른 기본 값은 설명을 참고하면 된다.
  • Boolean 옵션들은 -XX:+<option>을 이용해서 켜거나 -XX:-<option>을 이용해서 끌 수 있다.
  • Numeric 옵션들은 -XX:<option>=<number>를 이용해서 설정할 수 있다. 이렇게 표기된 숫자들은 메가바이트에 대해 'm' 또는 'M'을 붙여 표현할 수 있고 킬로바이트는 'k' 또는 'K' 그리고 기가바이트에 대해 'g' 또는 'G'를 붙일 수 있다.(예를 들자면 32k는 32768과 같다)
  • String 옵션들은 -XX:<option>=<string>을 이용해서 설정할 수 있다. 일반적으로 파일 또는 경로를 지정하거나 옵션에 해당되는 명령어들을 사용할 수 있다.
설명에 manageable이라는 플래그가 표시된 것은 JDK 관리 인터페이스(com.sun.management.HotSpotDiagnosticMXBean API)와 JConsole을 통해 동적으로 사용될 수 있다. Java SE 6 플렛폼 어플리케이션의 모니터링과 관리의 Figure 3에서 예를 보이고 있다. manageable 플래그는 jinfo-flag를 통해서 설정할 수도 있다.

다음의 옵션들은 다소 느슨한 기준으로 그룹지어져 각 카테고리에 포함되어 있다.(클릭하면 해당 리스트로 이동합니다)

2012년 4월 12일 목요일

XML 1.0을 써야하는 이유

참고 : http://www.cafeconleche.org/books/effectivexml/chapters/03.html , http://en.wikipedia.org/wiki/C0_and_C1_control_codes

XML을 쓰다보면 1.1버전이 존재하는데 왜 1.0만을 쓰는걸까 라는 의문이 들었던게 생각나서 정리해 봅니다.

XML 1.1에 대해 알아야 할 모든것은 다음 두가지로 요약될 수 있다.
  1. 사용하지 마시오.
  2. (전문가 한정)혹시 몽고어, 일본 메이지 시대에 사용되다 없어진 Yi음절, 캄보디아어, 암하라어, 몰디브어, 버마어 또는 일부 다른 소수언어로 이야기 하고 있거나 이런 언어를 이용해서 마크업(일반 텍스트가 아닌 마크업임)을 표기하길 원한다면 XML 버전 선언부 속성을 1.1로 설정할 수 있다. 만약 그게 아니라면 첫번째 규칙으로 돌아가시오.
XML 1.1은 다음에 나오는 여러가지를 행하며 이들 중 극히 제한적으로 몇몇 개발자들에게 유용한 것도 있겠지만 대부분의 경우 사용하는것에 있어 유익하지 않다.
  • 네임 문자열(예를 들면 엘리먼트명, 어트리뷰트명, 엔티티명 등등)에 대해 문자열 셋을 확장할 수 있게 한다. 이는 잠재적으로 문서를 이해하기 힘들게 한다.
 
<?xml version="1.0" encoding="UTF-8"?>
<book>
<title>የማቴዎሰ  ወንጌል</title>
<chapter number="">
<title>የኢየሱሰ የትው ልድ ሐረግ</title>
<verse number="">
  የዳዊት  ልጅ፣ የአከርሃም ልጅ የሁ ነው የኢየሱሰ ከርሰቶሰ የትው ልድ ሐረግ የሚከተለው  ነው፤
</verse>
<verse number="">
አከርሃም ይሰሐቅነ ወለደ፤
ይሰሐቅ ያዕቆብነ ወለደ፤
ያዕቆብ ይሁዳነና ወነድሞቹነ ወለደ፤
</verse>
</chapter>
</book>

 
이랬던 것이

 
<?xml version="1.1" encoding="UTF-8"?>
<መጽሐፋ>
<አርእስት>የማቴዎሰ  ወንጌል</አርእስት>
<ምዕራፋ  ዌጥር="፩">
<አርእስት>የኢየሱሰ የትው ልድ ሐረግ</አርእስት>
<ቤት  ዌጥር="፩">
  የዳዊት  ልጅ፣ የአከርሃም ልጅ የሁ ነው የኢየሱሰ ከርሰቶሰ የትው ልድ ሐረግ የሚከተለው  ነው፤
</ቤት>
<ቤት  ዌጥር="፪">
አከርሃም ይሰሐቅነ ወለደ፤
ይሰሐቅ ያዕቆብነ ወለደ፤
ያዕቆብ ይሁዳነና ወነድሞቹነ ወለደ፤
</ቤት>
</ምዕራፋ>
</መጽሐፋ>

이렇게도 쓸 수 있게됨 -_-;
  • 폼피드, 수직탭, BEL 그리고 DC1에서 DC4의 C0 제어 문자들(NUL 제외)들이 XML 문서 상에서 일반 문자 처럼 이스케이프 되어 인식된다. 하지만 정말 의미 없는 기능중 하나다.
  • C1 제어 문자들(NEL 제외)은 반드시 이스케이프 된 문자이어야 한다. XML 1.1이 상위셋이 아닌데다가 XML 1.0과 상호 호환성 또한 유지되지 않는 문제가 있음 (원문의 예시 참고)
  • NEL(2바이트의 CR LF를 단일바이트로 대체하는 문자)을 XML 문서에서 사용할 수 있지만 LF로 파싱됨. IBM의 메인프레임에서나 사용하던 문자로 일반적인 다른 시스템의 에디터에서 열 경우 엉망진창인 문서를 볼 수 있게된다. (원문의 예시 참고)
  • 파서는 아마도(꼭 그럴 필요가 있는건 아니지만) 유니코드 데이터가 정규화 되지 않았다고 클라이언트 어플리케이션에 알릴것이다. 유니코드에서는 동일한 문자가 다른코드 에서도 제공되는 케이스가 있는데 이럴 경우 XML1.1에선 더블케릭터가 아닌 싱글케릭터를 사용해야만 한다.
  • 네임스페이스 접두어가 불명확 할 수 있다. 실제로 사용할 일이 거의 없을 뿐더러 XML1.1과의 호환성을 유지하기 위한 부대비용이 많이 들게된다. (원문의 예시 참고)

2012년 4월 3일 화요일

EBNF(Extended Backus-Naur Form)

참고 : http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form , http://www.w3.org/TR/REC-xml/#sec-notation

1. 정의

컴퓨터 과학에서 Extended Backus-Naur Form(EBNF)는 메타구문 표기법 중에 하나로 context-free grammar(컴퓨터 프로그래밍 언어나 다른 포멀랭귀지를 정식으로 설명하는 방법)를 표현하는데 사용되어진다. Backus-Naur Form(BNF) 메타구문 기술법의 확장형이다.

  • ISO는 EBNF를 표준으로 채택함(ISO/IEC 14977)

2. 기초

EBNF는 컴퓨터 언어의 문법을 설명하는 코드로 터미널심볼과 넌터미널 생성 규칙(어떤 방식으로 터미널심볼이 규칙에 맞는 순서로 조합될 수 있는지를 통제하는 제약사항)으로 구성되어 있다. 터미널심볼의 예로 알파누메릭 문자, 문장 부호 그리고 공백 문자들을 들 수 있다.

EBNF는 생성 규칙에 있어 심볼의 시퀀스 각각을 넌터미널에 할당하는 것으로 정의하고 있다.

digit excluding zero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
digit = "0" | digit excluding zero ;


식의 왼편에 할당된 digit은 넌터미널로 정의 되고 수직바는 선택적임을 나타내며 터미널심볼은 인용부호로 감싸지며 뒤를잇는 세미콜론은 종료문자를 나타낸다. 그러므로 digit은 0이거나 1 또는 2 또는 3.... 또는 9까지의 수가 될 수 있는 digit excluding zero이다

생성 규칙은 연속되는 터미널 또는 넌터미널을 포함하며 각각은 콤마로 구분된다.

twelve = "1" , "2" ;
two hundred one = "2" , "0" , "1" ;
three hundred twelve = "3" , twelve ;
twelve thousand two hundred one = twelve , two hundred one ;


생략되거나 반복되는 것에 대한 표현은 중괄호를 통해 나타낼 수 있다 {.....}

natural number = digit excluding zero , { digit } ;


이경우는 첫째 자리는 1-9중 하나 뒷 자리는 없을 수도 혹은 중괄호의 값(0-9의 숫자)이 임의의 자릿수 만큼 반복될 수 있는것을 나타낸다.

임의 선택은 대괄호를 통해 나타낼 수 있다 [.....] 이는 대괄호 안의 값이 단 한번 혹은 없을 수도 있다는 것을 나타낸다.

integer = "0" | [ "-" ] , natural number ;


그렇기 때문에 integer는 0이거나 -부호가 있거나 없는 natural number가 된다.

3. 심볼 테이블
 
용법                    표기법
definition          =
concatenation     ,
termination       ;
alternation         |
option               [...]
repetition          {...}
grouping             (...)
terminal string   ...
terminal string   '...'
comment            (*...*)
special sequence   ?...?
exception           -

4. simple EBNF

XML의 정규문법은 simple EBNF표기법을 사용한다. 문법상 각 규칙은 형식상 하나의 심볼로 정의 되어진다.
    symbol ::= expression

      심볼은 정규 언어의 시작 기호인 경우 대문자 머릿글로 그렇지 않은 경우는 소문자 머릿글로 쓰여진다. 문자열이 표기된 그대로를 사용해야 할 경우 인용부호로 감싸서 표현한다. 오른 편에 표기된 식(expression)의 내부 아래에 소개될 규칙을 이용하여 단일 혹은 복수의 문자로 구성된 문자열과 매칭시키는데 사용되어진다.

      #xN
      N은 진수 정수이며 ISO/IEC 10646에서 정의 된 코드 포인트(예를 들자면 ASCII는 128 코드포인트로 구성되어 있고 범위는 0에서 7F까지이다)를 의미하며 식에서 표현하는 것은 N에서 정의된 문자와 일치한다.

      [a-zA-Z], [#xN-#xN]
      표기된 범위 내의 어떠한 문자도 포함 된다.

      [abc], [#xN#xN#xN]
      열거된 문자들 중 어떠한 문자라도 될 수 있고 열거형과 범위는 하나의 괄호셋으로 조합 될 수 있다.

      [^a-z], [^#xN-#xN]
      표기된 범위 이외의 어떠한 문자도 포함 된다.

      [^abc], [^#xN#xN#xN]
      열거된 문자가 아닌 어떠한 문자라도 될 수 있고 사용할 수 없는 값의 열거형과 범위는 하나의 괄호셋으로 조합 될 수 있다.

      "string"
      큰따옴표 안에 표기된 그대로의 문자열이 포함된다.

      'string'
      작은따옴표 안에 표기된 그대로의 문자열이 포함된다.

      이 심볼들은 다음의 좀더 복잡한 패턴들로 조합될 수 있다. A와 B는 간단한 식들을 나타낸다.
      (expression)
      expression은 단위로 취급 되며 다음 리스트에 설명된 것과 같이 조합될 수 있다.

      A?
      A이거나 혹은 없거나; 선택적 A

      A B
      A에 연이어 B가 따라옴. 이 연산자는 |(alternation) 연산자보다 상위 우선순위를 갖는다; 예를 들면 A B | C D 는 (A B) | (C D)로 볼 수 있다.

      A | B
      A이거나 혹은 B이거나

      A - B
      B를 제외한 A에 해당하는 어떠한 문자

      A+
      단일 혹은 복수개의 A. 이 연산자(concatenation)는 |(alternation) 연산자보다 상위 우선순위를 갖는다; 예를 들면 A+ | B+는 (A+) | (B+)로 볼 수 있다.

      A*
      0개 이거나 혹은 복수개의 A. 이 연산자(concatenation)는 |(alternation) 연산자보다 상위 우선순위를 갖는다; 예를 들면 A* | B*는 (A*) | (B*)로 볼 수 있다.

      문서 생성시 사용되는 또다른 표기법은 다음과 같다.
      /* ... */
      코멘트
      [ wfc: ... ]
      적격성 제약; XML문서의 생성과 연관된 적격의 문서(wel-formed documents)에 대한 제약 사항을 이름을 통해 판별한다. (well-formedness constraint : XML 기본 문법을 위반하지 않았는지 여부에 대한 제약)

      [ vc: ...]
      유효성 제약; XML문서의 생성과 연관된 유효한 문서(valid documents)에 대한 제약 사항을 이름을 통해 판별한다. (validity constraint : XML문서는 DTD에 문서에 대해 정의 되어 있는데 이것에 대한 위반 여부를 판단하는 제약)

      2012년 3월 25일 일요일

      Logitech Wireless Gaming Mouse G700

      고양이 두마리를 키우다보니.. 녀석들이 책상을 점거하는 일이 잦아서 무선 마우스가 필요하게 됐는데 그렇다고 매번 배터리를 교체하는 것은 귀찮고 유선으로 쓰다가 필요할때만 무선으로 쓸 녀석을 찾다보니 로지텍의 G700과 레이저의 맘바4G가 눈에 띄었는데..

      맘바4G의 가격과 단점들이 너무 컸고 고속휠기능이 필요했기 때문에 결국 맘바4G 출시시기 즈음에 G700을 구매하게 됐고 몇달 사용하면서 느꼈던 점을 적어보도록 하겠습니다.

      제품 정보와 스펙은 Logitech의 홈페이지를 참고하시기 바랍니다.

      먼저 박스와 제품 사진입니다.


      패키지 구성은 매우 단순하며 드라이버도 로지텍 홈페이지 가서 받으라는 녀석이고 -.- 배터리는 산요의 에네루프 1900mAh용량 제품 그리고 수신기, 수신기 연장 케이블, 마우스 케이블로 구성되어 있습니다.

      수신기 연장 케이블에 마우스를 연결할 수는 없고 유선 사용시 반드시 마우스 케이블로 PC와 연결 하여야 합니다. 전원 버튼을 OFF 상태로 두면 유선, 무선 모두 동작하지 않게 됩니다.. 배터리는 그렇게 오래가는 편은 아니라고 하는데 원래 기본 유선 사용에 필요할때만 무선으로 사용하는지라 방전이 될때까지 사용해본적은 없습니다.

      기존에 사용하던 G9x와 비교했을때 감도나 그립감은 개인적으로 G9x쪽이 좋다고 생각합니다. 원래 무거운 마우스를 선호하는 편인데(G9x도 최대 무게 세팅) 좀 가벼운 느낌이고 손에 감기는 느낌이 없다고 해야하나.. 버튼 클릭감도 G9x쪽이 좀더 편하더군요.. 측면 버튼이 몇개더 추가된 걸로 봐서 MMORPG 게이머를 타겟으로 해서 나온 제품 같은데 확실히 FPS용은 아닌듯 싶습니다. 그리고 유무선 감도와 관련해서는 거의 차이를 느끼지 못했습니다.

      무난한 유무선 마우스에 굳이 장점이라고 꼽자면 배터리가 산요 에네루프 제품이기 때문에 필요하면 시중에서 쉽게 구할 수 있다는 정도일듯 싶군요 : )

      마지막으로..


      제품 포장지에 있던 이미지 인데.. 왠지 웃겨서..

      p.s 그러고보니 혹시 패드써클을 생각하시는 분이 계실까 싶어서.. 이 제품용 패드써클은 따로 없습니다;

      2012년 3월 19일 월요일

      Intel Centrino 카드를 데스크탑에서 사용하기..

      이 글은 팁이라고 하기도 그렇고 뭔가 광고성 글이 될듯한 느낌이..-_-;

      노트북에 보통 사용되는 Intel의 센트리노 카드를 데스크탑용 아답터를 이용해서 설치할 수 있습니다. 센트리노 카드의 경우 노트북에서 사용하는 m-PCIe 인터페이스 이고 데스크탑은 일반 PCIe 인터페이스를 사용하기 때문에 이를 변환해주는 아답터가 필요한데 대만의 Bplus라는 회사의 제품에 대해 이야기 해보도록 하겠습니다.



      PCIe 1x 슬롯에 장착되는 타입이며 인텔의 Centrino Ultimate-N 6300을 장착하고 있습니다. 제품명은 MP2W-6300H이며 설치후 드라이버는 인텔 웹사이트에서 받아서 설치하면 정상 작동하게 됩니다. 노트북을 사용하면 볼 수 있었던 익숙한 제어판 화면을 데스크탑에서도 볼 수 있게 되는 것이죠.. : )


      아답터의 경우는 기본 장착 된 인텔 센트리노 카드 이외에 다른 카드들도 장착이 가능합니다.. 일부는 아답터의 USB 포트를 이용해서 노트북에 연결이 가능하기도 합니다(홈페이지의 호환성과 관련한 스펙시트 참고) . 물론 장착된 m-PCIe카드를 노트북에 직접 설치 하는 것 또한 가능 합니다.

      일단 이 제품을 구매하게 된 이유가 기존에 사용하던 USB 타입 제품의 드라이버 문제로 시스템 행이 자주 걸렸던 것과 유선을 사용할 수 없는 문제(아무래도 이게 제일 컸던 --;) 때문에 구매하게 되었는데 가격은 꽤 비쌌지만(배송비 포함 배추14장 정도 들었습니다..) 만족스럽게 사용하고 있습니다.

      혹시 제품을 구매하길 원하는 분을 위한 팁을 몇가지 알려드리자면 일단 결제 가능한 페이팔 계정이 있어야 합니다. 계정의 개인 정보 또한 정확히 입력이 되어 있어야 하며(해당 페이팔 계정 정보의 이메일로 배송 정보를 알려오며 배송지 또한 계정에 입력한 주소로 발송이 됩니다..) 발송이 되면 DHL 특송으로 발송되기 때문에 수도권 기준으로 다음날이면 받아 보실 수 있습니다.

      제품의 장단점을 몇가지 짚어보자면 다음과 같습니다.

      +요소 :
      드라이버가 안정적인 편이며 인텔의 업데이트를 받을 수 있다.
      아답터와 장착된 카드의 개별 활용이 가능하다.
      기존에 사용하던 일반적인 USB타입의 제품에 비해 안정적인 속도를 제공한다(공유기 제한 150Mbps에 144Mbps 정도 나오는군요..).

      -요소:
      가격이 비싸다.
      6300N의 경우 블루투스 기능이 포함되어 있지만 사용할 수 없다(드라이버 문제인지 해당 아답터로는 지원이 불가능한건지 확인해보지 않았습니다..)
      간혹 제품이 인식이 안되는 경우가 있다.(최초 설치 할때 인식이 안되는 문제를 겪었습니다. 메인보드의 슬롯에서 뽑았다 다시 설치했더니 인식을 하더군요.. 보드와의 호환성 문제인건지 모르겠지만 PC전원을 완전히 셧다운 한적이 있었는데 동일 증상이 발생해서 같은 방법으로 해결 했습니다.)

      ** 참고로 Windows 7에서 AMD의 bulldozer혹은 piledriver 코어의 Microcode 업데이트를 적용한 시스템에서 인텔 Wifi 드라이버와 충돌로 인해 블루스크린이 발생하는 문제가 있어 현재는 사용하지 않고 있습니다.

      2012년 3월 18일 일요일

      USB 저장장치로 Windows 7을 설치해보자!

      ODD가 없을경우 OS를 설치하기 위해서 USB 저장 장치를 이용하고자 할때 기본적으로 USB 저장 장치는 부팅이 불가능한 상태이기 때문에 약간의 작업이 필요합니다.


      커맨드 라인에서 diskpart를 실행합니다.


      list disk 명령어를 이용하여 크기를 확인 후 연결된 USB 저장장치를 확인합니다. 여기에서는 disk 3 입니다.(잘못 선택하면 엉뚱한 디스크가 날아가니 주의 요망!)


      select 명령어를 이용해서 disk를 선택한 뒤 clean 명령어를 이용하여 디스크를 초기화 하고 create partition primary명령어를 이용해서 주 파티션을 생성합니다. list partition 명령어를 이용하여 파티션이 생성된 것을 확인합니다.


      select partition 명령어를 이용하여 생성된 1번 파티션을 선택하고 active 명령어로 활성 상태로 설정합니다. 마지막으로 NTFS 파일 시스템으로 빠른 포멧을 진행합니다.

      이제 USB 저장 장치에 OS 설치 디스크를 통째로 복사하시면 USB 저장장치로 부팅해서 설치가 가능합니다.

      이 방법은 USB인터페이스를 갖는 HDD, 플래시메모리 모두 가능한 방법입니다 : )

      2012년 3월 16일 금요일

      작업관리자의 프로세스 우선순위를 기억시켜보자!

      윈도 기본 탑제의 작업관리자에서 특정 어플리케이션 퍼포먼스를 위해서 프로세서 우선순위를 변경할 수 있지만 기억시켜주는 기능은 존재하지 않는다. 하지만 이를 해결할 방법이 있으니..

      Prio(개인 사용시 프리웨어)라는 어플리케이션을 설치하면 다음과 같은 화면을 볼 수 있다.



      Ctrl + Shift + Esc 키를 누르면 TCP/IP라는 탭이 상단에 추가되어 있고 프로세스 정보를 보면 Save Priority라는 항목이 존재하는 것을 확인 할 수있다.. 그렇다 이제 설정한 값이 기억이 되는 것이다..

      물론 설정을 변경하게되면 시스템 크래쉬를 야기할 수 있다는 경고문구는 그대로 뜨며 --; 최적의 설정값은 직접 테스트 해보는 방법밖에는 없다는 숙제가 남겨지게 된다..

      p.s Silent Elevation옵션은 UAC가 활성화 되어 있을때 해당 프로세스를 관리자 권한으로 실행하게 해주는 옵션임..