Dvorak 키 배치 사용 시작

Computing 2008.05.22 00:57
지난 일요일부터 대략 4일동안 회사에서 한 일은 예외상황 처리 루틴을 만드는 일이었다.
예외상황을 다루는 매크로는 아래와 같은 것들이 있다 :

ACE_EXCEPTION
ACE_EXCEPTION_END
ACE_TEST
ACE_TEST_RAISE
ACP_RC_SUCCESS

위의 것들 중, 주황색으로 표시된 것들은 왼손으로 누르는 자판들이다.
어림짐작으로 80% 가량의 자판을 왼손으로 누르게 되어 있다.
오른손과 번갈아 가면서 누르는 것이 아니라 왼손만 줄기차게 연속으로 움직여야 한다.
그것도 손목에 무리가 많이 가는 새끼손가락, 약지, 중지의 비율이 상당하다.

4일동안 저런 코드만 엄청난 양을 타이핑한 결과 왼손의 손목, 팔꿈치, 심지어 어깨와 왼쪽 대흉근까지 결리는 현상이 생겼다. 은근히 기분나쁘게 아픈 통증이 생긴 것이다.

이러한 이유로 인해 급작스럽게 qwerty 가 아닌 dvorak 자판을 써 보기로 마음먹고 자판 배열을 바꾸었다.
동일한 단어(?)들이 dvorak 배열에서는 다음과 같다 : (주황색은 왼손임)

ACE_EXCEPTION
ACE_EXCEPTION_END
ACE_TEST
ACE_TEST_RAISE
ACE_RC_SUCCESS

얼핏 보기만 하여도 색깔이 골고루 섞여 있다는 것을 알 수 있다.
게다가 자세히 보면 같은 손가락을 두번 이상 사용하는 경우도 매우 적음을 알 수 있다.

문제는 vim 의 키 바인딩이었는데, 이것만 극복하고 익숙해지면 괜찮을 듯 하다. 그렇지만, 손가락을 움직이는 근육에 각인된 키 시퀀스의 기억을 바꾸는 데에는 상당한 노력이 필요할 듯 하다. 새로운 기억을 각인시켜야지 어쩌겠누...

직업상 한글 자판보다 영문 자판을 많이 사용해야 하는데, 자판 배열을 바꾼 것이 육체적으로 좀 도움이 되길 기대한다.


Dvorak Simplified Keyboard Layout

Dvorak Simplified Keyboard Layout



웃기는 문제가 하나 있는데, 한글 입력 모드 두벌식에서는 [ ] ' " / . , < > 등이 qwerty 와 동일하지만, 영문모드에서는 이것들이 위치가 바뀌는 것이다. 익숙해지면 괜찮으리라 생각한다.
좀 있다가 한글 자판도 세벌식으로 바꿀까 생각중이다.

위키피디아의 QWERTY 항목에서는 대안 키보드 배치들 중 하나로 Dvorak 을 소개하면서 설명하는 글이다.
확실히 더 빠른지 혹은 더 효율적이고 편안한지에 대한 "학술적" 연구 결과는 없지만, 사용자들이 느끼는 편안함에 대한 "정성적" 차이는 있다고 한다. 그렇지만 이 조차도 이 배열을 만든 사람인 Dvorak 에 의해 조작된 심리적 믿음(?) -- myth -- 일지도 모른다고 설명하고 있다.
그러나 타이핑 세계기록 보유자가 이 자판을 사용한다는 이야기도 있으니 뭔가 있기는 있는 모양.

위키피디아의 해당 부분을 발췌했다 :

Because modern keyboards do not suffer from the problems of older mechanical keyboards, the QWERTY layout's separation of frequently used letter pairs is no longer necessary. Several alternative keyboard layouts, such as Dvorak Simplified Keyboard arrangement (designed by Dr. August Dvorak and William Dealey and patented in 1936), have been designed to increase a typist's speed and comfort, largely by moving the most common letters to the home row and maximizing hand alternation. Some studies have shown that alternative methods are more efficient, but Dvorak and other alternative typists most often cite comfort as the greatest advantage. QWERTY's inventor, Christopher Sholes, patented a key arrangement similar to Dvorak's, but it never became popular.[citation needed]

Some researchers, such as economists Stan Liebowitz of University of Texas at Dallas, Texas and Stephen E. Margolis of North Carolina State University, claim that QWERTY is really no less efficient than other layouts; however, their study has been disputed by advocates of the Dvorak key setup. [3] Some believe that there is evidence to support the claim that Dvorak is faster. The world record for typing speed was made on a Dvorak keyboard. [4] Opponents claim[who?] that August Dvorak stood to gain from the success of his layout, and that he may have perpetuated this "efficiency myth" to increase his financial gains. Other QWERTY advocates claim that for a QWERTY typist to switch to Dvorak or another layout requires more effort than initially learning to touch-type, because of having to retrain the fingers' muscle memory; however, the opposite claim is also made because the Dvorak layout is supposedly more intuitive.

Computer users also need to unlearn the habit of pressing certain key shortcuts, e.g.: Ctrl + C for copy, Ctrl + X for cut, Ctrl + V for paste, on Microsoft Windows, as X, C and V are next to each other on a QWERTY keyboard). However, some programs and operating systems allow the use of alternate layouts combined with QWERTY shortcuts; for example, Mac OS X offers a "Dvorak-QWERTY" keyboard layout that temporarily reverts to QWERTY while the Command key is held down.

Opponents of alternative keyboard designs most often point to QWERTY's ubiquity as a deciding factor, because the costs incurred by using the supposedly inefficient layout are much less than those of retraining typists. It is not unusual to find Dvorak typists who also touch-type the QWERTY layout for convenience, since QWERTY dominates the keyboard market. The tension between the Dvorak efficiency and the QWERTY ubiquity illustrates the problem of collective switching costs, assuming QWERTY's relative inefficiency.




tags : dvorak, vim
Trackback 0 : Comments 2
  1. BlogIcon han9kin 2008.05.22 20:35 신고 Modify/Delete Reply

    영휘씨 컴퓨터 ftp에 올려놓은 파일들 권한이 없어서 읽지를 못해요.
    눈앞에서 있는데, 가져올 수 없는 이 서러움을 아시나요?

    • BlogIcon Orchistro 2008.05.22 20:44 신고 Modify/Delete

      확인해 보니 600 으로 죄다 세팅되어 있었네요. 바꿨습니다. 천천히 감상하세요.

Write a comment


Perfect situation / Weezer

Music/Others 2008.05.20 20:31
Perfec situation / sung by Weezer.

from their "Black" album, Make Believe (2005)

사용자 삽입 이미지


가사는 여기를 눌러요


그런데, 무슨 가사가 -_- ooooo 이렇게...
ㅋㅋ

영화에 삽입된 인상적인 음악은 영화가 끝나고 나서도 좀체로 잊혀지지 않는다. 한동안은 계속 음악이 흐르던 장면과 함께 머릿속에 떠 오르기 마련.

평소에 줄기차게 듣는 음악도 마찬가지이다.
이 경우엔, 영화의 단편적인 장면이나 스토리와 함께 기억되는 영화 삽입곡들과는 달리 한창 그 음악을 듣던 시기의 감정 상태와 음악 자체가 주는 분위기가 섞여서 매우 표현하기 힘든 그 어떤 느낌과 함께 기억된다는 것이 영화 음악과 다르다.

길지 않은 젊은 날이었지만, 나에게도 질기게 머릿속 한 구석에 남아 있는 음악이 몇몇 있다.
그것들은 가슴이나 대뇌 어딘가에 널부러진 감정 찌끄러기의 더미 위에 책장 위의 먼지처럼 앉아서 완전히 잊혀진 채로 있다가 몇년 후에 문득 듣게 되는 음악의 파동에, 훅 불면 일어나는 선반 위 먼지처럼, 그때의 감정과 함께 인식기관으로 다시 돌아온다.

감정이라기보다 분위기, 감상, 느낌, 심적 상태, 아련함, 그리움, 시원함, 불안함 등과 같은 오만가지 것들이 한꺼번에 섞인 어떤 "정수" 라고 하는 것이 더 알맞은 말이겠다. 봄 골짜기에 아카시아 향기마냥 기분좋은 바람을 타고 기억나든, 장마철 하수구의 퀴퀴한 냄새가 올라오듯 스믈거리며 올라오든, 카메라 플래쉬의 섬광이 터지듯 놓칠 수 없는 찰나가 되었든, 당시의 아련함을 불러 일으킨다. 육체는 현재에 있되, 그 외의 것은 얇게 퍼져서 과거의 시간에 뉘이게 되는 것이다.

참으로 신기게도, 노래에 의해 연상된 당시의 아련함(아련함이라고 해 두자) 을 상기하는 것과는 전혀 달리 당시의 상황, 인물, 사건과 같은 "사실" 들은 하나도 기억나지 않더라는 것이다.

그와 같은 음악들 중 하나가 바로 이 곡이다.

문득 저녁을 먹고 이어폰을 꽂는 순간, 섬광과도 같이 정신이 마비되었다.
언제였지,
그게...
언제였을까...
그때 내 주변엔 누가 있었을까...

오늘 밤에는 기억을 더듬으러 싸이월드를 둘러 봐야 하겠다.

Trackback 0 : Comment 0

Write a comment


shift 연산

Computing 2008.05.20 17:01
32비트 컴퓨터에서


위 코드의 출력값은 얼마일까?

제일 처음 떠오르는 답은 0x00000000 일 것이다.

조금 눈치가 빠른 사람이라면 0x00000000 이 상식적인 답이겠지만 답이 0x00000000 이 아니기 때문에 이런 문제를 내었으리라 짐작하고서는 뭔가가 있다고 생각할 것이다.

정말 뭔가가 있다.
컴파일을 하면,

$ gcc b.c
b.c: In function 'main':
b.c:7: warning: left shift count >= width of type

gcc 가 친절하게 warning 도 내어 준다.

실행을 시키면,
$ ./a.out
0x00000002

마치 circular shift된 것 같은 결과가 나온다.
왜 그럴까?

컴파일러가 << 연산의 operand 에 modular 연산을 취할까? 단지 << 연산인데, 그냥 shl 같은 instruction으로 곧장 매핑시키지 않고 modular연산 따위를 컴파일러가 할까? 아무래도 그건 오버하는 것 같다.

cpu instruction manual 을 살펴 보았다.


Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, N-Z 에서는 shift 연산에 대해서 아래와 같이 이야기하고 있다 :


The destination operand can be a register or a memory location. The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used). A special opcode encoding is provided for a count of 1.

역시나, 컴파일러가 오버하는 것이 아니었다.
인텔은 그렇다 해도 다른 CPU, ppc 나 sparc 은 어떨까?
sun 과 aix 에서 테스트 해 본 결과 마찬가지 결과가 나왔다.
sparc v9 instruction set reference manual을 보아도 마찬가지 설명(마스크 아웃한다는)이 나와 있다.

우연히 찾은 것이지만, 재미있는 것이라고 생각되어서 한번 적어 보았다.

tags : C/C++
Trackback 0 : Comment 0

Write a comment


DEBUG macro

Computing 2008.05.20 13:19
C 로 프로그래밍을 하는 사람이라면 거의 모두들 한번쯤 디버깅 메세지를 출력하는 문제에 대해 고민해 보았을 것이라 생각한다.
아마도 빌드 모드가 디버그일 경우에만 매크로가 확장되고, 릴리즈일 경우에는 사라지도록 다음과 같은 매크로를 정의해서 사용했을 것이다 :
그런데 위의 매크로를 쓰면서 불편한 것이 하나 있으니, 바로 다음과 같이 사용할 수 밖에 없다는 것이다 :
그렇다. 치명적인(!!!) 약점이 있으니, 바로 괄호를 두개 써야 한다는 것이다.

C99 표준에서 이 문제를 해결할 수 있도록 매크로에 가변 인자를 지원하는 기능(?)이 포함되었으나 그 표준정의 자체가 한계를 가지고 있는 데다가 (함수의 가변 인자와는 달리 반드시 최소 하나의 인자를 받아야만 한다는 제약사항이 있다) 지원하는 컴파일러마저, VC++ 2005 이상에서만 지원한다. 물론 gcc 는 당연히 지원하는 데다가 플러스 알파로, C99 표준의 약점을 해결하기 위한 확장까지 제공하긴 하지만, 여기서 내가 원하는 것은 모든 컴파일러에서 통용되는 방법이므로 매크로 가변인자 기능을 사용하기에는 무리가 있다.

그러면 보기 싫은 두개의 괄호를 어떻게 해결할까...

아래와 같이 DEBUG 매크로를 정의해 보자.
혹은
컴파일러의 최적화에 의존을 하게 되면 필요없는 printf 는 사라지게 된다. 게다가 요즘 컴파일러는 이정도의 최적화는 기본이다.

재미있는 것은, 아래의 것 보다, 함수 이름을 (void) 로 치환해 버리는 것인데,,,

그러면 위의 첫번째 방법을 사용했을 때 아래와 같은 코드는
프리프로세서를 거치고 나면, 디버그 모드에서는
디버그 모드가 아니면
로 확장되게 된다.

얼핏 보아서는 이게 컴파일이 될까 하는 생각이 들겠지만,
놀랍게도 컴파일이 된다! +_+ (콤마 연산자임)

정말 기발(!)하지 않은가?
나는 수년간 괄호 두개가보기 싫은데도 불구하고 달리 뾰족한 방법을 생각하지 못해서 괄호 두개를 계속 써 왔었는데, 저 방법을 보는 순간 갑자기 마구 억울해지기 시작했다.

물론, 아래의 다소 암호같은(!) (void) 로 치환하는 방법은 (댓글에서 han9kin 님이 지적했듯이) 콤마 연산자로 구분된 각각의 연산이 실행이 되어 버려서 변수의 값이 변할 수 있는 위험이 존재한다.

그러니 뭔가 특이한 걸 써서 "튀"기 보다, 안전하게 while (0) 로 치환하는 방법을 선택하도록 하자.

tags : C/C++
Trackback 0 : Comments 2
  1. BlogIcon han9kin 2008.05.20 13:56 신고 Modify/Delete Reply

    #define DEBUG (void)

    #define DEBUG while (0) printf
    는 제가 보기에는 너무 달라보입니다.

    전자는 인자들에 대한 연산이 모두 실행될 것이고, 후자는 실행되지 않을 겁니다.
    물론 디버깅 정보 출력하는 코드에 연산이 있는 경우는 거의 없겠지만.

    그리고 gcc -W 로 전자를 컴파일하면 다음과 같은 워닝이 나와서 보기가 별로 안좋습니다.
    warning: left-hand operand of comma expression has no effect

  2. BlogIcon Orchistro 2008.05.20 17:04 신고 Modify/Delete Reply

    저도 그래서, 위의 (void) 로 치환한 것은 흥미거리 정도로 생각합니다 :-) 실제는 아래의 while(0) 을 쓰는 것이 나으리라 생각됩니다 :-)

Write a comment


kicking the tires

English 2008.05.20 11:24
John McCain 이 지난 토요일 (2008. 5. 17) TV 토크쇼에 나와서 한 우스갯소리인데,,,
님 좀 짱인듯 ㅋㅋㅋ

If come November, you still haven't decided, I'd be willing to set aside my differences with your party and say,

"Hey, let's put both of them on the ballot."

I'll support you on that, it's the least I can do.
In conclusion, I wanna add that I also thought John Edwards had a lot of good ideas.
And you might wanna kick the tires on him one more time.

kicking the tires : an expression, probably came from buying a used car, when it was often advisable to kick the tires to see if they are old and flabby. The tires are an extra expense that you don't want to take on.
The meaning has broadened into a general saying now. It means "test it out", "check it out for flaws or errors", "try before you buy." If you are walking around a car lot, window shopping, a salesman may come up to you and say, "Do you want to kick the tires?" He doesn't mean that you should actually kick the tires. He means, "do you want to sit in it / ask questions about it / take it out for a test drive?"
Trackback 0 : Comment 0

Write a comment

티스토리 툴바