마이크온블로그닷컴 ::Just Quit your Job!::

진정 사용성이 무엇이라 생각하나요?

(불꽃남자) — Sun, 21 Feb 2010 02:55:23 +0900

오랜만에 사용성에 관한 이야기를 좀 해봐야겠다.

사실, 사용성은 옵션일수밖에 없다.

이 얘기에 욱하는 사람들도 있겠지.. 하지만 이게 현실이다!

사용성이 아무리 뛰어난들 핵심기능이 구현되어 있지 않으면 다 나가리다.

사용성이 아무리 뛰어난들 내가 원하는 기능이 없으면 또 다 나가리다.

사용성이 아무리 뛰어난들 내가 불편하면 그것 또한 나가리다.

그런데 언젠가 부터 사용성은 반드시 필요한 필수! 라고 얘기 하는 사람들이 있다.

물론, 사용성을 개뿔 신경쓰지 않고 개발하는 것보다 사용성을 생각하면서

만드는 것이 당연히 좋겠지만,

그런데,... 음...

뭐랄까?.. 요새 포탈사이트나 기타 어플들에서 내세우는 사용성들이

그게 과연 정말 편해? 라는 생각이 들때가 많다.

쓰다보면 편해야 하는데.. 쓰다보면 불편한 기능들이 있기 때문이다.

이런 생각들의 근간은 사용성이라는 단어에서 풍겨오는 어떤 선입관이라고 해야하나?

그런 편견들이 많이 묻어난다.

사용성이란 도대체 뭘까?

사용자의 행동 패턴에서 반복되는 작업들을 없애면서 뭔가 알아서 자동으로 샤샤샥 해주는 그런 편리함?

그런것을 의미하는 걸까?.. 난 요새 말하는 사용성이 그런것을 의미하는 것같다. 라는 느낌을 자주 받는다.

내가 잘못 이해하는 것일수도 있지만..

하지만 말이다... 위와 같은 의미의 사용성이라면,

때론 불편해도, 그 불편함이 어떤 가치를 지탱해준다면, 기꺼이 사용성은 희생되어도 된다 라고 생각된다.

사용성 보다 중요한 내적(서비스적)가치

More 조엘온 블로그 책을 읽다보면, 거기서도 비슷한 맥락의 내용이 나온다.

여기에 내가 하고 싶은 얘기가 너무나 잘 정리되어 있다. (궁금한 사람은 꼭 보시길..)

조엘온 블로그 사이트 안에는 소프트웨어만을 다루는 토론방이 있다.

여기서는 토론의 가치를 지키기 위해, 일반적으로 우리 생각하는 사용성을 많이 버렸다. (심지어는 검열도 한다.)

대표적인 것이 댓글 알리미 기능, 누군가 쓴글에 피드백을 주면, 메일이나 기타 방법으로 알려주는 기능인데..

이런 알리미가 있을때와 없을때를 비교하면, 당연히 있을때 토론방 방문횟수가 적어진다.

이것은 결국 토론방 활성화에 악영향을 주게 될것이다.

비슷한 예가 하나 더있다.

네이버의 오픈캐스트 발행하기 기능이다.

이미 수많은 블로거들이 발행하는데 무슨 몇시간 걸리냐고 불만을 쏟아냈다.

하지만 여기에 불편한 진실이 숨겨져 있다면???

누구는 캐스트 발행이 너무 불편해서 도저히 못하겠다고, 도대체 누가 할수있겠냐고,.. 얘기하겠지만..

캐스트 노출로 인해 많은 방문자를 유입하는 것에 가치를 두고, 혹은 그것으로 먹고 살 생각이 있다면

발행하기가 지랄맞게 불편하더라도 계속해서 발행을 할것이다.

하지만 일반 사용자들은 그렇치 못할것이다. 왜냐? 그들은 그만큼 할얘기도 없을 뿐더러..

소위.. 개나 소일 확률이 높기 때문이다. (좀 과격했나? ㅋㅋ 그냥 강조의 의미로 받아들이삼.)

서비스적으로 생각하면, 저질 컨텐츠 보다 당연히 양질의 컨텐츠를 생산하는 시스템으로 가는것이 맞다.

뭐 물론 여기에 롱테일의 법칙에 따라서, 그런 시시콜콜 컨텐츠들이 가치가 있다고 생각할수도 있겠지만..

오픈캐스트는 그런 롱테일의 가치를 표방하는 서비스는 분명 아니다.

오히려 그 반대인 파레토 법칙의 가치를 표방한다고 볼수있다.

그렇다면, 그 가치에 맞는 방향으로 디자인(또는 설계) 되어야 한다.

즉, 사용성이 좀 떨어지더라도 응당 그만한 가치가 있다면 그렇게 해야하는 것이다.

사용성! 다시 생각한번 생각해 봐주세요.

이제는 진정 사용성이 무엇인가 다시 한번 곱씹어 볼때도 됐다.

작은 버튼이 단순히 좀더 크게, 좀더 눈에 잘띄게, 좀더 클릭하기 쉽게 만드는 그런 사용성 말고,

진정 이 컨텍스트 안에서 혹은 이 서비스 안에서 요구하는 가치를 진정으로 돋보이게 하는

그런 UI 혹은 UX 를 만들때도 됐다..(그렇치 않나요?)

마지막으로 TV에서 누군가 했던 말로 정리하려한다.

요즘 옛날에 비해 어떤가? 라는 질문에 이렇게 대답했다.

편해지긴 했지만, 좋아지진 않았다.

오늘은 여기까지 이만 끝~!

아이폰 연락처 동기화 (맥을 쓸경우)

(불꽃남자) — Sat, 26 Dec 2009 14:32:30 +0900

며칠전에 아이폰을 지르고, 뒷수습을 하고 있는 중이다.

가장 문제가 되는게 기존 핸드폰에 저장된 연락처를 옮기는 일인데..

아~ 이게 진짜 어뜩케 해야할까? 고민이 한두가지가 아니었다.

검색해보면, 아웃룩이나 구글등을 이용해서 연락처를 싱크하는 방법이 나와있긴한데..

조금 귀찮아서 고민을 좀 하고 있던 차에..

더 좋은 방법을 찾았다.

단, 지금부터 하는 얘기는 맥유저에만 해당한다. (ㅋㅋㅋ 역시 맥~~)

일단 기존 핸드폰을 가지고 있던 사람들은 기존 핸드폰 홈피가서

핸폰에 있는 정보를 PC로 옮겨주는 데이터 싱크 프로그램등을 다운로드 받아야한다.

난 CYON 핸드폰을 썼기 때문에 CYON 홈페이지가서..

데이터 싱크2 거시기 라는 프로그램을 받았다.

그리고, 간단히 내 주소록을 PC로 내보내기 하면 된다.

내보내기 할때는 csv 파일 형태로 내보내자!!

그리고, 맥에서 "주소록"을 열어서 내보낸 csv파일을 읽어들이자!!

그리고, 이제 아이폰을 연결하고 주소록을 싱크하면 끝~!!

아주 간단하다..ㅋㅋㅋ

글로 이해하려나?.. ㅋㅋ

여튼 이렇게 하면 매우 간단함.

아이폰 갈아타기 준비 (SKT와 정떼기)

(불꽃남자) — Wed, 23 Dec 2009 14:26:11 +0900

아이폰으로 갈아탈 맘을 단디 먹고,..SKT와의 10년간의 정을 떼는 방법!!

1. 레인보우 포인트를 모두 써라!
http://www.tworld.co.kr/ 가서 로그인한후,
myTworld -> 멤버쉽/포인트 -> 요금결제

2. 핸드폰 요금을 기타 포인트로 정리하기.
BC 카드를 쓰시는 분은 TOP 포인트나 모아포인트가 있을텐데.. 이걸 가지고 휴대폰 요금 결제 하면 되겠습니다.
방법은 http://www.pointpark.com/ 가셔서 각종 포인트를 통합하고,
간단히 휴대폰 요금 결제 하시면 됩니다.

3. 번호 이동에 대한 대비...
알아보니, 번호 이동을 하더라도 KT에서 다 알아서 기존 번호를 무료로 다 연결시켜준다는군요.
특히 011 번호는 더이상 할당되지 않기 때문에,.. 011 번호를 가지고 있는 저와 같은 사용자는
새로 만든 010 으로도 통화가 되고 011 기존 번호로도 통화가 된다네요..
그러므로 번호이동에 대한 부담은 zero에 가깝다고 함.

4. 각종 할인 혜택..
본인은 SKT와 10년을 같이 해서 받은 혜택이라고는 장기가입혜택 뿐이 없는데..
그 금액이 1000원을 넘어본 적이 없어서.. 사실 이게 혜택인지는 의문이죠..
통화료도 2만원 내외니까..

그외 가맹점 할인이 있는데.. 편의점과 레스토랑은 멤버쉽할인이 비슷하다고 하네요..
하지만 가맹점 갯수는 SKT가 월등히 많다고 하고,.
최근에 KTF 스타벅스 제휴는 끝났다고 하고..
이건 기대하지 말아야 하는건가? -ㅜ..

5. 평소 핸드폰 요금
사실 앞에 4가지보다 더 현실적인것이 매달 지불하는 핸드폰 요금인데..
보통 거의 쓰지 않아서.. 2만원 내외로 나오다가.. 요새는 부쩍 늘어서.. 4만원대까지 치솟았음.
아이폰을 살경우, 분할 납부료 까지 하면, 16GB에 가장싼 요금이 한달에 6만원 대라고 하니..
2만원의 오차는 발생하지만.. 아이폰을 쓰면서 얻게되는 UX에 비하면.. 리즈너블 할것 같음.

6. KT 집전화와 통합.
이건 일단 아이폰을 구매하고 100번으로 전화해서 해결하라고 한다.
아이폰 지르고 난뒤에 정리해서 올려야겠당.

프로젝트는 왜 실패했는가?

(불꽃남자) — Fri, 27 Nov 2009 01:34:41 +0900

개인적으로 여기서 개인적이란 얘기는, 회사일과는 아무런 관련없이..

개인 취미생활을 말하는 거다.

여튼 개인적으로 프로젝트를 진행했었다.

지난 6월쯤이었나? 그때부터 공식적인 마지막 회고 회의인 어제까지 한다면..

장장 5개월간의 프로젝트였다.

그리고 오늘 드디어 마지막 회고 회의를 했다. 물론 멤버는 달랑 둘이었지만..ㅋㅋ

회고의 주제는 "프로젝트는 왜 실패했는가?" 였다.

프로젝트는 왜 실패 했는가?

많은 이유들이 있었지만, 대표적으로 큰줄기를 3가지만 꼽자면,

1. 스펙 간소화 실패

2. 목적의 불명확성

3. 지나치게 많은 새로운 시도

정도가 되겠다.

물론, 프로젝트가 잘 된점도 있었다.

두가지만 꼽는다면,

1. 언제 어디서든 쉽게 설정할수있는 빌드 자동화 (개발환경설정이 쉬웠다.)

2. 다양한 시도의 실패에서 얻은 교훈

정도가 되겠다.

이번 프로젝트가 공식적으로 실패를 하므로써, 사실상 잃은 것 보다는

얻은게 더 많았다는게 최종 결론.

적어도 실패했던 프로세스를 반복하지는 않을 것이라는 것이 가장 큰 이득이 아닐까?

초기 설계에 대한 얘기도 있었고,

취미로 하는 프로젝트이다보니, 회사일이 바쁠때 손을 놓게 되면서 발생하는 컨텍스트 스위칭 비용얘기

그리고 그 비용을 줄이기 위한 리마인드용 문서작업.(확실히 문서작업은 결론이 나지 않았다.)

요즘 읽고 있는 책과, 생활에서 얻은 이러저러한 아이디어 공유

실패 원인 분석과 해결 방안 모색

다음 프로젝트에 해볼만한 것들 등등

비록 짧은 시간이었지만, 생산적인 토론이 아니었나 싶다.

성공을 위한 준비

이번 실패를 밑거름 삼아 다음 시도엔, 성공을 맛보기 위해 준비해야할 것들이 많다.

정리해서 토욜날 발표해야하는데..

오늘은 무리고 당일날 준비해야겠꾼.. ㅋㅋ

다음 시도엔

실서버 배포까지 해봐야겠다.

졸려서 대충 접고,.. 오늘은 자야겠다. 이만 안녕~

괴짜 통계학 - 통계 자료를 볼땐 항상 의심부터 하자

(불꽃남자) — Fri, 13 Nov 2009 15:35:34 +0900

책 내용이 그다지 어렵지도, 내용 자체가 딱딱하지도 않은 책이다.
아주 쉽게 읽힌다. 너무나 당연한 얘기를 반복하고 있어서, 읽다보면 지루하기 까지하다.
그래서 결국 1/6 정도를 남기고 읽기를 멈췄다.
마자 읽어볼 생각이나, 그 나머지에서 건져낼 얘기는 더이상 없는 듯 싶다.

한마디로 이 책은 통계 자료를 볼때, 유심히 속지말고 잘 봐라 하는 내용..

몇가지 건진 것들을 정리하면,
1. 통계자료는 비판적으로 보자 (의심의 눈초리로 보기 시작했다.)
2. % 와 %포인트는 다르다.
3. 같은 그래프도 때에 따라 효과적으로 보이기 위한 전략이 있구나..(결국 속이자는 거지..)
4. 확률 공부를 좀 더 해야겠다.

이상 끝~

루저파문, 그리고 씁슬함

(불꽃남자) — Wed, 11 Nov 2009 23:52:27 +0900

요 며칠전부터 루저발언으로 게시판이 초토화 됐다.

이를 계기로 DC에서는 미수다갤도 생겼다.

미수다는 내가 즐겨보는 프로그램이다.

하지만 이번주는 보지 못했다.

그래서 딱히 내생각은 이렇다 라고 얘기는 못하겠다.

생방을 봤다면, 루저파문이 일기전에 뭔가 느낌이 있었겠지..

불쾌할수도 있고, 저런 개념없는년 이라고 했을수도 있고,

그럴수도 있겠다. 할수도 있고,.. 별 감흥이 없었을수도 있다.

하지만 말이다. 그럼에도 불구하고,..

이딴게 왜 기사화 되고, 문제시 되는지 난 잘 모르겠다.

워낙 가십거리에 관심이 없어서 그런것일수도 있고..

어쩌면 미수다를 직접 보지 못해서 그런것일수도 있다.

2PM의 재범이처럼, 그 발언을 한 여대생이 맘고생을 좀 안했음 좋겠다.

수준낮은 기사들을 경쟁적으로 쏟아내는 신문사나 언론도 문제지만,

그렇다고 그들을 욕할 생각은 없다.

결국 인터넷이 정보 유통의 중심이 되면서

나은 부작용이 아닌가 싶다.

그래서 씁슬하다.

덧붙이는 말이 더 있었는데.. 사족같아서..

오늘은 그냥 씁슬함으로 마무리..

여러 글쓰기 도구 중에 무엇을 주로 쓰시나요?

(불꽃남자) — Tue, 15 Sep 2009 02:45:47 +0900

글쓰기 도구 라고 하면,

내 머리속에서 가장 먼저 떠오르는건 아무래도 요 블로그가 아닌가 싶다.

글쓰기 도구

1. 블로그
2. 게시판 (제로보드, 그누보드,... )
3. 한줄 블로그 (미투데이, 트위터,... )
4. 위키 (미디어 위키, 모니 위키)
5. 스프링 노트
6. 미니홈피

위에서 스프링 노트를 위키의 범주에 넣을 수도 있지만, 용도나 모양새, 쓰임새를 보면,..

위키랑은 확실히 다른 느낌이 들어 개인적으로 다른 분류로 넣었다.

이 외에도 많은 글쓰기 도구들이 있을지언데.. 많나? 아닐수도 있고,

내가 아는 혹은 내가 쓰는 글쓰기 도구는 위와 같다.

그 중에서 최근 가장 많이 쓰고, 가장 손에 익은 도구는 블로그와 미투데이 그리고 위키다

위키 중에서도 지라 위키를 가장 많이 쓰다보니, 가장 익숙한듯 싶다.

그래도 모니 위키나 트랙의 위키도 점차 익숙해져가고 있다. 뭐 위키가 다 거기서 거기다 보니..

화려한 글쓰기와 단순한 글쓰기

개인적으로 글이란, 형식보다는 내용이 중요하다고 생각한다.

그러하기 때문에 많은 기능과 화려한 폰트를 자랑하는 에디터 보다는

그냥 기본 에디터, 혹은 달랑 텍스트만 쓸수 있는 노트패드와 같은 심플한 에디터를 선호한다.

하지만 분명 나와 다른 글쓰기 행태를 보이는 사람들도 많을 것 같다.

예쁜 폰트를 좋아하고, 이모티콘을 좋아하고, 형형색색의 글들과 움직이는 애니메이션을 글속에 채우고,

뭐 이런 것을 중요하게 생각하는 사람들도 분명히 주변에 많이 보인다.

둘중에 "무엇이 더 좋다. 우월하다" 라고는 이야기 할수 없지만, 확실한건 난 단순한 글쓰기를 선호한다.

단순한 글쓰기를 선호하는 까닭 (요 며칠전 부터 이유를 까닭으로 적고 있다. 여튼... ㅋㅋ)

1. 폰트가 화려한 글과 형형색색 글들은 익숙하지 않은 나같은 사람에게는 가독성을 해친다.

2. 글쓸때, 폰트와 글색, 글자크기 등을 신경쓰고 싶지 않다. 귀찮다. 가끔 강조를 위한 볼드나 소제목을 애용한다.

3. 글씨보다는 글의 내용이 난 더 중요하다. (가끔씩 제목에 낚이는 글을 보고 분노할줄 안다.)

4. 난 개성있게 니가 쓴 글씨도 좋지만, 난 니가 하고자 하는 얘기에 더 관심이 많다.

5. 그냥 깜장색이 안정감이 있다.

6. 습관적으로 이것이 익숙하다.

그래서 가끔은 생각한다.

스마트 에디터가 과연 필요한가?

여기서 지칭하는 스마트 에디터는 NHN에서 제공하는 오픈소스 에디터가 아니라,
일반적인 다기능 에디터를 말하는 것이다.

필요할까? 필요는 하겠지만, 반드시 필요한 것은 아니라고 생각한다.
물론 텍스트 에이리어만 가지고는 불충분하다.

이런 기능이 포함된 심플한 에디터는 어떨까?

1. 난 미투데이의 북마클릿을 거는 방법을 좋아한다. 따옴표(") 두개와 콜론(:) 하나와 공백( ) 하나면 쉽게 링크가 걸린다. 따로 상단 UI에 있는 링크 걸기 이미지를 클릭하지 않아도 된다.

2. 자동 태그도 [[태그]] 이렇게 각괄호 두개를 해주면, 그냥 태그로 인식해주면 좋은데..
물론 각괄호 2개를 넣어 표현하고 싶은 사람도 있겠지.. 하지만 얼마나 될까?
그러면, 개발자 답게 \[\[ 요렇게 \]\] 쓰면 되지 싶다. ㅋㅋㅋ (과연 사용자들이 수긍할수있을까?)

3. 굵은 글씨와 취소선, 밑줄, 기울임 글씨는 모두 단축키를 지원한다.
컬러도 단축키를 지원해준다.

4. 문단은 들여쓰기와 싱글바 별표등을 이용해 위키 처럼 쓰면 자동으로 변환해주면 좋겠다.

그 이외는 필요없다.
딱 저렇게만 해주면 좋지싶다.

여러분은 어떤가요?

무엇을 어떻게 쓸까?

(불꽃남자) — Sun, 13 Sep 2009 09:12:07 +0900

간만에 독후감 하나 쓴다.

먼저 책 표지부터 하나 박아주시고..

이 책은 내가 요즘 블로그에 자주 글을 못쓰는 까닭을 아주 명확하게 얘기해 주고 있다.

그것은 내가 바빠서 그런것도 아니요.

글 쓰는데 시간이 오래 걸려서도 아니다.

그것은 다름아니라 내가 쓸 말이 없기 때문이다. 아하하하..

생각해보니 정답이었다.

글을 참 잘쓰고 싶은 욕심은 있는데, 쓸꺼리도 없으면서 자꾸 욕심만 많아서..

무엇을 쓰지? 무엇을 쓰지? 궁리만 많이 했던것 같다.

결국엔 쓸꺼리도 없으면서, 자꾸 어떻게 꾸며 쓸지를 고민하게 되니 당연히 글이 잘 안써지는 것이었다.

이런 나의 글쓰기 행태는 이 책의 표현을 빌리자면, 그야말로 병신짓 꺼리고 그딴식으로는 글을 쓰지 말아야 한다

이 책을 읽으면서 난 엄청 혼꾸녕이 났다. ㅇㅎㅎ

40여년 한길을 걷으신 선생님의 뚜렷한 주관이 곳곳에 묻어났다. (역시 달인~ )

지금도 이 글을 쓰면서도, 왠지 조목조목 요 대목이 틀려서 이건 이렇게 해야한다.

라고 지적을 받을 것만 같다.

그래도 괜찮다. 일단 지금 이글은 적어도 꾸며낸 이야기가 아니라.

내가 읽고 느낌 글을 쓰는 까닭에 거짓글도 아니고 꾸밈글도 아니다.

글쓰기에서 가장 중요한 것은 입말을 써야한다고 이책은 말하고 있다.

입말이란, 현재 우리가 쓰고 있는 말이다.

즉, 책에서 말하는 문어체도 아니고, 일반적으로 잘 쓰지 않는 말도 아니고, 고지식한 말도 아닌,..

생활에서 우리가 입밖으로 내어 표현하는 그런 말을 가지고 글을 써야 한다는 것이다.

그리고, 책상머리에 안자서 상상한 이야기보다, 내가 경험한 이야기를 중심으로 쓰라고 권장하고 있다.

그래야 쓸꺼리가 명확해지고, 가타부타 표현에 가식이 섞이지 않게 되어,

읽는 사람 또한 글을 쉽게 받아들인다고 한다.

그동안 내가 읽었던 논문들이 왜 이렇게 어렵지? 했던 질문들도 그 까닭이 명확해졌다.

그리고 내가 쓴 쓰레기 논문이 참으로 부끄러웠다. 그리고 그 논문을 받아들인 그 학회는 참 안습이다.

(그런데 안습이다. 라는 표현은 쓰지 말아야 한다. ㅎㅎㅎ 그냥 안타깝다 라고 쓰면 된다.)

그리고 잘 읽혀지지 않았던 번역서들도 그 까닭이 명확해졌다.

제발 번역가들아~ 읽는 사람이 알아먹기 쉽게 우리 입말로 좀 써주면 안되냐?

특히, IT 전공서적..-_- 은 번역한 이의 이름을 꼭 확인해봐야 한다는 것을 새삼 깨달았다.

여하튼간에 이책은 청소년을 위한 글쓰기 책이었지만,

누구나 한번쯤은 꼭 읽어봄직하다. 강력추천한다!!

책을 빌려준 승렬에게 다시한번 땡큐~

제목과 전혀 관계 없는 글...

(불꽃남자) — Wed, 12 Aug 2009 21:55:17 +0900

요즘 미투질 하느라.. 내 블로그임에도 불구하고 오랜만에 방문하는 것 같다.
진짜 요샌 블로그 이렇게 하다간 걍 버리지 싶다.

부지런히 쓰고 싶은데,.. 여유를 찾지 못했다.

먼가 여유가 생기면 바로 일이 치고 들어온다.

각설하고..

오늘의 주제는 Humane Interface 라는 책에서도 언급되었던 내용인데,

본문 내용과 다른 제목

에 대해서다. 혹시, 블로그나 일기를 쓰다가 제목을 무엇으로 할까? 고민을 해본적이 있나?

난 무지하게 많다.

항상 제목이 내용보다 먼저 있기에,.. 제목을 정하고, 글을 쓰다보면,
제목과는 관련 없는 이야기가 되곤한다.
그리고 가끔은 고민도 한다. 무슨 제목으로 하지?
그리고 가끔은 내용이 없는 제목을 쓰기도 한다. (냉무) 이러면서..

아~ 이젠 제목 정하는것도 귀찮아져 버렸다.

낚시글이 많은 게시판

게시판 형태로 목록이 보이는 UI에서는 제목만을 보고, 원하는 글을 찾기에 참으로 유용했다.
하지만, 이제 제목은 더이상 유용하지 않다. (너무나 극단적인가? )
사실 여전히 유용한데.. 제목에 의해 낚이는 경우가 너무나 많아졌다.

특히나, 헤드라인기사,...(네이버의 뉴스캐스트 아주 가관이지...)

뭐 요즘엔 그것뿐인가? 자주 가는 게시판을 봐도 널렸다. 아주..그냥..
더이상 제목만 보고, 내용을 판단해버리는 우둔한 사람은 없지 않을까?

똑똑하고 빠른 검색엔진

그리 오래되지도 않았다. 검색 엔진이라는 놈들이 등장하면서 부터,

인터넷의 이용 형태는 뚜렷한 패러다임(?)의 전환이 이루어져왔다.

기억하는가? 디렉토리 서비스를 제공하는 야후

난 아마 1997년 처음 도서관에서 야후엘 접속했던것 같다..

1992년 내가 처음 컴퓨터를 사고, 1993년 처음 하이텔을 접속했던 그시절이 고작

지금으로부터 15년전쯔음의 일이다.

여튼간이 이런 빠른 변화속에 검색엔진의 등장은..

나로 하여금 더더욱 제목의 필요성에 물음표를 던지게 한다.

이젠 태그만 달아도 될꺼같다.

굳이 제목이 필요할까?
이 글도 마찬가지...

요새 내가 즐겨쓰는 미투데이는 딱! 내가 하고자 하는 얘기와 맞물린다.

트위터도 마찬가지..(개인적으로 트위터는 어렵다 @.@ 영어라서 그런가?..)

쓰여지는 글들이 많을수록,... 지난간 내글들의 향수를 느끼기 위해, 처음부터 하나둘 다시 읽는 경우도 있고,

가끔은 내가 쓴 내글을 내가 검색해서 볼때도 있다.

절대로 제목을 보고 찾는 경우가 없다.

물론 찾는 경우라면, 한번 검색한 이후.. 제목을 보는거다.

이런경우는 어떨까?

제목은 없고. 내용만 있는글..

제목은 특별히 없어도 되겠다. 그냥 글의 서두 20여자를 걍 제목으로써 보여주면 되지 않나 하는거다..

UI에 따라서 가변적으로, 제목으로 표현되는 글자수를 조절할수도 있겠다.

마치 본문 요약형 미리보기 정도쯤 되지 않을까 하는데..

그래서,.. 결론은 하나 만들어보고있다.

태그 기반의 제목이 없는 게시판..

프로젝트 기반이 갖춰지면.. 오픈소스로 갈아탈 예정이다.

커밍순~!

IE에서 innerHTML 사용시 주의해야할 점

(불꽃남자) — Sun, 26 Jul 2009 14:39:00 +0900

일단, 발행하기 전에 정리부터 하자..
예제는 나중에 정리하고.. 생각나는대로 써보면,..
대충 정리해보면 아래와 같다.

1. DOM 노드 캐싱
DOM을 캐싱할때는,.. 캐싱하려는 노드를 cloneNode(true)로 떠서 캐시하자..
그렇치 않으면, IE에서는 innerHTML로 해당 노드를 날렸을때,. 캐시한 노드까지 날라간다.
반면, IE외의 다른 브라우저에서는 innerHTML로 해당 노드를 날렸을때..
해당 노드만 날라가고, 캐시한 노드는 그대로 있다.
[하나 더 주의] - cloneNode를 할 경우, 바인딩된 이벤트는 복사되지 않는다.!

2. 메모리 누수
모든 브라우저가 innerHTML로 엘리먼트를 교체하면, 엘리먼트가 걸려있는 이벤트 핸들러들이
날아가 버린다. 보다 정확한 의미는 참조를 잃어버린다!!
때문에 참조를 잃어버린 이벤트 핸들러들은 영영 해제할 길이 없어 메모리 누수가 생긴다.

따라서, 엘리먼트 교체를 해야할 경우엔, 이벤트 핸들러를 먼저 제거해주거나..
앞에서 얘기한 노드를 캐싱하거나..
아니면, HTML로 날릴만한 엘리먼트엔 이벤트 핸들러를 걸지말고, 그 상위 노드에 걸어서
버블링 처리를 해라~!!

3. HTML 렌더링
HTML을 innerHTML로 재할당을 할경우, 브라우저는 재할당한 부분만 랜더링을 다시하게 된다.
이때, 구식브라우저(꼬진브라우저, 느린브라우저)인 IE6에서는 랜더링 할때, 생각보다 속도가 느리다.
그래서 아래와 같이 사용하게 되면,..

node.innerHTML = "<div>....중간생략 복잡한 디비전 태그 교체...</div>"
doSomethingHere();

doSomethingHere() 함수 안에서 새로 랜더링 되는 엘리먼트의 width나 height 등을 가지고 뭔 짓꺼리를 하게 되면,
IE6에서는 htmlfile 에러는 내뱉는다.

이유는 앞서 설명했듯이 랜더링 속도가 느려서 발생하는 문제로...
로드 된후, 실행시 까지 약간의 딜레이를 주거나,
인터벌울 돌려서 렌더링이 됐는지 체크를 한다.

난 걍 랜더링시 문제가 될경우에 한에서만 이렇게 쓴다.

el.innerHTML = sTpl;
var oInstance = this;
setTimeout(function(){
oInstance._initialize();
}, 100);

4. htmlfile 에러
그밖에 IE6혹은 IE7에서 htmlfile 에러가 발생하는 경우가 있는데 아래와 같은 경우가 있다.

붙이려는 노드가 읽기 전용 속성의 태그이고, 거기에 ID 값을 부여해서 innerHTML 할 경우
** IE에서 COL COLGROUP FRAMESET HTML STYLE TABLE TBODY TFOOT THEAD TITLE TR 개체등은 ID 필드가 읽기전용 속성이고 그 외의 개체에서는 모두 읽기/쓰기가 된다.
기본 HTML 구조 규칙을 깨는 경우,
예를 들면, LI 엘리먼트 하위에 다시 LI 노드를 자식으로 넣는 경우가 있겠다.
이 경우는 실제로 겪었던 부분으로, li 자식 노드로 li를 넣는 바보같은 짓을 범했다. 이런 경우가 흔하지 않는 경우인데, 안타까운건 FF 에서는 li 하위에 li 를 짚어 넣어도 아무런 에러를 발생시키지 않는 다는 것이다.

5. FireBug를 믿지마라!
보통 FireFox의 플러그인 인 firebug 를 이용해서 디버깅을 하게되는데, FF 는 너무나 관대(?)해서,
IE에서 뱉는 에러를 몇몇가지를 그냥 쌩까고 혹은 아~ 이건 개발자 실수니까,..스마트(?) 하게 알아서 정정해준다.
즉, FF만 믿고 개발했다가는 IE 호환성에 적신호를 받게 될것이다.
그렇다고, firebug 가 구리다는건 아니고, 간간히 중간중간 때때로, 생각날때, IE 브라우저로 테스트를 해보는 습관을 갖는게 좋겠다.

추천하는 바는 그냥 IE6 브라우저를 버리고 갔으면 한다. (그냥 개인적인 바램~ OTL... ㅜㅜ )
하지만 현실은 시궁창... ㅎㅎ

소프트웨어 크리에이티비티 2.0

(불꽃남자) — Fri, 24 Jul 2009 01:27:00 +0900

참으로 오랜만에 글을쓴다. 아마도 이번달의 첫글이지 싶다.

그동안 게을렀던건 아니고,.. 그냥 바빴다.

요새 내가 글을 쓰지 못하는 이유는 2가지다.

첫째는, 바쁘다.

둘째는, 글이 잘 안써진다.

여튼, 오늘은 바쁜와중에 틈틈히 출퇴근시간에 읽어 재낀 책을 하나 소개 하려한다.

제목은 위에 이미 썼고, 부록빼고 약 430여 페이지 분량의 두께를 자랑하는 책이다.

읽는데 걸린시간은 대략 2주 정도 걸린듯 싶다.

책을 읽으면서 밑줄을 치고 메모를 해야하는데.. 하는 문구들이 엄청나게 많았다.

그만큼 읽으면서 공감을 많이 했다.

과연 소프트웨어개발에서 창의력이 필요할까?

위 질문은 책에서 나왔던 질문중에 하나고,..

내가 요즘에 든 생각중에 하나는

프로세스가 점점 안정화 되어가면서, 나는 점점 재미를 잃어간다는 것이다.

잘 갖춰진 공장의 프로세스처럼, 생산라인의 하나의 부품처럼,..

그냥 조이고 닦고, 또 조이고 닦고,.. 생각없이 조이고 닦고,..

그러면 뚝딱... 상품이 하나 나온다. 이게 재밌나?

난 재미가 없다.

얼마전에도 팀원들에게 푸념섞인듯이 이런말을 했다.

"요즘 코딩이 재미없어졌어"

테스트코드를 한창 짤때도 그랬다.

"코딩이 재미없어"

이런 생각들이 내 머릿속을 가득메우고 있을때,

이책에서는 창의성에 대한 다양한 연구들을 소개한다.

테스트코드는 유용하지만, 많이 짤수록 지겨워진다는 연구결과도 있었다...(딱 나다..-_-)

너무나 많은 연구들이 소개되어 있어서..

일일이 다 열거하기도 힘들다.

결론은 이거다..

현재까지 소프트웨어의 생산성을 높이기 위해, (물론 품질도 포함된 얘기다)

프로세스를 강조하고, 정형화하고, 문서화 하고, 또는 자동화 하고

그런 과정들이 굉장히 중요시 되어 왔다.

그리고 이런 풍토는 그 반대점에 있는 개인의 직관이라든가 창의성 자율성들을 제약하고,

상향식이 아닌 하향식(위에서부터 밑으로 지시가 내려오는 것) 구조가 되는데..

점점 소프트웨어의 복잡도가 높아짐에 따라서, 이런 구조의 생산성이 생각보다 높아지지 않는다라는것..

그래서 이제는 상대적으로 지양되었던 개인의 창의성과 경험 또는 직관들도 필요하고,

이것이야 말고, 정형화된 프로세스만큼 혹은 그 이상 중요해 졌다 라는 얘기다!

그리고 난 여기에 굉장한 공감을 표하는 바이다~!!

소프트웨어의 복잡도가 높아지면, 높아질수록, 정형화된 프로세스와 맞지 않는

예외사항이 너무나 많이 발생한다.

또는 개뿔 그동안의 방법들이 아예 안통하는 경우도 많다.

Spring Framework 에서 UTF-8 한글 설정

(불꽃남자) — Sun, 14 Jun 2009 23:58:57 +0900

인코딩 문제로 오늘 또 하루종일 씨름했다.

사실 그닥 어려운게 아닌데.. 처음 설정을 잘못해놓으면,.

고생하기 쉽상이다.

웹개발에서 인코딩과 관련해서 신경써야할 부분

아래와 같은 3가지라고 보면 되겠다.

1. 클라이언트 (javascript)

2. 서버 (apache or tomcat 설정)

3. DB

1. DB 캐릭터셋 설정하기

그중에서 가장 실수하기 쉬운 것중에 하나는 DB 설정.

mysql 을 설치하고, 꼭 아래와 같은 명령어로 현재 mysql 의 설정 상태를 확인해야한다.

mysql> \s

mysql 을 설치할대, 기본 캐릭터셋이 latin1 으로 설정되어 있기때문에

신경써서 설치하지 않으면, 원하는 utf8 설정이 안된다.

설정이 제대로 안되어 있다면, 설치 폴더로 가서 my.ini 파일을 열어

인코딩 관련 부분을 모두 수정해줘야한다.

여기서 그렇게 했는데도 불구하고, \s 명령어를 이용해, mysql 설정상태를 확인 했을때,

DB character set 이 latin1 로 나오는 경우가 있는데..

이런 경우는, create database로 db를 생성할 당시의 캐릭터 셋이 latin1이 었기 때문에

뒤늦게 수정해봐야 수정되지 않는다. 결국엔 db를 날리고 다시 생성해야한다.

이런 경우 때문에 초기 설치시에 주의해서 원하는 캐릭터셋으로 설정을 해야한다.

2. 스프링 프레임웍에서 설정하기

두번째로 서버 설정을 확인해야하는데.. tomcat에서 server.xml 을 열어서 8080포트와 8009번 포트의
커넥터에 URIEncoding="UTF-8" 를 추가해준다.
스프링 프레임웍을 이용할경우, web.xml 열어서 아래와 같은 필터를 추가해준다.
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
그리고 xxxx-servlet.xml 파일을 열어서, viewResolver를 아래와 같이 또 수정해준다.
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">

<property name="prefix" value="/WEB-INF/view/"/>

<property name="suffix" value=".jsp" />

<property name="contentType" value="text/html; charset=UTF-8"/>

</bean>
이렇게 해주면, 기본적으로 클라이언트딴에서 특별한 인코딩을 수행하지 않아도 UTF8로 인식을 한다.
때문에 응답할때도 특별한 디코딩을 해주지 않아도 된다.

참고한 링크 : Spring framework에서 UTF-8 설정

3. 서버 설정없이 클라이언트에서 무조건 UTF-8로 넘겨주기

위와 같이 서버딴에서 특별한 설정을 해주지 않았다면,
다소 귀찮은 작업을 해줘야하는데..
그것은 클라이언트에서 서버로 정보를 날릴때, 무조건 인코딩을 해서 넘겨야 한다는 것이다.

인코딩하는 방법은 간단하다.
아래와 같이 자바스크립트를 이용해, 넘기고자 하는 정보를 encodeURIComponent()
함수를 이용해 인코딩 해주면, 넘기는 정보를 UTF-8로 인코딩해서 넘기게 된다.

4. 인코딩 파헤치기

보통은 클라이언트에서 서버로 요청 파라메터 정보를 넘기게 되면,
아래와 같은 3가지 인코딩 방식으로 넘기게 된다. 아래 1번을 제외한 나머지 방법은
브라우저가 설정된 인코딩 방식을 따르게 된다. 1번방법은 자바스크립트에서 강제로 인코딩한다.
예를 들어 "한글"이란 문자열을 넘기면,
1. encodeURIComponent() 로 인코딩 할때, "%25ED%2595%259C%25EA%25B8%2580"
2. UTF8 인코딩을 할때, "%ED%95%9C%EA%B8%80"
3. EUC-KR로 넘길 때, "%C7%D1%B1%DB"

위 3가지 타입을 UTF8로 설정된 서블릿에서 각각 request.getParameter() 로 넘겨받은 정보를 읽어오게 되면,
UTF8로 디코딩 되어 각각
1. "%ED%95%9C%EA%B8%80"
2. "한글"
3. "???"
로 읽혀오게 된다.
여기서 문제는 3번이 문제가 된다. 3번은 실제로 "한글"이란 정보를 EUC-KR로 인코딩해서 넘기게 되는데..
서블릿에서 UTF-8로 디코딩을 하게 되어 알수없는 값이 되어버린다.

그리고 서버에서 이것을 다시 UTF8 캐릭터셋으로 설정된 DB에 그대로 저장하면,. 각각
1. "%ED%95%9C%EA%B8%80"
2. "?쒓?"
3. "ㅁ싼깍옙"
로 다시 저장된다.
1번을 제외한 2,3번 방식으로 DB에 저장이 되면, 본래 기대했던 값들과 다른 값들로 저장이 되는데..
DB 정보를 서블릿에서 다시 읽어볼때, 같은 UTF8로 디코딩을 하게 되면 사실 큰문제 없다.
하지만 위 DB정보를 다른 캐릭터셋으로 설정된 서블릿에서 읽어오게 되면 이식성에 문제가 생긴다.
또한 DB 캐릭터 셋이 UTF8이 아닌 다른 캐릭터셋으로 설정이 되었다면, DB에 저장될때 마찬가지로
문제가 생길수있다.

때문에 UTF8로 다국어를 지원해야하는 특별한 상황이라면, 1번 방법을 사용하는것이 보다 안전하다.
하지만 보통 하나의 캐릭터셋만을 지원하거나 통일하기 때문에 2번 방식으로 대부분 커버가 가능하다.

사실 더 중요한 것은, 인코딩과 디코딩할때,
클라이언트(브라우저인코딩) - 서버 - DB
3박자를 모두 잘 맞춰서 해줘야 한다는 것이다.

이상 정리 끝~

XP와 사용자 스토리

(불꽃남자) — Wed, 06 May 2009 23:47:36 +0900

오늘은 플래닝 포커 카드에 눈이 멀어, 그 동안 전혀 쓸려고 노력해보지도 않았던,..

서평을 써보려고 한다. ㅇㅎㅎ

아마도 작년 2월 말쯤으로 기억한다.

인턴을 시작하면서, 내게 주어진 마지막 미션이 바로 XP와 무지무지 관련이 깊었다.

미션의 의도가 XP였는지는 사실 모르겠지만, 그 미션을 난 XP로 풀어보려고 했다.

사실 인턴을 하기 전부터 개발방법론에 심취해 있었는데..

eXtreme Programming 이라는 책을 접하게 되면서,.. 아하.. 이 XP(A)가 그 XP(B)였구나..

하는것을 깨닭았다. 여기서 그 XP(B)란,.. 2005년 중반으로 거슬러 올라가야한다.

내가 처음 XP 란 단어를 본 것은,.. 학교 소모임 연구실이었다.

복학하신 선배가 들고 다니던, 두꺼운 영어 원서.. 제목은 뚜렸이 기억난다.. XP!!

그 당시,.. "어랏 왜 저 선배가 윈도우즈 XP 를 공부하지? 그런거 공부 안해도 될텐데..."

라는 나름 순수한 상상~ ㅋㅋ

그리고 그 이후, 2006년 여름쯤,..

복학하고 나서, 친구들과 학교 과제 프로젝트를 진행중이었다.

당시에 소모임 연구실에서 4일밤을 지새우며 코딩을 했는데..

친구랑 둘이 안자 코드를 같이 짰다. 같은 코드를 보면서, 서로 의논해 가면서..

이후,.. 이런 짓꺼리들이 XP에서 말하는 짝 프로그래밍 이라는 사실을 알고,..

오호라! 했다.

그렇다. 사실 나도 모르게.. 어느정도는 애자일 개발방법론을 스스로 체득해서 쓰고 있었으며,..

자연스럽게 다가왔다.. 중복작업 싫어하고, 시간에 쫒기다 보니 프로젝트에 있어서 효율을 항상 생각해야하고..

필요없는 것들은 정말이지 더이상 만들고 싶지 않았을 뿐이고,. 그러면서 의사소통이 중요함을 알게되고..

그런데,..

이러저런 단편적인 경험들이 XP라는 저 책 한권으로 시원스레 설명해주고 있는것이 아닌가? ㅇㅎㅎ

바로 그런 책이다.. 보는 순간 아하~ 그렇쿠나.. 하는 사람들은 보통 나와 비슷한 경험을 해보지 안았을까?

추측해본다..

그러면서,.. 인턴중에 한권의 책을 더 샀다..

바로 사용자 스토리(User Story)라는 책이다.

이것도 너무나 재미있게 보면서,.. 아~ 근데 이건 현실과는 좀 동떨어진 이야기라고 많이 생각했다.

왜냐면,.. 내게 고객 혹은 사용자라는 단어가 참으로 어색하게 느껴졌기 때문이다.

그동안 내가 만들어온 프로그램에서 사용자는 없었다.

이거 참 아이러니하다.. 정말 대학 4년동안 수많은 프로그램을 찍어내다시피 만들었는데..

그 속에는 사용자가 없었던 것이다.

사용자가 없다! 라는 말로, 딱 정리 할수는 없었지만..

졸업할 무렵쯤에,.. 스스로 이런 생각을 한적이 있다..

"코딩이 지겹다... 고생해서 만들었는데,.. 나도 안쓴다.."

"내가 만든 게임은 재미없다.. 근데 왜 만든거지?"

이런 생각들이 떠오르면서.. 이런 결심을 했다!

"이젠 나조차 쓰지 않는 쓰레기 프로그램은 더이상 만들고 싶지 않다!"

그런데 사용자 스토리엔 사용자만 있다.

모든 것은 고객이라는 사용자로부터 시작된다. 라는 것을 크게 깨우쳐 주는 책이었다.

그래서 한번쯤은 읽어보시라 추천을 해본다.

근데,.. 비싸다.. ㅇㅎㅎ 볼사람은 얘기하삼.. 내가 빌려주껭~ ㅋ

PS... 잿밥에 눈이 멀어, 글을 쓰기 시작했다만,.. 할얘기가 참 많네..

좀더 정리할 필요가 있다... 나중에...

체크해놔야징...

BDLayer 새버전 릴리즈!

(불꽃남자) — Tue, 05 May 2009 01:34:39 +0900

우리팀에서 나름 유용하게 사용했던 BDLayer (내이름 이니셜을 붙였다..ㅋㅋㅋ)

작년말에 저거 만들때, 나름 설계에 고민을 많이 했는데..

구조상의 결함과 고치기 힘든 버그때문에..

결국 오늘 새버전을 만들어 버렸다.

나름 그동안 구상해왔던, 설계로 작성했고,..

"최대한 불필요한 함수들은 노출하지 말자" 라는 기본 원칙을 세웠는데..

나름 잘 지켜진것 같다. 코드가 아주 심플해졌네~ ^^

그리고 아직 크로스 브라우징 테스트는 하지 못했다.

(Mac버전 FF3, Safari, Opera 만 테스트 했음)

이번 코드는 시작부터 JSSpec을 적극 활용해서 진행했다.

역시나 서비스코드보다는 훨씬 적용하기가 수월했다.

AutoHide 플러그인에 잡기 힘든 버그도 잡아서 속이 다 시원하다.

역시나, 타이머는 디버깅이 힘들다..ㅇㅎㅎ

만들면서 느낀 것,..

역시 자바스크립트는 프레임웍(프로토타입,제이쿼리,진도 등등)을 이용해 클래스를 흉내내는것보다.

그냥 자바스크립트 본연의 모습이 보다 깔끔한 것 같다.

향후 계획은

1. 일단 크로스 브라우징 테스트부터 하고,

2. 모달 플러그인까지만 추가할 계획.

3. 그리고 SSR 프로젝트에 적용할 예정!

이번 연휴 계획 3개중 벌써 한개를 해치웠군..

이제 남은건 Processing.js 와 Spring 만 남은건가?

내일은 어린이날이니까, 로스트 보면서 하루 쉬어야징..

어느날 갑자기 피들러(Fiddler)가 느려졌을때, 해결방법

(불꽃남자) — Wed, 29 Apr 2009 12:48:09 +0900

웹개발자나 UI 개발자에게 없어서는 알될 툴중에 하나가 바로,..
HTTP 모니터링툴일것이다.

대표적으로 HttpWatch 와 Fiddler 라는 Http Debugging Tool 이 있다.

두개 모두 내가 유용하게 쓰고 있는 툴인데,..
그중에서 피들러가 어느날 갑자기 너무 느려졌다..
피들러를 열고, 웹페이지 하나 열라치면,.. 몇 십초나 걸린다.-_-;..

도대체 뭐가 문제인거야? 한참을 고민하다.. 에라이~ 모르겠다..
접어두고, 그냥 불편한대로 다른 방법을 이용했는데..
그런데, 이젠 더이상 안되겠다 싶어...
Fiddler 관련 메일링 리스트를 뒤졌다..

역시 찾으니까 금방 나온다..-_-;..
인터넷옵션 - 연결 - LAN 설정에서 자동 구성의 체크박스를 모두 해제해두면 그걸로 끝!

다시 피들러가 제속도를 찾을것이다.

그래도 안된다고?.. 그럼 나도몰라!! ㅋㅋ

영춘권의 고수 엽문 - 보면 배우고 싶어진다!

(불꽃남자) — Mon, 20 Apr 2009 00:31:35 +0900

머리 좀 식힐겸, 간만에 극장을 찾았다.

일단, 평가부터 해보면, 볼만하다에 점수를 아주 후하게 준다.

개인적으로 무협영화 좋아라하는데, 이건 무협이라고 하긴 좋그렇고,

실화를 바탕으로 한 영화라서,... 역사+뻥20% 가미된 영화라고 보면 되겠다.

여튼 쿵푸라 불리는 영춘권, 이게 뭐지? 라고 하는 사람도 있을줄로 안다.

얼마전에 케이블에서 영춘권에 대한 무술다큐 같은 걸 한적이 있었다.

외국인이 나와서 각지를 돌아다니며, 그곳의 무술을 배우는다는 컨셉의 다큐였는데,

"공격이 최선의 방어" 라는 기본 철학으로, 쉴새없이 공격하는것이 영춘권의 특징이다.

그리고 상대와 거리를 두는것이 아니라, 오히려 바짝 다가가 타격을 못하게 하는것이 특징..

이쯤해서, 영화 포스터 한방 박아주시고!!

참고로 엽문은 이소룡의 스승이란다..

엽문2에서 이소룡이 나온다는 스포일러도 있다. ㅇㅎㅎ

그간 수많은 문시리즈.. 대표적으로 정무문이 되겠지..ㅋ

정무문의 주인공은 정말 힘들게 이기던데...

영춘권의 고수인 엽문은 거의 맞지도 않고, 모든 상대를 거의 줄창 두들겨 팬다..

보고 있노라면,.. 속이 다 시원한다..ㅋㅋ

그리고 역시, 영화답게 주인공의 아내는 이쁘다..+_+_+

역시 영화는 영화야..ㅋ

맥용 Vmware Fusion에서 윈도우 Print Screen 키맵핑 방법

(불꽃남자) — Mon, 13 Apr 2009 23:08:57 +0900

국내 맥 유저중에 많은 수가 맥OS와 함께 Windows OS를 겸 해서 쓰고 있다.

내가볼때, 거의 90% 이상이라 생각된다. 이미 내 주변의 맥 유저중..

윈도우를 어떠한 형태로든 맥북에 깔아서 쓰고 있는 사람들이 100%다..

각설하고..

맥북에서 윈도우을 사용할때, 가장 불편한 것중 하나가 아마 키맵핑일것이다.

그중에서도 제일 먼저 골치를 썪히는게 한영키 맵핑~!!

ㅇㅎㅎ 나도 저 한영키 맵핑때문에 상당히 고생했다..

이제까지 내가 해본 한영키 맵핑의 최종 결정판은

바로 Sharpkeys 라는 키맵핑 프로그램을 이용하는 거다.

위 링크에서 다운로드 받아 실행후, 아래와 같이 키 맵핑을 하면, 한영키는 간단히 해결된다.

위와 같이 설정하면, 왼쪽 사과키는 윈도우키를 오른쪽 사과키는 한영키와 맵핑이 된다.

먼가 키맵핑이 이상하긴 한데.. 어쨋꺼나 저쨋꺼나.. 해보면 안다..

아마 한영키 까지는 대부분이 맵핑해서 잘 쓰고 있으리라 생각된다.

앞서 이미 밝혀두었지만, 난 맥용 Vmware Fusion 을 기준으로 얘기하는거다..

괜히 머 부트캠에서 안되느니 페러럴에서 안되는지 투정부리지말고.. 알아서 해결하시라..

자 그럼 프린트 스크린키를 맵핑해보자!!

아마 그럭저럭 한영키를 맵핑했던 사람들도, 프린트 스크린이 도대체 어딧는거야? 이러면서 좌절을 경험하신분이 분명 있으리라 생각된다.. 나도 한때 좌절했으니까....

그런데 바로 20분전에 누가 물어봐서 고민을 10분 해보고 해결했다.

(왜 그땐 찾아볼 생각 안하고 좌절부터 했는지...ㅇㅎㅎ)

맵핑방법은 여러가지가 있는데..

그중하나가.. 앞서 언급한 SharpKeys를 이용하는 방법이다.

샵키스를 이용할때, 불편한건 맥용 단축키가 우선순위가 높으므로, 윈도우에서 쓰려면..

맥용 단축키를 해제하거나 머 이런저런 설정으로 바꿔야 한다는거다..

그래서 난 다른 방법을 찾아보기로 했다..

이런 이건 모냐?.. 너무 쉽게 찾았다.

이미 Vmware Fusion에서 제공해 주고 있지 않은가? -_-

브이엠웨어 퓨전의 설정창을 열어보자.. 맥에서 설정창은 모두 사과키+콤마 를 누르면 된다.

그럼 아래와 같은 설정화면을 찾아볼수 있을꺼다.. 감이 오는가??

추가 설정은 당연히 위에서 + 키를 눌러 설정하면되고...

난 Print Scrn 키를 시프트+컨트롤+P 로 맵핑해놨다..

설명은 이걸로 끝!~

내가 밥상은 차려놨으니.. 밥은 알아서 떠먹길~!!

맥 터미널 사용시, 터미널 안의 텍스트가 제대로 출력되지 않을때..

(불꽃남자) — Mon, 06 Apr 2009 17:24:27 +0900

얼마전부터, 내 맥북에서 호스트 설정을 위해,..

터미널을 열고, 루트로 로그인후,.

#vi /etc/hosts

라고 입력을 하면, 그동안 설정했던 호스트들이 하나도 안보이는 문제가 발생했다..

혹시 내가 실수로 호스트를 다 날려먹은건가?..

그런 의심도 해봤는데.. 최근에 맥북으로 호스트 파일을 설정한 일이 없기때문에..

그건 아닌것같고...

곰곰히 생각해보았다.. 문제가 뭘까?

ㅇㅎㅎ 결국 1주일 내내 궁금해 했던 그 문제는 인코딩 문제였다..-_-

지난주에, 회사 원격서버 접근이 필요해서 터미널의 문자 인코딩을 EUC-KR로 설정을 바꿨었다..

다시 UTF-8로 설정을 바꾸니.. 정상적으로 나온다..

-- 이것때메 얼마나 삽질을 했떤지..

오늘 또 하나 배우는구낭.. 알수없는 삽질의 끝은 과연 언제 끝날까?

모든 캐릭터셋이 UTF-8 이었음 좋겠다는 생각을 오늘 또 해본다.

----

터미널 명령어 몇개 정리해보면,..

1. 맥 터미널 루트 인증 - 사전에 root 아이디를 생성했던걸로 기억한다.

맥도 그렇고, 우분투도 그랬던거 같고, 기본적으로 root 아이디를 따로 생성해야한다.

# su (엔터)

# 비밀번호 (엔터)

2. ssh 로 접근 하려면.. 그냥 터미널에서 아래와 같이 치면된다.

#ssh 접근 도메인 (엔터)

정리 할려고 했더니.. 딱히 더 정리 할게 없꾸낭...ㅎㅎㅎ

또 검색하다가.. 익히면 적어둬야징~

쉽게 씌어진 시와 쉽게 씌어진 글..

(불꽃남자) — Mon, 06 Apr 2009 00:20:06 +0900

지금 우리는 얼마나 쉽게 글을 쓸수 있는가?

이렇게 쉽게 씌어진 글에 얼마나 많은 애착을 가지고 있을까?

요즘 미투질을 많이 하게 되면서,.. 블로그 포스팅이 점점 뜸해진다.

좋은 글을 쓰려면 그만큼 오랜 시간을 투자하게 되는반면,..

미투데이는 너무 쉽게 글이 씌어진다..

그래서 미투쥘이라고 하는거겠지..

한통의 연애편지를 쓰는 것처럼, 애착가는 글들이..

점점 내 블로그에서 사라져 버리는 듯한 느낌이다.

사실 내 블로그에 비공개 포스팅이 몇십개 되는데..

사실은 그게다 부치지 못한 연애 편지라면...

믿으실랑가? ㅋㅋㅋ

쉽게 씌어진 시(時)
-윤동주-

창 밖에 밤비가 속살거려
육첩방(六疊房)은 남의 나라

시인이란 슬픈 천명(天命)인 줄 알면서도
한 줄 시를 적어 볼까

땀내와 사랑내 포근히 품긴
보내 주신 학비 봉투를 받아

대학 노트를 끼고
늙은 교수의 강의 들으러 간다

생각해 보면 어린 때 동무들
하나, 둘, 죄다 잃어버리고

나는 무얼 바라
나는 다만, 홀로 침전(沈澱)하는 것일까?

인생은 살기 어렵다는데
시가 이렇게 쉽게 씌어진다는 것은
부끄러운 일이다

육첩방(六疊房)은 남의 나라
창 밖에 밤비가 속살거리는데

등불을 밝혀 어둠을 조금 내몰고
시대처럼 올 아침을 기다리는 최후의 나

나는 나에게 작은 손을 내밀어
눈물과 위안으로 잡는 최초의 악수
[출처] 쉽게 씌어진 시(時) -윤동주|작성자 청포도맛

IE8 출시 기념 스페셜 포스팅~!!

(불꽃남자) — Fri, 20 Mar 2009 19:22:41 +0900

아직도 IE6을 쓰고 계십니까?.. 이제는 더이상 망설이지 않으셔도 되요!!
당당히 IE8로 업그레이드하여, 월등히 빨라진 속도를 체감해보세요~!!
자신있게 강추 드립니다..ㅋㅋㅋ

내가 모 MS 직원은 아니지만,.. 그동안 RC1 깔고 지우고 반복하면서...
IE8 제잘 쪼옴~!! 이랬는데.. 정식버전은 그야말로 굿이다..
아직은 눈에 띄는 버그는 발견하지 못했다.

그동안 알파와 베타를 거치면서 내가 리포팅한 버그도 몇개 있는데..
다 해결 되었군..ㅋ

RC1에서 Active X 황금바 관련 버그도 해결된거 같아.. 느무 기쁘다..
이젠 IE8 로도 당당하게 오픈업~!! 결제할수있꾸나~ +_+_+_+

지금까지 칭찬 일색이었습니다. 움훼훼훼..
솔직히 좀 까고 싶진 않다.. 칭찬해줄껀 해줘야지..
나부터도 우리나라 사람들은 칭찬에 너무 인색한것 같다.
이젠 칭찬하며 살아야지~ ㅋㅋㅋ

검색을 좀 해보니,..여전히 까는 사람은 까더군..
FF니 Opera니, 좀 안다고 나불대는 블로거들을 보면.. 토나온다..정말로..
웹표준이나 뭐니 좀안다고 쫑알대는 블로거와 별반 다르지 않는 수준이다..

자신들이 믿는것만이 진실인냥 나불대는 사람들이 너무나 추해보인다.
나도 한때 저랬는데.. 진실은 저 너머에... 좀더 겸손해져야겠다.

여튼, 이번 IE8 출시는 IE6 점유율에 얼마나 많은 영향을 미칠지..
기대된다~ +_+_+_+

분명 IE8이 성공해 IE점유율 50%를 넘어서는 날에는..
많은 웹사이트들이 IE8 최적화를 하겠지?
그렇다는 얘기는 FF나 사파리나 오페라에서도 다 잘되겠지?
생각만 해도 흐믓하다~ ㅋ

UMC 가 돌아왔다.

(불꽃남자) — Wed, 18 Mar 2009 20:07:52 +0900

UMC 2집이 나왔다. 찾아보니 홈페이지도 있네. ㅎㅎㅎ

내가 소시적에 B-Boy 를 꿈꾸던 학창시절이 있었지 아마 ㅋㅋㅋ
지금 생각해도 피씩 웃음이 나던 시절, 밀레니엄 이전 시절
일천구백구십년대...후반이지 아마

정확한 시점은 나도 잘 기억이 안나는데..
내 MP3에 Shubidubidubdub 노래와 이태원에서 라는 노래를 무한 반복하며,
웅얼웅얼 대던 시절이 있었는데... 아마 2005년도 쯤일꺼야..

그리고 작년이었나? 재작년이었나? 음악 그만 둔다고..
싸이 홈피에 글을 올린적도 있었떠랬지.. 아놔~ 왜 그만둔데..이랬는데..
그러면서 또 저 두노래 찾아서 무한반복 꼽씹어 보고..ㅋㅋ

분명 음악이 싫어서 안하는건 아닐꺼라 라는 생각은 있었지만,
그 짧은 글에, 뭔가 고민이 있었을꺼란 짐작을 하고도 남았지..
아마 위에 두 노래의 가삿말을 되뇌여 봐도 먼가 현실적인 문제가 있었던듯....

여튼 근데,.. 며칠전에 2집이 나왔다. 이젠 나도 직딩이라 음반 하나 살 여유는 되기때문에..
한정판으로 질렀지.. 음화하하하하하하..

싸우스파크나 봐야겠다는 노랫가사에 완전 뒤집어 졌다..ㅋㅋㅋ
나도 한때, 싸우스파크 보면서,.. 왓어뻑..비치...샤럽.. 하며 꿍얼꿍얼 하던 시절이 있었는데....ㅋㅋㅋ

오늘은 뭐? 오늘은 뭐? 오늘은 뭐? XX럼아 ㅋㅋㅋ 하면서 마무리 지어야겠다.
내가 먼소리 하는지는 노래를 들어보시면 아십니다.!!
들어보삼~!! ㅋ

말할수 없는 비밀: 난 별4개를 줄꺼야!!

(불꽃남자) — Mon, 09 Mar 2009 01:20:43 +0900

최근들어 피아노 연주가 나오는 영화들을 연달아 보는것 같다.

피아노의 숲에서도 쇼팽의 연주가 나왔는데..

여기서도 역시 쇼팽의 곡들이 나와 주셨다.

왜이렇게 쇼팽의 곡들이 나오는가 했더니, 쇼팽의 곡들이 어렵단다..ㅎㅎ

그렇쿠낭..

주걸륜이 나온 영화중에 쿵푸덩크 였떤가?

그때도 주걸륜을 처음 봤을때, 신인 배우인가?

라고 생각하면서, 오~ 독특한 한데~ 이랬는데..

역시 여기서도 그 독특한 매력을 발견할수있었다.

난 그보다도, 이 학교에 등장하는 여배우들이 너무나 맘에 든다.

왜 이렇게 하나같이 다 꽃녀들인지..

나도 저 학교 다니고 싶더랬다. ㅎㅎㅎ

여튼 이영화 강추~!!

Httpwatcher에서 이미지 요청시 Aborted 되는 현상

(불꽃남자) — Fri, 09 Jan 2009 02:06:28 +0900

항상 이런 이슈는 퇴근쯔음 생긴다..-_- 싫다 정말..

여튼, 개편이후, PV가 갑자기 줄어서.. 확인해본결과..

문제는 이미지 태그의 src 이용해 리퀘스트를 날릴때, 그 리퀘스트가 중지되는 현상이 발견됐다.

Httpwatcher에서 확인해본결과..

아래와 같은 코드 사용시에..

(new Image()).src = "로그집계기록"

열에 2~3번은 aborted가 되고 있었다.

위와 같은 상황이라면 PV가 대략 20~30%는 하락할것이다..ㅎㅎ

여튼 수많은 삽질을 통해 대강의 원인을 찾아본결과..

아래와 같은 이유가 있었다. (이유는 3가진데.. 자세한건 아래 링크 참조)

http://blog.httpwatch.com/2008/01/28/wh ··· watch%2F

그중에서 다운로드 중일때, 리퀘스트를 날리면 요청을 끊어버린다는 것!!

이게 가장 유력한 원인으로 파악되고 있다.

일단.. 내일 다시 테스트해봐야징.. 졸립넹..-_-

-----

최종정리~

위에서 발생한 문제는 최종적으로 가비지 콜렉션 문제로 정리됐다.

즉, 위와 같이 (new Image()).src = "로그집계 기록"을 호출할경우..

요청에 대한 응답을 받기도 전에 이미지 객체가 가비지 콜렉션 되어 사라질수 있다.

이럴경우, 응답은 취소가 된다.

해결책은 간단하다. 가비지 콜렉션 되지 않도록 이미지의 참조 카운터를 누군가가 들고 있으면 된다. 아래와 같이 전역변수로 가지고 있어도 되고,

_gImg = [];

function 로그집계 = {

var o = new Image();

o.src = "로그집계";

_gImg.push(o);

}

로그집계();

혹은 아래와 같이 abort 이벤트에 대해서 이벤트를 바인딩 해둬도 된다

function 로그집계 = {

var o = new Image();

o.src = "로그집계";

o.abort=function(){};

}

로그집계();

후자보다는 전자가 보다 명확한 방법이다.

후자의 경우의 코드상의 의미는 abort 이벤트가 발생했을때, 어떠한 처리를 따로 해주는것인데..

저렇게 아무런 의미없는 함수를 바인딩해둘필요는 없지 않을까?

그래서 전자로 처리했다.

간만에 앨범을 대량 구매했다.

(불꽃남자) — Wed, 07 Jan 2009 22:56:26 +0900

지난주 토욜날 주문했는데..

오늘왔네.. 어제왔었나? ㅎㅎㅎ

NELL - Healing Process

이제야 샀다.. 근데.. 모냐?-_- CD가 내 놋북에서 안읽힌다.--. 제길.. 불량인가?

Yes24에 문의해봐야겠당.

NELL - Separation Anxiety

요새 넬 노래를 자주듣는다. 씨디를 다 빌려줘서 어디에 있는지도 모르겠는데..

다행히 내 아이팟안에 Let it Rain 앨범이 있어서.. 출근할때 마다 듣고 있다.

조용히 좌석버스에 앉자서 눈감고 아침에 들으면, 너무 좋다.. 잠도 잘오고~ ㅋㅋㅋ

Dynamic Duo - Last Days

한동안 락만 듣다가 오랜만에 랩앨범이 듣고 싶어서, 고르다가..

다이나믹듀오의 전신이 CB MASS 였다는 얘길듣고, 노래한곡 안들어보고, 주저없이 사버렸다.

역시나 개코, 최자.. 귀에 익숙한 목소리라 그런지.. 촥촥 잘 붙네.. ㅋㅋ

장기하의 싸구려 커피

그냥 들리는 얘기에 서태지와 아이들 1집 난알아요 이후, 2번째 충격이다..

라는 어떤 블로그 글을 읽고, 충동구매했다... 머 가히 충격적이지는 않고,..

이런류의 음악들을 많이 들어봐서 그런지 그냥 평범한데..

쉽게쓴 가삿말이 역시 귀에 쏙쏙 들어온다.. 앨범이름 만큼 씨디 자켓이라고는 개뿔없고,..

골판지 예쁘게 접어 케이스 만든건 맘에 든다..ㅋㅋ

Epik High - pieces, part one

언젠가는 한장쯤은 살꺼라고 생각했는데.. 그날이 결국 왔꾸나.. 타블로 좋다..ㅋㅋ

아직 몇곡 안들어봐서.. 머라고 딱히 말하긴 어렵지만..

듣다보면.. 좋아지겠지.. 이제사 다양한 음악을 들을 심적 여유와 경제적 여유가 생겼다는게..

너무나 행복하다.. 줄창들어야지~!!

W&Whale - Hard Boiled

올해의 명반으로 추천된거라.. 그냥 아무생각없이 충동구매했다. 너도나도 다 강추한거라서..

일단 들어볼 요량으로 사버렸다. 역시나 아이팟에 옮겨놓기만하고, 듣진 못했다.

감상평은 나중에 해야지..

윤상 - Song Book

윤상 앨범을 살까.. 윤종신 앨범을 살까 고민하닥.. 일단 윤상부터 샀는데..

CD 2장 짜리네.. ㅎㅎ 이것도 씨디케이스가 골판지 빡스다.. 나 이런거 좋아하긴하는데..

이 골판지 케이스는 내부에 본드냄새가 넘 심하다..-_- 나 냄새에 민감한데..

머 노래는 다 옮겨놨으니.. 다시는 케이스를 열어볼 기회는 없을듯..

그대로 CD장으로 고고싱~ ㅋㅋ

총 7장을 구매했구나.. 사실 오늘 택배와서 뜯고 나서 깜짝 놀랬다.

내가 이렇게 많이 샀나?.. 그동안 장바구니 리스트에 담아둔거 다시 추려서..

확 구매했는데.. 꾀나 많이 산거같다..ㅎㅎㅎ

아직도 사야할 앨범들이 너무 많다.

빅뱅도 사야하는데... 빅뱅 싱글은 왠지 사기싫다..--

정규앨범 살려고했더니.. 또 싱글에 있는 앨범노래가 오리지널이 아닌 어쿼스틱으로 들어가있네..

아우~ 갈등..

김C 앨범이랑 윤종신껏도 리스트에 넣어놨다.

브라운아이즈 1집이랑 아이즈드 소울 1집 사고 싶은데..

여전히 품절이구만..-_- 다시 안나오낭?..ㅎㅎ

UI는 항상 적응을 필요로 한다.

(불꽃남자) — Sat, 03 Jan 2009 01:50:00 +0900

네이버 메인개편 이야기부터 시작해보자..

웹사이트 UI 개발과 관련된 서적에서는...
웹사이트 개편시, 기존의 UI를 점진적으로 개편하라고 말한다.

하지만, 이번 메인개편은 정말 대대적인 공사(?)를 진행했다.
물론 몇몇 사용자들(울 엄마 아빠..ㅎㅎ)은 뭐가 바뀐거지? 이렇게 반응했다..ㅎㅎㅎ

참고로... 울부모님은 이러고 있다.
울엄마 반응 - "뭐 바꼈어?.. 그대론데?.. " (-_- 엄마...ㅎㅎㅎ
울아빠 반응 - "뭐 바꼈어?.. 이거 모야? 동영상 광고야..?? " (-_- 아빠~.. ㅎㅎㅎ

그밖에 인터넷에서 떠다니는 반응들을 수집해보면,..
꾀나 많은 사람들이 불편하다고 얘기한다.

정말? 그렇게 불편해?..

불편함은 아래 2가지로 요약할수있다.
1. 기존의 익숙함에서 오는 불편함과..
2. 새로움에 적응해야하는 불편함...

내가 처음 맥을 사고 나서,.. 느꼈던 불편함을 회고해보면..
아마 맥을 사고 나서 근 석달동안 맥을 씹어댔다..
불편하다고.. 윈도우가 역시 짱이라고..
내주변 친구들은 다 알듯.. 내가 얼마나 맥을 사놓코 투덜투덜 됐는지..

역시나 내 블로그 곳곳에 흔적들이 남아있어서.. 정리해봤다.

아무리 생각을 해봐도.. 맥북은 참으로 불편하다.. 일단 무엇보다 엄청난 무게의 압박..
좀처럼 익숙해 지기 어려운 키보드 배열.. 단축키.. 내가 즐겨쓰던 윈도우키도 없고..
[출처 : http://miconblog.com/tc/sohn/327]

얘네들 정말 짜증나 정말.. 짜증이야.. 써근사과... 쀅!
오늘로써 맥북 사고.. 2주째 방치중이다... 당췌 맥북을 열어볼 엄두가 안난다...
이러다가 올해안해 열어볼수는 있는것인가?.. -_ㅜ
[출처: http://miconblog.com/tc/sohn/305]

정말 맥북.. 살사람들은 고심하고 사라!! 순간 당황했다..

...중략...

그러나 여전히 직관적이지 못한 인터페이스중에 하나는

delete키 -_- 맥북은 FN키와 delete키 조합으로 백스페이스 기능까지 같이하고 있다..

일종의 모드를 사용하고 있는데, 불편하다..-_- delete키도 많이 쓰고 backspace도 많이 쓰는데.. 그냥 독립키로 하면 안되나?-_- 맨날 헷갈린다.. 아직 적응이 안된건지.. 아니면 헷갈림에 적응된건지..-_-

[출처: http://miconblog.com/tc/sohn/297]

그러나 지금 난 맥 신봉자다!! ㅋㅋ 정말 써보면 알게된다..
처음에 좀 불편하지만.. 쓰다보면, 분명 더 나은 UI 라는것을 느끼게 된다.

이번 개편에서 나오는 반응을 보면서.. 1년전 새로 산 맥북앞에서 투덜되던
나의 모습을 보는거 같아서.. 좀 욱겼다..ㅋㅋㅋ
근데 아마도 당분간은 계속 투덜될것같다.
내가 그러했듯.. "맘먹고 써보자" 라고 생각하기 전까지..ㅋㅋ

UI, 과연 적응만 하면 끝인가?

사실 사용자에게 무조건 적응만 하면 된다고, 얘기하는건 좀 무책임한 발언이다.
최소한의 가이드는 제공해줘야 하지만. 그렇다고 가이드를 따라하며 배울 사용자도 아니다.
전자제품 설명서만 봐도 안다.. 우리는 그딴걸 읽어보지 않을꺼라고..
보통 전자 제품 설명서는 일단 해보고.. 안되면 찾아보게 된다..ㅎㅎ

역시 맨땅에 헤딩하기를 좋아하는 사용자들

그렇기 때문에,.. 직관적인 UI를 만드는 것이 굉장이 중요하다.
하지만 직관적이다 아니다 또한 굉장히 경험적이면서 주관적인 요소가 포함되어 있다.
따라서 사실 이것이 좋은 UI 이다 아니다를 구분하기는 참으로 어렵다.

그럼에도 불구하고, 재밌는 사실은.. 상대적으로 이게 더 편하다. 불편하다는 구분할수있다.

상대적으로 비교 가능한 UI, 그리고 정량화

가령 예를 들어보자.
앞에서 언급했듯이, 사람마다 주관적인 경험적요소가 좋다/나쁘다를 결정짓는 잣대로 쓰이기때문에.. 여러사람을 기준으로 어떤 UI를 비교하긴 어렵다.
하지만.. 한사람이 여러 UI를 비교해보면,..
이건 저거보다 쉽다 어렵다를 구분하기 쉽다.

내가 보통 예로 드는건,..
예매 사이트중에.. 씨즐과 YES24..
두 영화 예매사이트중에서 난 Yes24가 더 편하다..

그렇다고 Yes24가 아주 좋다는건 아니다..
개선해야할게 너무나 많치만,. 그럼에도 불구하고 씨즐보다는 좋터라..
물론 개인적인 경험에 의해서다..

여기서 한마디 충고.. Yes24.. ( 내블로그 자주 등장하는 사이트중에 하나...ㅎㅎ)
당신네들 도대체 영화에 플래시 스크롤 해줄꺼야? 말꺼야?
아우~~ 정말 불편해.. 도대체 그 조그마한 스크롤을 어떻게 마우스로 찍어서 하냔말이야..
심지어 난 마우스 없이 쓴다규~~
플래시 스크롤 되게 해달라~ 해달라~
(스크린샷 찍어놨는데..-_- 파일 업로드가 안되네..-_- ㅎㅎ)

여튼 그렇다.
역시나 오늘도 끝맺음은 못하고.. 졸려서.. 다음기회에...

---------

생각난 김에.. 덧붙이면..

오늘 오랜만에 CGV 사이트에서 직접 영화 예매를 강행했다..

이유는,.. Yes24에 할인권과 포인트를 다 써버렸기 때문이지..ㅎㅎ

여튼,.. 오늘 CGV 예매 사이트의 인터페이스를 보면서...

감탄했다.. 아~ 참 쉽게 잘 만들었네~~ 흐믓 미소가 지어진다..

먼저 스크롤이 커졌다~ +_+ 유후~~

(그러나 여전히 마우스휠로 스크롤이 안된다..-___- 요건 개선해주세요~ 네에~ )

마우스휠을 이용한 스크롤은 아직(?) 안되지만,.. 그래도 좋은건..

보이지 않게 사용자를 가이드한다.. 즉,

첫번째 스텝을 수행하지 않으면.. 2번재 스텝의 마우스 스크롤이 동작하지 않는다는거..

약간은 사용자를 제약하는 면도 없잖아 있지만...

예매 시스템의 흐름상 적절해보인다..

그러나 한가지 문제점이라면..-_-..

로그인체크를 먼저좀 해줘야한다는거..

대충 다 선택했는데.. 결제하려니.. 로그인 해야한단다..

로그인했더니..-_- 설정했던거 다 날라갔다..-_- 이것도 좀 개선해주시죠?

그리고 여전히 모든 사이트에서 개선되지 않는..크로스브라우징 문제.

결제시스템과 연관이 있는 문제이므로.. 제발좀... 엑티브엑스를 이용한 결제시스템은좀...

그래도 이런 기술적인 인터페이스를 제외한..

순수한 GUI 측면에서는 많은 발전을 이룬것같아 흐믓했다..

이제 CGV사이트를 좀 많이 이용해봐야겠다..^^

개선하느라 고생한 UI 개발자에게 심심한 박수를 보낸다~ ㅎㅎ

쌍화점 식껍했다..

(불꽃남자) — Sat, 03 Jan 2009 00:40:56 +0900

퇴근 막판에 또 일이 밀려,.. 식겁했는데..
머리좀 식힐겸 퇴근후, 영화한편을 봤다.

최근에 나온 볼만한 영화들은 다 본거같아서..
쌍화점을 선택했다..

출발비디오 거시기 이런데서 대충을 줄거리를 봐서,
역시 그게 다 이겠꺼니.. 하며 별 기대는 안하고 봤다..

근데..
하악하악.. 헉!!!!

식껍했다!!

배드씬이 참 많아 좋았는데..케케케케
송지효 이쁘던데~ +_+_+_+_+ ㅋㅋㅋ

근데 그게 중요한게 아니라..
허어어어어어어헉~~
식겁했다..

너희둘~!! 하아아아아아아아~~
식껍했다..

식껍.. 젠장...

영화는 참 잘만든거같다..
그런데.. 식껍했다.. 허어어어어어억~

과속 스캔들 그리고, 예스맨

(불꽃남자) — Sun, 21 Dec 2008 23:00:06 +0900

어제 오늘 오랜만에 연이어 문화생활을 즐겼다.

먼저 오늘 본 과속 스캔들..
간만에 훈훈한 영화..
못 보신 분들은 꼭 보시길...

애들이 넘 연기를 잘한다~ 완전 귀여움~ +_+_+_+
우리 보영씨는 노래를 왜케 잘하냐?
태현횽아의 코믹연기는 항상 기본은 하지~!!

그리고 예스맨!
초 긍정주의..
생각만큼 미친듯이 재밌는 영화는 아니지만..
역시나 볼만한 영화임..

두편중 한편을 보라고 한다면,..
난 과속스캔들이 더 재미있었음..

이상 후기끝~!

개발자 좀 살려주세요~ SaveTheDevaloper

(불꽃남자) — Tue, 16 Dec 2008 02:06:12 +0900

오늘 새벽은 아래 링크 하나로 큰웃음 지으면서,.. 잠을 잘수 있겠다..ㅋㅋ

http://resistan.com/savethedeveloper/

농담삼에 모든 사람들이 MS로 통일해서 IE만 썼음 좋겠다..

라고 생각할때가 한두번이 아닌데..

그이유는 바로 IE6 때문이라지요..ㅋㅋ

겉으론 캠페인에 동참하고 있지만... 정작 내가 IE6 을 못버리고 있다는거,...

어쩔수 없지 않은가..

그네들이 IE6 을 모두 버리지 않는 이상.. 난 IE6을 못버린다는 사실..OTL

누구를 위한 하위 호환성인가?

가끔은, 여전히 절대 다수의 점유율을 자랑하는 IE6 사용자들을 위해,..

하위 호환성을 유지하고 있지만은...

앞으로 자라날 우리 아이들이 쓰는 웹환경을 위해서는...

하루빨리 IE6이 사라져야 하지 않을까? ㅋㅋㅋ

과거의 아버지들이 그랬던것처럼,..

우리도 우리 아이들에게 좀더 나은 환경을 제공해주기위해선..

피할수 없는 선택!.. 이라고 하면..

욱긴다... 왠지..

장가는 갈수 있을런지...ㅎㅎ

FF 에서 강제로 한글 IME 변경하기..

(불꽃남자) — Mon, 15 Dec 2008 18:37:34 +0900

imeMode 속성은, IE 전용 속성인데,
FF3 에서부터는 해당 속성을 지원해주는듯하다..
https://developer.mozilla.org/En/CSS/Ime-mode

하지만.. 테스트는 안해봤다. 테스트 해본 사람들에 의하면,..
아직 안된다고 하더라..ㅎㅎ

그래서 좀더 크로스 브라우징이 가능한 방법이 없을까?
생각하다가.. Flash 인터페이스를 이용하는건 어떨까 생각해봤다.
아래 링크를 참조하고..
http://kimkijeung.com/entry/IME-Input-Method-Editor

위 링크처럼 가능하다면, 플래시컨테이너 하나 로드해놓고,
인터페이스 함수만들어서, 자바스크립트로 해당 함수를 호출하면
간단히 해결될것같은데..

오늘 집에가서 한번 만들어봐야겠당..ㅋ

반대로, FF에서 한글을 입력 안하게 하는 방법도 있을수 있겠다
편법이지만..
http://blog.hooriza.com/1049

웹사이트 최적화 #1. 요청횟수 줄이기

(불꽃남자) — Wed, 10 Dec 2008 03:17:03 +0900

앞으로 오픈베타까지 5일 남았다.
그동안 반 미친듯이 코드만 짜다가, 요즘은 막바지라 한결 여유를 찾은듯하다.
어제부터 코드 프리징을 위한 막바지 최적화 작업에 들어가고 있다.

오늘은 여유롭게, 그동안 못한 블로깅을 하면서, 얘들은 먼 얘기를 하고 있을까..
검색을 좀 해봤다. ㅎㅎ
많은 사람들이 기대반 우려반, 그리고 일단 까고보자 반, 아무생각없다 반인거 같다. ㅎㅎ
머 결국 어느정도 관심은 있다 정도로 정리가 되는군.
머 일단, 각설하고...

개편되는 메인페이지 로딩속도를 최적화하기 위해 고민한 것들을 공유해본다.

사용자에게 있어서 첫 페이지 로딩속도는 굉장히 크리티컬한 요소다.
그렇기 때문에 최적화 작업을 하면서, 가장 신경썼던 부분이 바로 요청회수 줄이기였다,

클라이언트 영역에서 요청횟수를 줄일수 있는 방법은 3가지로 볼수있겠다.
외부링크로 걸려있는 css 파일 갯수 줄이기..
외부링크로 걸려있는 js 파일 갯수 줄이기..
그리고, 이미지 갯수 줄이기..

하지만, 실상 요청횟수 줄이기가 만만치는 않았다.
특히, 이미지가 주가 되는 대부분의 포탈이나 웹사이트의 경우는 정말 불가항력에 가깝지 않을까?

그래도 뭐 어떻게든 요청횟수를 줄이기위해, CSS Sprite도 적용했지만, 접근성 문제로 인해,
전면적으로 CSS Sprite을 적용할수는 없었다.
"CSS Sprite은 의미없는 배경 이미지에만 적용할 것을 권한다."
CSS Sprite은 검색을 해보면, 아마도 구글 코리아 메인 페이지의 애니메이션 효과를 예제로 들고 있는 글들을 쉽게 접할수 있다. 바로 구글 코리아가 적용한 애니메이션 효과가 대표적인 의미없는 배경이미지가 되겠다.

여기엔 단순히 접근성 문제만은 아니고, 대부분 캐시 서버에 이미지를 올려놓기때문에, 운영이슈도 함께 고려되어야한다. 이미지에 수정사항이 생기면, 전체 그리드 이미지를 새로 업로드하고, 경로를 수정해줘야한다. 안그럼 캐시된 사용자의 브라우저에선 제대로된 이미지를 볼수없을테니 말이다. 이럴때마다, 정말 구글과 같은 텍스트 기반의 웹사이트들이 어찌나 부럽뜬지..ㅎㅎ
그러나 , 여기는 한국이고, 구글이 우리회사도 아니다! ㅎㅎ

한편 모듈별로 작업하면서 크고작은 최종 js 파일의 갯수는 총 20개나 됐다.
물론, 배포툴을 이용해 파일을 2개로 합쳤고, 압축을 하지 않았을 경우, 대략 200KB 정도의 크기였다. 그리고 압축을하고, 아파치 gzip 모듈을 적용하면, 대략 40KB 정도의 크기가 나왔다.
요청횟수는 1/10로 줄였고, 파일크기는 대략 1/5 정도로 줄였다.

과연 이렇게 최적화한 결과는 어떠했을까?
FF3 의 FireBug 를 통해서, 대략적인 로딩 시간을 비교해봤다.

[그림으로 넣으려고 했으나.. 귀찮아서 생략하고 대략의 결과는 다음에...ㅋㅋㅋ]