Ygdrasil

dvorak 자판을 3일정도 사용해 본 결과 다음과 같은 사실을 알게 되었다.

1. 타이핑하는 데 한쪽 손만 집중적으로 사용할 일이 없다. 그래서 물흐르듯 편안한 타이핑이 가능하다.

그러나 위 사실이 양날의 검이 될 줄이야...

우선, ctrl-c, ctrl-v, ctrl-x 등을 하려고 할 때 자판이 분산되어 있는 관계로 예전처럼 오른손에 마우스를 쥐고 왼손만으로 위 의 키 시퀀스를 누르는 것이 불가능해 졌다. c 는 오른손 약지로, v 도 오른손 약지, x 는 왼손 집게손가락으로 눌려야 하는 것이다. 즉, 마우스를 쥐고 있던 오른손이 움직여서 키보드로 와야 한다는 것을 의미한다.

유닉스 명령어들이 qwerty 를 사용할 때에는 몰랐지만, dvorak 을 쓰고 보니 qwerty 에서 사용하기 쉽게끔 만들어진 것 같다는 심증.

일례로, 가장 많이 쓰는 명령어 중 하나인 ls. 이거.. 드보락 자판에서는 오른손 새끼손가락만으로 타이핑 해야 한다. 엎친데 덮친 격으로 ls -la 를 입력하려고 하면 오른손 새끼손가락만 연속으로 네번을 움직여야 한다.

cat 파일네임 을 입력하려고 할 경우, 보통 cat 를 치고 파일이름은 X 의 clipboard 를 사용해서 마우스 오른쪽 버튼을 눌러서 입력하는 경우가 많은데, cat 를 입력하기 위해서 두 손이 모두 자판 위에 올라가야 한다. 즉, 마우스를 쥐고 있던 오른손이 다시 자판으로 왔다가 가야 한다는 사실.

코딩을 많이 하는데, {, }, [, ], 가 모두 오른손 새끼손가락 저편으로 "더 멀리" 올라가 버려서 상당히 입력하기가 어려워졌다.

그리고, vim 의 명령어들의 위치가 바뀌어버린다. 물론 바뀐 명령어의 위치야 적응하면 되겠지만, 한손으로도 편안하게 입력하던 명령어들의 시퀀스가 양손을 모두 이용해야 하는 것으로 바뀌었다는 것. 그래서 평소엔 오른손은 마우스를 잡고, 왼손은 vim 명령어를 입력하는데, 역시나, 마우스를 쥐고 있던 오른손이 자판으로 달려와야 하는 경우가 많이 발생한다는 것.

대략 위와 같은 이유와,
프로젝트의 일정이 매우 빠듯한데, 생산성을 매우 크게 떨어뜨린다는 심리적 압박감으로 인해 다시 쿼티로 돌아왔다.

사무실에서 함께 일하는 존경하는 프로그래머 한 분이 나 때문에 드보락으로 갔다가 나만 빠져 나왔다고 거의 삐짐모드가 되어 버리셨다. ㅋㅋㅋ

큰일났다.
오늘 iMac 을 리스타트를 했는데, 로그인 창의 키 레이아웃이 qwerty 인 것이다.
이미 패스워드를 모두 바꿔버린 상태라 잠시 절망할 뻔 했다.
심호흡을 한번 하고, 마음을 가다듬은 후, 패스워드를 어렵사리 다시 조합해 내어서 로그인 성공.

시스템 환경 설정에서 키보드 레이아웃을 바꿨는데도 로그인 창의 레이아웃은 처음에 MacOS 를 설치했을 때의 디폴트로 남아 있게 된다.

구글님께 여쭤 봤더니 계정의 암호 설정하는 창에서 로그인 윈도우에서 입력 메뉴 보기 라는 체크박스에 체크를 해 주면 Login Window 에서 키보드 레이아웃을 선택할 수 있으니 거기서 드보락을 선택해서 입력하면 된다는 대답을 주신다.
 

이왕 드보락 자판 배열을 사용하기로 한 만큼, 키보드 자판 배열도 그에 맞게 드보락으로 바꾸기로 마음먹었다.
내가 사용하는 키보드는 애플의 알루미늄 키보드이다.
키보드가 예쁜 데다가 타이핑시 소음도 적고, 타이핑 감도 매우 쫀득쫀득한 것이 적절한 반발력도 있어서 타이핑이 매우 기분좋다. 그래서 매킨토시는 구입하지 못해도 키보드는 이것으로 구매해서 사용하고 있다.

자판 배열을 Dvorak 으로 바꾸기 위해서 키캡을 분해해서 빼 내어야 하는데, 이거, 함부로 하면 비싼 키보드님 다치신다 -_-

요령은 다음과 같다.

우선, 아래 사진처럼 날카로운 것을 이용해서 키캡의 윗쪽 모서리를 살짝 들어 올려서 손가락으로 집을 수 있도록 공간을 만든다.

그런 후, 아래 그림처럼 대각선 아래의 모서리를 누르고, 방금 들어올린 윗쪽 모서리를 잡고서 가볍게 "똑" 소리가 날 때까지 들어올린다. 그리고, 또 그 반대쪽 아래의 모서리를 누르고 방금 들어올린 윗쪽의 반대쪽 모서리를 잡고 "똑" 소리가 날 때까지 들어올린 후 조심스레 들어내면 된다.

주의할 것은 만약 아래쪽부터 들어내려고 시도하면 키캡을 망가뜨리게 된다는 사실인데, 왜냐하면 내부 구조가 아래 사진과 같이 생겼기 때문이다. 아랫쪽 첫번째 사진의 커터 칼이 들어가 있는 부분에 약간 튀어나온 녀석이 아래 사진의 홈 안쪽의 구멍에 쏙 들어가서 끼워져 있기 때문에 아랫 부분을 억지로 들어올리게 되면 둘 중 하나가 깨어지게 된다. 절대 주의!

그리고 결정적인 예외상황이 한가지 존재하는데, return 키 바로 위에 위치하는 \ 키 (백슬래쉬 키) 의 경우에는 무슨 이유에서인지 모르지만, 아래의 첫번째 사진에서 볼 수 있는 X 자 모양의 구조가 90도 회전한 상태로 되어 있어서 다른 키 처럼 윗쪽 면 부터 들어올려서 빼려고 하다가는 비싼 키보드 망치는 수가 있다. (( 사무실의 sh* 님이 백슬래쉬 키를 윗쪽 면 부터 들어올려서 억지로 뺐는데, 다행히도 아래에서 보이는 작은 hindge 가 부러지지는 않았다. 이 분이 찾은 분해법이 나와 있는 사이트에 들어가니 누군가 답글로 백슬래쉬 키는 방향이 90도 돌려져 있다고 달아 두었었는데, 못보고 지나치셨던 모양이다 ㅋㅋㅋ

이렇게 분해를 모두 마친 모습이다 :

이제, 원하는 Dvorak 자판으로 배열해서 끼우기만 하면 된다. 조립은 분해의 역순. 아랫쪽의 홈부터 살짹 맞춰준 후 꾹 눌러 주시면 딸깍 하는 소리 두번과 함께 잘 들어간다.

Dvorak 배열 키보드로 변신한 내 Apple Aluminium Keyboard. ㅎㅎㅎ

이렇게 드보락으로 바꿔 놓고 나니 문제가, 그것도 매우 큰 문제가 하나 생겼다.
양손 집게손가락을 올려놓을 Home Row 에 기준이 되는 표시로 톡 튀어나온 녀석이 (ㄹ 과 ㅓ 위치) 엉뚱한 자리로 가 버렸다는 것인데, 아무래도 스카치 테잎을 몇장 겹쳐서 기준 자리에 붙여 두든지, 밀랍을 녹여서 약간 톡 튀어나오도록 하든지 대책을 강구해야 겠다. 이도저도 마음에 안들면 다시 키 배치를 QWERTY 로 원복해 두는 수밖에 없겠지만...

끝으로 IXUS 80IS 로 찍은 내 방의 조화-_- 사진 하나 올려 본다. ISO 100 무보정

----
2012-04-07 추가: 맥북 에어 키보드 분해법

http://orchistro.tistory.com/241

Dvorak 자판을 쓴지 이제 3일째.
문제가 생겼다.

오전에 시스템 리부팅을 했는데,
gdm 로그인 화면에서 자판이 qwerty 로 되어 있는 것이었다!! ㅠ_ㅠ
패스워드를 한글 단어에 매핑해 놓고 있는지라 영자판이 dvorak 일 때와 qwerty 일 때 패스워드가 달라지게 되는 것이다. 간신히 종이에 패스워드를 적어 가면서 로그인 성공.
혹시 콘솔에서도 그럴까 하는 생각에 콘솔로 전환해 보았다. 아니나 다를까 qwerty 였다.

위의 두 가지 문제를 해결하는 방법.

1. /etc/X11/xorg.conf 에 아래와 같이 XkbLayout 를 dvorak 으로 설정해 주면 gdm 로그인 화면 문제 해결.

  Section "InputDevice"
      Identifier  "Generic Keyboard"
      Driver      "kbd"
      Option      "XkbRules"  "xorg"
      Option      "XkbModel"  "pc105"
      Option      "XkbLayout" "dvorak"
  EndSection

2. /etc/rc.local 에 아래의 내용을 넣어 주면 콘솔에서도 dvorak 레이아웃 사용 OK

/bin/loadkeys dvorak

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


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

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

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


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

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

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




웃기는 문제가 하나 있는데, 한글 입력 모드 두벌식에서는 [ ] ' " / . , < > 등이 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.

32비트 컴퓨터에서

#include <stdio.h> int main(void) { unsigned int a = 1; a <<= 33; printf("0x%08X\n", a); return 0; }
위 코드의 출력값은 얼마일까?

제일 처음 떠오르는 답은 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을 보아도 마찬가지 설명(마스크 아웃한다는)이 나와 있다.

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

C 로 프로그래밍을 하는 사람이라면 거의 모두들 한번쯤 디버깅 메세지를 출력하는 문제에 대해 고민해 보았을 것이라 생각한다.
아마도 빌드 모드가 디버그일 경우에만 매크로가 확장되고, 릴리즈일 경우에는 사라지도록 다음과 같은 매크로를 정의해서 사용했을 것이다 :
#if (DEBUG_MODE) #define DEBUG(x) printf x #else #define DEBUG(x) #endif 그런데 위의 매크로를 쓰면서 불편한 것이 하나 있으니, 바로 다음과 같이 사용할 수 밖에 없다는 것이다 :
if (rc == ERROR) { DEBUG(("error! err code = %d, var = %d\n", errcode, var)); } 그렇다. 치명적인(!!!) 약점이 있으니, 바로 괄호를 두개 써야 한다는 것이다.

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

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

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

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

그러면 위의 첫번째 방법을 사용했을 때 아래와 같은 코드는
DEBUG("ERROR!!! %d, %d", i++, j++); 프리프로세서를 거치고 나면, 디버그 모드에서는
printf("ERROR!!! %d, %d", i++, j++); 디버그 모드가 아니면
(void)("ERROR!!! %d, %d", i++, j++); 로 확장되게 된다.

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

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

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

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