키보드 밑에 수납공간을 마련했다.!!

Under the key

Logitech Cordless Desktop LX 700

• insert키를 위쪽으로 빼고 delete 키를 크게하여 방향키 위에 다섯개의 키만 배치한 점.(내가 맘에 들어하는 키 배열이다.)
• 키보드 하단(스페이스 키 부근)의 키를 큼지막하게 만든 점.

위와 같은 점들이 전과는 다르게 눈에 띈다. MS 키보드를 따라한 것 같다.

키보드 터치감이 노트북 키보드와 비슷하게 푹신하게 만들어져있지만 싸구려 키보드들에서 느낄 수 있는 안 좋은 느낌의 푹신함은 아니어서 대체적으로 만족스럽니다.

디자인도 깔끔하다.

ps) 제 키보드는 아니구요. 아는 사람이 쓰는 키보드 잠깐 눌러보고 글을 썼습니다. -_-;

[update 20050213]

이 키보드 국내에도 이미 나와 있더군요.

아는 사람을 통해 하나 구했습니다.

MS 내부에서 사용한다는 C# Coding Guildelines (via Eric Gunnerson’s C# Compendium)

열자마자 눈에 들어오는 것이… tab 문자는 절대 사용하지 말라는… 들여쓰기를 위해서 스페이스 문자 4개를 쓸것.

왜지?

W3C의 웹 콘텐츠(의) 접근성(을 높이기 위한 제작) 지침 1.0에 기반하여 작성된 듯 보이는 한국 웹 콘텐츠 접근성 지침 버전 1.0이란 것이 한국정보문화진흥원이란 곳에서 발표되었다고(될 것이라고)한다. 또 웹 콘텐츠 접근성 지침을 준수하는지 여부를 검사하고 수정할 수 있게 하는 도구도 개발하고 있다고 한다.

장애인등의 소외계층의 정보통신 접근성 향상을 위해 정부에서도 뭔가 일을 하고 있다는 것도 고무적인 일이다.

인터넷에 잠시 검색을 하였으나 지침에 대해 찾을 수 없어 타이핑하여 올려 본다.

한국 웹 콘텐츠 접근성 지침 버전 1.0

• 텍스트 아닌 콘텐츠(non-text contents)중에서 글로 표현될 수 있는 모든 콘텐츠는 해당 콘텐츠가 가지는 의미나 기능을 동일하게 갖추고 있는 텍스트로도 표시되어 있어야 한다.
• 시간에 따라 변화하는 영상매체는 해당 콘텐츠와 동기 되는 대체 매체를 제공해야 한다.
• 콘텐츠가 제공하는 모든 정보는 생상을 배제하더라도 인지할 수 있도록 구성되어야 한다.
• 이미지 맵 기법이 필요할 경우에는 클라이언트 측 이미지 맵을 사용하거나 서버 측 이미지 맵을 사용할 경우에는 동일한 기능을 하는 텍스토로 구성된 대체 콘텐츠를 제공해야 한다.
• 콘텐츠를 구성하는 플레임의 수는 최소한으로 하며 프레임을 사용할 경우에는 프레임별로 제목을 붙여야 한다.
• 콘텐츠는 스크린의 깜빡거림을 피할 수 있도록 구성되어야 한다.
• 키보드(또는 키보드 인터페이스)만으로도 웹 콘텐츠가 제공하는 모든 기능을 수행할 수 있어야 한다.
• 웹 콘텐츠는 반복적인 네비게이션 링크(repetitive navigation link)를 뛰어넘어 페이지의 핵심 부분으로 직접 이동할 수 있도록 구성하여야 한다.
• 실시간 이벤트나 제한된 시간에 수행하여야 하는 활동 등은 사용자가 시간에 구애받지 않고 읽거나, 상호작용을 하거나 응답할 수 있어야 한다.
• 데이터 테이블은 테이블을 구성하는 데이터 셀의 내용에 대한 정보가 충분히 전달될 수 있어야 한다.
• 콘텐츠의 모양이나 배치는 논리적으로 이해하기 쉽게 구성하여야 한다.
• 온라인 서식을 포함하는 콘텐츠는 서식 작성에 필요한 정보, 서식 구성 요소, 필요한 기능, 작성 후 제출 과정등 서식과 관련한 모든 정보를 제공해야 한다.
• 스크립트, 애플릿 또는 플러그 인(plug-in) 등과 같은 프로그래밍 요소들은 현재의 보조기술의 수준에서 이들 프로그래밍 요소들의 내용을 사용자에게 전달해줄 수 있을 경우에만 사용하여야 한다.
• 콘텐츠가 위 항목을 만족하도록 최대한 노력하였으나 해결되지 않는 부분이 남아있다면 텍스트만의 콘텐츠를 제공하는 웹 페이지(또는 웹 사이트)를 별도로 제공해야 한다.

얼마전 정비소에서 자동차를 수리했다. 다음 그림은 정비소에서 보험사에게 발급한 보험지급청구서의 일부이다.

작업시간에 따라 공임을 계산한다. 작업시간의 단위는 뭔지 모르겠지만 매우 상세히(소수점 아래 두자리까지) 산출하고 있다. 이렇게 산출된 수리비를 보험회사에 청구하면 보험회사는 내역을 손해사정사에게 넘겨 산출된 비용을 조정하여 확정하게 된다.

소프트웨어 개발비 산출도 이런 식이였으면 좋겠다. 대규모 개발 프로젝트는 어떤지 모르겠지만 “알바”라고 얘기하는 작은 규모의 개발일은 시작할때 개발비와 개발 기간을 정한다. 얼마나 걸릴지 일의 양이 얼마나 될지는 누구도 정확히 모르는 상황에서…

요구사항을 듣고 대략의 개발기간과 비용을 고객에게 말해주고 개발이 완료된 후에 “어떤 작업들을 했고 각 작업당 작업시간이 이러니까 비용은 얼마 나왔다” 라고 하면 고객은 필요한 작업을 한 것인지, 가격은 적당한지를 제3자에게 평가받아 가격을 조정, 결정하는 것이 합리적이지 않겠는가. 공인된 기관에서 작업당 표준 작업시간 및 비용은 정해 놓는 것도 필요할 것이고.

비용산출을 이런식으로 하게되면 야근, 휴일 작업에 대해서도 회사에 정당하게 수당을 요구할 수 있을 거다. ㅋㄷ