문득 그런 생각이 들었다. 너무 완벽한 것을 요구하는 것일까? 내가 저 경력이었을 때, 나도 그랬을까?하고 생각해 보았지만 나는 그렇지 않았던것 같은데 하면서 내 기준에 맞추어서, 아직 잘 기지도 못하는데 날아보라고 하는 건가 하는 생각이 들었다.
내가 잘하는 것하고 남을 잘 하도록 만드는 것하고는 역시 차이가 많이 난다. 나는 내 맘대로 할 수 있지만 역시 다른 사람을 이끄는 것은 무지 힘들다. 일단 답답하고 어떤 때는 도대체 왜? 하면서 화가난다.
어떻게 하면 서로 윈윈 할 수 있을까?
코칭에 더 관심을 가져보아야 겠다.
10년된 형과 돌도 안지낸 하룻강아지
밑에 보이는 것이 일반적(?)으로 쓰이는 PC용 세벌자판이 인쇄된 기계식 PS/2 방식의 키보드이다.
연록이 묻어난다.
2001년 9월 생이다.
위에 보이는 키보드는 iMac 기본설정으로 딸려오는 블루투스 무선 키보드이다.
콤팩트하고 애플답게 잘 생겼다.
3월 생쯤으로 보인다.
그것 뿐이다.
근데 결국 형을 택했다.
PS/2방식의 키보드를 쓰려면 PS/2 to USB 젠더(콤포지트)가 필요하다. 이것은 이미 가지고 있었다. 연결하고, 알트키와 윈도키를 각각 커맨트키 옵션키에 맵핑하고 키보드 리피트 속도는 느리지만 이걸 쓰고 있다. iMac에서
사실 이놈은 쌍둥이다. 하나는 거실 PC에 쓰이고 있다. 누가 형인지 동생인지 모른다.
이놈은 사실 불구다. 그래서 한동안 중원을 떠나 있었다.
왼쪽 컨트롤키가 문제가 있어서 Ctrl-C, Ctrl-V 신공을 쓸수 없었는데(윈도우), 말하자면 거의 차크라(공력)가 빠진, 즉, 무공을 일은 상태였는데
iMac에 붙여쓰니 애플의 Alt(Command)-C, Alt-V 신공을 쓸 수 있다.
새로 공력을 받고 새로운 무공비급을 익힌 상태라 할까? 가끔 기존에 익혔던 신공과 헤깔리긴 하지만 나름 잘쓰고 있다.
20년도 가주기를 바라면서…
UI 처리 방식은 어디나 비슷하구나
iOS도 UI 처리방식에서는 Win32 랑 비슷하구나…
하긴 Unix/Linux 쪽도 UI 프로그래밍 쪽은 비슷한 구조로 되어 있겠지
주 쓰레드에서 열심히 프로세스 돌리고 있을 때 UI 갱신이 안된다.
작업을 쓰레드도 돌리고 주 쓰레드에서 UI 갱신 작업을 하도록 작성해야 할 듯
iOS 얘는 왜 그냥 될꺼라 생각했을까?
아이폰 시뮬레이터에서 키보드로 세벌식 한글 입력이 정상적으로 안된다. 이중모음 ‘되’, 쌍자음 ‘ㄲ’ 이 입력이 안된다. 아마도 실제 입력처리는 두벌식으로(두벌식만 현재 지원)되고 Mac에서는 세벌식으로 보낸다해도 뭔가 처리방식에서 차이가 이나보다 처리가 안된다.
두벌식은 잘되겠지…
아이폰에서도 세벌식을 지원해줬으면 좋겠다
OCP의 실현 방법중 한가지, 템플릿 특수화
Open-Closed Principle을 만족하기 위한 한가지 방법으로 서로 상속 관계에 있지도 않고 인터페이스도 서로 다른 객체 혹은 클래스 들을 위해 c++ 의 만의 방식으로 템플릿 특수화를 통해 그 해결 방법을 찾을 수 있지않을까?
예를들어, 조금씩 인터페이스가 다른 UI 콘트롤(Widget)을 생각해보자. 물론 일반적으로 콘트롤들은 동일한 클래스를 상속받아 구현될 수 있으므로 이런 상황 자체가 발생하지 않을 수 있지만. 다이얼로그, 커스텀 컨트롤 등 서로 호환되지 않는 활성화 비활성화 메쏘드가 있다고 하자.
이럴 경우, 추상화/합성에 의해 해당 컨트롤 들을 하나의 추상 인터페이스로 각각에 대한 구현 어댑터(혹은 데코레이터)를 만들어, 이 어댑터들을 통해 일괄적으로 요청하는 방법이 있을 수 있다.
템플릿 특수화에 대한 방법을 보자면 동일한 템플릿 function을 만들고 각각의 컨트롤 들에 대해 템플릿 함수 특수화를 통해 기존 코드는 수정하지 않고 새로운 컨트롤이 추가되어도 OCP를 만족하면서 확장이 가능할것으로 보인다.
그러나 이 경우는 컴파일러에 특성을 많이 탈것 같다. 템플릿 함수 특수화를 지원하는 컴파일러에 한해서
프레임워크, 새삼 다시 한번 생각해 보게 된다… 벌써 10년이 넘었는데도 아직까지 변변한 프레임워크가 하나없다. 해왔던 프로젝트가 모두 다르고, 빡빡한 일정, 수시로 변경되는 요구사항 때문이라면 변명이 될까? 이번 프로젝트도 역시 마찬가지로 처음엔 설계부터 잘하려 했으나 여의치 않았고, 프레임워크까지는 아니지만 익숙하지 않은 라이브러리를 사용하는 데 익히는 시간이 걸린다는 것. 그런데 시간이 촉박해서 그렇고, 뭔가 새로 배워야 한다는 부담감. 잘 사용하지 못했다… 그렇다면 프레임워크를 아무리 잘만들어도, 해당 프로젝트에 잘맞는지는 둘째치다라도 익히는데 시간이 걸리고, 즉 배우기 어렵다면 외면 받거나 오용되거나하는 사례가 발생할 가는성이 커진다. 그렇다면 프레임워크는 이해하기 쉽고, 사용이 쉽고, 교육 혹은 전도에도 많은 비중을 둬야 한다는 얘기가 된다. 또한 바꾸어 말하면 접근이 쉽고, 배우기 쉬운 것이 잘만든 프레임워크라 하겠다. 범용적으로 사용할 수 있다거나, 커스터마이징이 쉽게 가능하다거나, 성능이 좋다거나 보다 이것이 먼저 우선이 되야 하지 않을까하는 생각이 문득든다.
