TNF Needlworks

플러그인 놀이

즐거운 이야기 2007/06/14 01:36 by J.Parker

몇몇 커뮤니티 사이트에서 openAPI를 제공하고 있습니다. 이에 사용 유저들은 매쉬업을 통한 여러 종류의 상품을 만들고 공개하고 있으며, 지금도 여전히 여러 유저들이 openAPI를 이용하여 다각화시키고, 이 중에는 멋진 비지니스 모델로 성장할 수도 있는 것들도 많이 있는 것 같습니다.
구글에서 제공하는 API, 그리고 다음, 네이버, flickr 등에서 제공하는 openAPI로 텍스트큐브용 플러그인을 시도해보니 개인 블로그 상에서만 국한된 플러그인이 아니라 보다 확장성이 높은 플러그인으로 거듭날 수 있음을 알 수 있습니다. 어디선가 '웹2.0의 주역이 openAPI 일 수도 있다'고 한 말이 과언은 아닌 듯합니다. 텍스트큐브에서도 개인형 블로그가 아닌 비지니스 모델로 성장 시킬 수 있는 매쉬업 플러그인들이 많이 만들어졌으면 하는 바람입니다.
올여름 후엔 MetaWeblogAPI를 이용한 텍스트큐브용 포스팅 s/w를 만들어 볼 생각입니다. 이미 나와 있는 것들이 많지만, 텍스트큐브에 안성맞춤인 것 같아 생각 중입니다.
생각해 놓은 아이디어들은 많은데 막상 잘 나오지 않습니다. 차차 하나둘씩 호주머니에서 나올 듯합니다.^^

---

일찍 자려고 노력하기

즐거운 이야기 2007/06/14 00:02 by hojin.choi

요즘 일찍 자려고 노력합니다. 12시 이전에요. (그러나, 지금도 10분 남았다는 사실) 빠지는 머리 나오는 배, 요거 인생 겁주더라구요. 12시에 잔다고 하지만 6시에 일어날 것을 목표로 하고 있습니다.

일찍 자면서 할 일을 어떻게 하느냐, 전엔 노트북을 회사나 집에 놓고 다녔지만, 이제 들고 다니면서 짬짬히 시간나는대로 작업하렵니다. 최대한 시간을 쪼개서요. 참고로 출퇴근 시간, 걷는 것을 제외하고, 지하철에 앉아 있는거 합치면 한시간 조금 넘게 나옵니다.

지하철에서 책을 읽다가 자리나면 앉아서, 조금 뜸들이고, 놋북을 켭니다. 요즘 ACL 관련해서 텍스트 큐브(TC) 소스를 수정하는데, 지하철에서 집중이 더 잘 돼요. 페도라의 베릴 조합이므로 가끔 큐브 돌릴 때 의식이 되긴 하지만요. ;)

총 합 2시간 정도를 TC에 넣는 정도로 집중하고 있습니다. 여러분 저의 이 시간 관리가 성공해야 아내에게 사랑 받습니다. 좀 격려 해 주십쇼.

---

자바스크립트

즐거운 이야기 2007/06/13 23:49 by inureyes

물리학이 전공인데 자바스크립트를 죽자살자 붙잡고 있는 중입니다. 수강중인 DR (Data retrieval 또는 information retrieval이라고 하는 분야입니다) 과목의 프로젝트를 구현하기 위해 자바스크립트 의존적인 클라이언트? 를 짜고 있기 때문입니다. 재미있는 아이디어의 프로젝트입니다. IR의 한 분야에서는 middleware 등에서 조건에 맞는 요소를 뽑아내는 부분에 대한 것을 다룹니다 -top-k query라고 합니다-

프로젝트로 제안하고 만들고 테스트하고 있는 것은 관점을 좀 바꿔본 top-k query 방법입니다. 보통 서버에 키워드를 날리면 서버에서 처리한 결과가 날라오고, 그에 따른 카테고리를 선택하면 또 서버에 쿼리가 날라가고 돌아오고는 하는데, 그 과정을 전부 클라이언트로 옮기게 됩니다. 이 과정의 장점중 하나는 개인의 검색 성향을 서버에 제공해주지 않을 수 있다는 것입니다. 그러면서 검색에 대한 개인화 구현이 가능하게 되지요.

이런 부분을 실제 서비스 업체들은 그다지 안 좋아할 수도 있습니다만, 전 필요하다고 생각하고 있습니다. 응용이 별 것 없을 것 같이 보입니다만 생각해보면 다양합니다. 전 로그인이 참 귀찮습니다. 그렇지만 뭘 보고 싶은지 잘 모르는 상태에서 서비스를 사용하거나 쇼핑을 할 때, 저절로 자신의 관심사로 검색 결과들이 포커싱되는 것은 로그인없이 구현하기가 어렵지요. 이 프로젝트는 그걸 가능하게 해줍니다. 자세한 것은 귀찮아서 생략하고 페이퍼 나오면 붙이도록 하겠습니다.


그런데 이 과정에서 해당 클라이언트를 activeX로 짜면 우선 제가 못 씁니다. 그래서 서버와 상호통신하고 top-k 계산 과정을 수행하는 클라이언트를 통째로 자바스크립트로 짜고 있습니다. 참 상반된 느낌을 받으면서 짜고 있습니다. 하나는 '자바스크립트가 이렇게 강력한 언어였나' 하는 것이고 다른 하나는 '뭐 이딴 언어가 다있냐' 는 것입니다. ajax가 때늦게 각광받는 이유도 동시에 배우고 있습니다.

맘잡고 써 본 자바스크립트는 굉장히 객체지향적입니다. 게다가 각 객체들을 웹페이지 구성요소와 붙이는 것에 있어서는 페이지와 동시에 독립적으로 로딩된다는 점 때문에 다른 방법으로는 흉내낼 수 없는 것들을 해 볼 수가 있습니다. 적당한 프레임웍과 희한한 자바스크립트 notation에 대한 이해와 노가다가 합체하면 생각한 것은 대부분 해 볼 수가 있을 듯 합니다.

하지만 동시에 '호환성'이 문제가 됩니다. 브라우저마다 다르게 돌아가는 (자바스크립트 파서가 다르기 때문이지요) 자바스크립트를 생각하면 무작정 생으로 짜다가는 activeX 못지 않은 변태 스크립트가 등장할 수 있습니다. 게다가 JSparser가 잘 뻗습니다. 좀 잘못짰다 싶으면 테스트 중에 브라우저가 수많은 친구 탭들을 안고 사망합니다. (왜 사냐건 울지요) 게다가 (이건 이제서야 JS활용이 극대화되는 이유중 하나이기도 할텐데) 느립니다. 정말 느립니다....

php로 구현한 서버측 드라이버들을 제외하면 원하는 기능을 구현한 자바스크립트 모듈은 천 줄 정도밖에 안됩니다만, 하부에 dojo framework의 컴포넌트 일부를 연결했기 때문에 필요한 기능만 잘라 왔다고 하더라도 실제로는 크기가 좀 됩니다. 제가 무식한 것들을 요구해서이기도 하겠습니다만, 속도가 잘 안 나옵니다. (그래서 온갖 편법을 동원하여 속도를 늘리려고 했습니다만 여전히 느립니다.[footnote]예를 한 번 들어보면 이런 것도 있습니다. string을 number로 변환하려면 앞에 + 붙이는 것이 가장 빠른 방법입니다. 여러가지 방법 중 parseInt는 가장 느린 방법이지요.[/footnote]) 그래서 구현한 결과가 컴퓨터 사양을 탑니다.


쉽게 쓴다고 썼는데 쓰다 중간에 위를 읽어보니 더 쓰면 안 되겠다는 생각이 드네요. -_-;
그래도 즐거운 이야기로 붙이렵니다. ~


덧) 일주일째 테스트 데이터베이스를 셋팅하고 있는 프로젝트 공동 진행자 모 분은 끝없이 좌절하다가 막 자러 갔습니다. 검색 엔진 구현을 위해 word relation 측정을 위한 웹문서 샘플링과 카테고리 저장을 하는데 DB가 벌써 60기가가 넘어가네요. 단일 mysql에서 50기가 넘는 데이터베이스를 핸들링 하는 것은 실제로는 처음 봤습니다. (보통 분산하면 했지 이렇게는 잘 안하지요)

---

칼루아 밀크를 아시나요?

즐거운 이야기 2007/06/10 23:53 by LonnieNa

깔루아 혹은 칼루아 밀크(Kahula Milk)라고 불리웁니다.
처음 칼루아밀크를 접하게 된게 오래되었는데요, 친구랑 칵테일바에 갔다가 바의 구조상 앞에 앉아있는 언니(?)가 마시는걸 보고 커피냐고 물었다가 한 모금 뺏어 먹어보고나서 푸욱빠지게 되었답니다.



집에 칼루아 리큐어 병채로 있다죠.
실제로 리큐어를 원액으로 마셔본적은 없습니다.
레서피가 너무 간단해서 집에서도 손쉽게 만들어 마신답니다.

우유와 칼루아 리큐어를 4:1 비율로 섞어주기만 하면 되거든요.
진한 커피향과 맛이 대부분이고, 당연히 우유를 섞었기에 부드러운 우유맛도 느낄 수 있답니다.
맛은 꿀을 섞은듯 달콤하니 끝맛은 알콜냄새가 조금 납니다.
달콤 하다고 많이 드시면, 겉보기완 달리 이게 나름대로 알콜 도수가 좀 있어나서 너무 많이 마시면 안되요..

오늘 연인과 혹은 아내와 남편과 함께 나름대로 즐기는, 집에서의 칵테일 한잔 어떠세요?

---

자연의 아름다움

따뜻한 이야기 2007/06/07 18:04 by daybreaker

룸메랑 수업을 같이 듣는 경우가 많다보니, 자연스레 같은 길을 두런두런 이야기하며 걷는 시간이 많습니다. 얼마 전에 제가 룸메에게 물었죠. "너는 길가에 아름답게 피어난 꽃들을 보면 아무런 감흥이 없냐?"고 말입니다.

..그랬더니 "응, 별로."라고 하더군요. 대신에 천5백만원짜리 진품 분재를 구분한 적이 있다나 뭐래나..;;

어렸을 때 서울 강남의 삭막한 아파트단지에 살면서도, 철따라 피어나는 민들레, 제비꽃과 각종 이름을 알 수 없는 들풀들, 땅바닥을 기어다니는 곰개미들은 저의 길벗이었고, 저는 지금도 항상 마음에 소중히 간직하고 있습니다.

혹시 아시는지요? 잔디도 꽃이 핀다는 걸. 매년 이맘때쯤 잔디밭을 낮은 각도에서 잘 보면 꺼뭇꺼뭇한 색이 나타나는데, 다름이 아니라 잔디의 꽃대가 검기 때문에 그런 것입니다. 절기가 변할 때마다 주변의 식물들이 어떻게 변해가는지 자세히 관찰해보면 재밌는 것들이 많습니다. 단풍나무의 꽃이 열매가 되어 팔랑팔랑 돌면서 떨어지는 모습이라든지, 플라타너스의 씨앗이 땅바닥에서 이리저리 치이며 흩어지는 모습, 막상 씨는 없다는 참나리의 수줍은 꽃대, 어렸을 때 할아버지 집에 가면 있었던 대추나무의 설익은 초록 대추들.

저는 아무리 바쁜 프로젝트-_-를 하러 가는 길이라고 해도, 살갗에 닿는 바람결과 그에 맞춰 흔들리는 풍성한 나뭇잎들, 사각사각 거리는 소리를 들으면 기분이 즐거워집니다. 무던히도 생명력을 뽐내는 식물들을 보면 말이죠. 식물과 곤충들로부터 얻는 아름다움은 제 그림의 단골 소재가 되어왔고, 최근에 그린 작품들도 그와 관련이 있습니다.

자신의 주변에서 자연의 아름다움을 찾는다면, 하다못해 콘크리트 틈새에 피어난 못생긴 민들레 한 송이라도 관심을 가지면 색다른 세상이 보일 겁니다. 저는 자연을 사랑한다는 것이 다른 거창한 것을 말하는 게 아니라 이런 소소한 데서 나오는 것이 아닐까 생각합니다.
왜 사람들은 그런 아름다움을 모르는 걸까요? 단지 관심이 없어서일까요. 보다 많은 사람들이 자연을 사랑했으면 좋겠습니다. ^^

ps. Needlworks 팀의 역할 구조도 그렇고 홈페이지 디자인도 그렇고 제가 좋아하는 식물과 곤충에 컨셉이 맞춰져 있는 것도 우연은 아닌 것 같군요. :P

---

비표준화 작업

머리아픈 이야기 2007/06/07 16:44 by J.Parker

W3C의 웹 표준화에 대해 알게 된 것은 불과 1년하고도 몇 달 정도이다. 실제 몸소 체험하게 된 계기는 태터툴즈 블로그를 만나면서 이고, 그 이후로 웹 표준화에 신경을 써야 한다는 쉽지 않은 압박감을 가지고 있다. 태터툴즈 스킨을 몇 개 만들어 봤지만 어찌 그리 표준화 작업이 어려운지 애 먹은 적이 한두 번이 아니다. 여러 스킨들을 만들어 내시는 스킨메이커분들이 존경스러울 다름이다.

얼마 전부터 몸담고 있는 회사에서 생각지도 않은 웹사이트 개발 업무를 시작했고, 얼떨결에 참여까지 하게 된 케이스이고, 정말 하기도 싫은 jsp로 구현을 해야 한다. 참한 디자이너도 없는 그렇다고, 컬러 감각이 뛰어난 개발자도 없는 팀으로, 정말 난감한 상황이다. 현재 60%의 공정이 진행되고 있지만, 말 그대로 90년대 말 홈페이지처럼 단순하게 컬러링 했고, 나름대로 웹 표준에 맞추려고 무단히 노력하고 있는 상황이다.

개발에 참여하고 있는 이들이 대부분 웹 쪽과는 담을 쌓고 있는 실정이고, 웹 표준에 대해서는 더욱 그러하다. 이런 상황에서 나름 웹 표준에 맞춘다고 하는 것이 정말 맨땅에 헤딩하는 기분이 듭니다. 그래도 블로그라도 운영하는 내게 "조금 맞춰보지 그러나.."라며 말을 하는 팀선배의 말에 표준에 맞춰보고는 있지만...  역시나 웹 표준은 가까이 있음에도 멀리 있음을 깨닫게 합니다. 웹 표준에 대한 중요성을 인지하도록 한다는 것도 쉬운 일이 아닌 듯 합니다.

몇 달 전인가? 회사에서 운영하고 있는 현재의 홈페이지에 대한 웹 표준성에 대해 팀장에게 말한 적이 있습니다. IE전용에 그 외의브라우저에서는 전혀 말을 듣지 않는 홈페이지 입니다. 왜 이 상태로 내버려두냐고 하니 "대부분 IE만 쓰잖어"라고 말합니다."그렇지만... 기타 등등에도 사용성이 용이해야 하지 않을까요?"라고 말한후 여태까지 처리가 안 되고 있는 상황입니다. 이런 시점에서 앞으로 남은 40%의 공정을 어찌 맞춰가야 할지 걱정입니다.

이 기회를 통해 웹 표준이라는 어려운 일을 매번 해결해주시고 계시는 graphittie님께 정말 감사드립니다.

---

혼란 / 태터툴즈 프로젝트를 회고하며

머리아픈 이야기 2007/06/07 00:34 by inureyes

지나가는 이야기.

어떤 일이든 시간이 지나면 역사가 생긴다. 태터툴즈도 돌아보면 3년이 넘은 프로그램이고 프로젝트이다. (위키백과에 정리되어 있는지 모르겠지만) 정재훈님이 시작한 프로그램이 '태터앤 컴퍼니'라는 회사를 탄생시키고, 이후에 다시 GPL로 공개되면서 '태터앤 프렌즈'라는 사용자 커뮤니티가 개발에 참여하게 되고, 얼마 지나지 않아  데이터 형태의 개인 창조물이 창조자가 아닌 기업에 일방적으로 종속되는 것을 반대하는 '태터 네트워크 재단'이라는 개념이 이야기 되며 개발의 대부분을 담당하게 되고, '태터 네트워크 재단'의 주장을 펼치기 위한 구심점이 약한 점을 개선하고자 니들웍스가 구성될 때 까지 거의 쉬지 않고 달리고 있는 중이다.


태터툴즈가 한 단계에서 다음 단계로 넘어가는 과정을 들여다보면 재미있는 현상들을 발견할 수 있다. 그 중 한가지는 단지 3년간의 변화가 '오픈소스 소프트웨어 업계'의 기나긴 역사를 굉장히 압축해서 보여주고 있는 점이다. 개인의 "필요"가 소프트웨어가 되고, 그러한 "필요성"을 공유하는 사람들이 많아지고, 사용자가 늘어나게 되면 회사가 생기게 된다. 이후 사용자 참여와 우군을 확보하기 위하여 GPL을 선택하게 되고, 자발적으로 사용자 중 개발에 참여하는 사람들이 생기게 된다. 이후 기업은 엔터프라이즈 사업, 서비스 사업 또는 기존의 기술에 기반한 새로운 사업에 진출하며, 오픈 소스 프로젝트는 커뮤니티에 맡겨지고 기업과 공생관계를 맺게 된다.

저 과정의 중간 단계에서 사라지거나 지지부진해지는 오픈소스 프로젝트들이 많다. 필요성을 공유하는 사람들이 많지만 개발을 전담하는 기업 또는 조직이 생기지 않을 경우, 사용자의 필요성을 계획성있게 적당한 시기에 반영하지 못하게 된다. GPL을 선택하지 않고 소스 단계에서 공개될 수 밖에 없는 스크립트 언어 기반의 프로그램을 공개할 경우 사용자 참여 대신 소스를 다른 기업등에 넘겨주기만 하는 자선단체가 된다. 프로그램이 공개된다는 특징 때문에 적당한 시기에 이를 기반으로 할 새로운 사업을 찾지 못할 경우 기업의 존폐가 영향을 받게 된다. 오픈 소스 진행 주체가 명확해지지 않으면 새로운 사업에 집중하는 기업의 리소스 부족과, 사용자가 늘어날수록 그에 비례하여 늘어나는 요구사항을 컨트롤하기가 힘들어지게 되고, 적어지는 사용자 참여로 인하여 프로젝트가 죽게 된다.

그 과정을 태터툴즈는 훌륭하게 넘어왔고, TNF/니들웍스, TNC는 그 다음을 향해 달려가고 있다.

초창기부터 태터툴즈를 사용해왔고, GPL과정을 흥미롭게 바라보고 처음 불만을 터뜨렸었고, 지금은 태터툴즈/텍스트큐브가 삶의 한 부분이 된 사람으로서 지난 3년 (그리고 그 중 15개월) 은 여러 의미가 있다. 태터툴즈의 개발 과정과 주체, 변화가 저렇게 속도감을 가지고 달려온 저변을 생각해본다.

'타산지석'이라는 말이 있다. 많은 오픈 소스 프로젝트들의 명멸이 태터툴즈의 방향을 정해 나가는 것에 도움이 되었다. 많은 프로젝트들이 있지만 로드맵을 세워 나가며 많이 고려했던 프로젝트는 '페도라', '모질라' 와 '베릴'  프로젝트였다. 그 셋은 각기 다른 굉장한 개성을 가지고 있다. 구태여 설명하는 것이 사족일 정도이다.

수많은 프로젝트들이 도움이 되지만 특히 그 세 프로젝트들의 생성과 진행, 역사는 '거대한 목표를 가진 프로젝트' 가 어떠한 시점에 어떠한 결단이 필요한지에 대한 통찰의 재료가 된다. 프로젝트들의 실패나 느려짐이 어떠한 상황에서 발생했었는지, 어떨 때 프로젝트가 '바람직한 방향'으로 흘렀는지에 대한 예는 찾아보면 끝이 없다. (역시 이야기하는 것이 사족이 될 것이다.) 적당한 타이밍에 다음 단계로 나가야 한다고 생각했고 태터툴즈를 '도구를 넘어선 어떤 것'으로 사랑하는 분들과 함께 계속 앞으로 나아가고 있다.

이제 얼마 후면 공식적으로 태터툴즈는 텍스트큐브의 모태가 되며 텍스트큐브 1.5가 태터툴즈를 대체하게 될 것이다. 그 결단을 내리기 위해서 고려해야 했던 수많은 시나리오와 가능성이 있다. 수많은 이름 상의 혼란, 기존에 만들어진 브랜드의 포기, 개발 주체들의 관계에 대한 수많은 억측의 가능성등, 어떤 시나리오도 부작용이 없는 경우가 없었다. 하지만 수많은 다른 프로젝트의 예들에서 얻은 결론이 그래야 할 순간이라고 말하고 있기 때문에 그렇게 결정했다.

텍스트큐브로 이름을 바꾸는 것은 단순히 이름의 변경을 의미하는 것은 아니다. 혼란을 충분히 감내해야 할 이유가 뒤에 자리잡고 있다. 간단하게는 외국인들에게 '태터툴즈'가 가지는 영어 어감이 좋지 않음에 대한 지적이 여러번 있어왔다거나 하는 실질적인 이유가 있다. 그렇지만 네이밍의 변경이 의도하는 것은 개발 주체와 상표의 재정의, 그리고 그로 인한 의미가 정확히 전달되는 것이다.

태터툴즈는 TNC의 상표이다. 로고는 상표권이 있고, 엄밀하게 로고와 트레이드 마크는 GPL은 아니다. 설사 TNC가 해당 상표를 자유롭게 사용하도록 하더라도 전체 소스 코드의 얼굴이 되는 상표는 소속이 있는 상태이다. 텍스트큐브로 전환하며 그 부분에 대한 메세지를 내부에 담으려고 하고 있다.

텍스트큐브 로고는 GFDL로 배포될 것이다. (국내 상표의 경우 자유로운 상표 사용을 위하여 TNC를 통해 등록 할 수 밖에 없었다. 이 나라는 개인이 '리눅스'를 상표등록해서 소송 걸기도 하는 나라 아닌가.) 공개되는 소스는 이제 상표까지 온전히 GPL을 따르게 될 것이다. 지금까지 데비안 패키징을 시도해보지 못했던 이유[footnote]GPL 하에서 데비안 패키징을 하기 위해서는 GPL의 결격 사항이 없어야 한다.[/footnote]가 사라지게 될 것이다.

그 과정을 통해서, 그 다음 단계로 나아가기 위한 시작을 밟아 나가려고 한다. 당장은 복잡해 보이는 과정이겠지만 실은 더 간단해 지기 위한 시작이며, 태터툴즈-이젠 텍스트큐브-라는 프로그램을 사용하는 것만이 아니라 프로그램에 대한 소유감과 함께 애정과 책임을 느끼는 사람들이 많아지는 세상을 꿈꾸고 있다.



지나가는 이야기라 하고서 너무 오래 머물렀다. 이제 그만 저장하고 안녕~

---

텍스트큐브 접근제어 (ACL)

머리아픈 이야기 2007/06/06 00:10 by hojin.choi

머리아픈 얘기입니다만, 텍스트큐브(구 태터툴즈)는 다음과 같은 종류의 접근하는 세력이 있습니다. 자격이라 말할 수 있겠지요.

• 블로그 관리자
• 글 쓸 수 있는 사람
• 손님

또한, 이들의 접근을 당하는 개체는 다음과 같은 종류들이 있습니다.

• 글
• 댓글
• 블로그 설정

접근하는 세력(Access Request Object)과 접근당하는 개체(Access Control Object)간의 관계를 모아 놓은 것을 접근제어목록(Access Control List; ACL)이라고 말할 수 있습니다.

태터툴즈의 공식적인 코드에는 다중 사용자에 대한 지원이 있습니다. 이것은 팀블로깅과는 다릅니다. 하나의 데이터베이스를 둘 이상이 각자의 블로그를 운영하는 것입니다. 티스토리도 어찌보면, 다중 사용자 모델로 운영되는 태터툴즈라고 생각할 수 있습니다.

이제 새로이 나올 1.5에서는 팀블로깅이 지원되는데, 따로 운영되는 블로그 여럿이 아닌, 하나의 블로그에 대한 글쓰기, 자기글에 대한 수정/삭제 기능이 지원됩니다. 게다가 오픈아이디를 통해서 접근하는 세력도 비슷한 범주에 넣어 구별할 수 있게 됩니다.

예상되는 시나리오는 다음과 같군요.

철수는 "멋진 블로그"에 글쓰기 권한을 가진 블로거입니다. 자신의 ID로 로그인을 하여 글을 쓰고 공개하였습니다. 그리고, 영희가 그 글에 댓글을 남겼습니다. 아차 싶어 댓글을 수정합니다.

이런 기본적인 동작에 대해서 다음과 같은 접근권한이 동작합니다.

1. 철수는 멋진 블로그에 접근하여 "손님"이란 자격을 얻습니다.
2. 철수는 로그인하면서 "글을 쓸 수 있는 사람" 이란 자격을 얻게 됩니다.
3. 철수는 글 쓰기 메뉴를 선택합니다.
4. 철수는 글을 쓰고 저장후 공개하기를 선택합니다.
5. 영희는 멋진 블로그에 접근하여 기본적인 "손님"이란 자격을 얻게 됩니다.
6. 영희는 글을 읽고 댓글을 씁니다.
7. 영희는 자신이 쓴 글을 수정합니다.
   

간단히 텍스트큐브에서 사용될 ACL에 대해서 끄적여봤습니다. 여기에 OpenID가 살짝 올라탑니다.

---

Sense Reader 오픈 케이스

차가운 이야기 2007/06/05 20:00 by graphittie

시각장애인용 국산 스크린 리더인 Sense Reader가 오늘 도착했습니다. 혼신의 힘을 다해 현관문을 두드리는 택배 아저씨를 반갑게 맞고 받아든 대빵 큰 상자 속에는 예쁜 패키지 디자인의 Sense Reader 하나만 덜렁 들어 있었지요.

저는 웹 접근성 문제를 시각장애인 문제를 통해 접근해왔습니다만, 기본적으로 웹서비스는 시각장애인을 위해 특별한 조치를 취할 필요는 없다고 생각합니다. 웹 접근성을 쉽게 구현할 수 있도록 해주는 웹 표준이 이미 존재하기 때문에, 웹 서비스에서는 다른 생각 없이 이 웹 표준에 맞춰서 서비스를 제작하면 자연스럽게 여러 방식의 웹 접근성이 확보되기 때문입니다.

이번 Sense Reader 구매는 이런 웹 표준이 스크린 리더에서 실제로 어떻게 처리되고 있는지 확인하고 장애인의 사용성을 경험해보고자 하는 일환으로 이뤄졌습니다. Textcube의 기능이 Sense Reader 기능에 맞춰 제작되는 것은 아닙니다...

그럼 오픈 케이스 사진을 감상해 보시죠.

매뉴얼이 전부 점자로 제작되어 있어(너무 당연한...) 읽을 수가 없었기 때문에 앞으로 삽질을 많이 해야겠습니다. Sense Reader 개발사인 엑스비전 테크놀로지(XVision Technology)는 시각장애인 개발자 분들께서 모여 설립한 회사라고 합니다.

---

세상 또 한쪽의 편견

즐거운 이야기 2007/06/04 04:36 by LonnieNa

세상엔 편견아닌 편견이 많이 있습니다.


지난 태터캠프에서 gofeel님(gofeel님이 아닌 다른분 이었나?)과도 잠깐 우스게 소리로 스쳐간 이야기가 있지만,
여자둘이 손을 잡거나, 팔짱을끼고 가면,..
저 두 여자는 아주 친하구나, 우정이 깊은가봐 등등의 생각을 하게 됩니다.
그러나 그 상황을 남자끼리 하고 간다면 주변의 시선은 어떠한가요?
저부터도 미를친넘 이라고 생각합니다. 심하게는 혹시 남자끼리 어쩌고 저쩌고 하나? 라는 생각도.. '_'

상황이 상황인지라,
여자혼자서는 영화 잘 봅니다. 개인적으로 여자혼자 영화보는것 꽤 괜찮다고 생각합니다.
근데 남자혼자 영화보면, 저건 백수인가(?) 왕따냐? 뭐하는 넘이지?

두번째는, 여자둘이 영화를 봅니다.
이 상황은 위의 여자둘이 손을 잡고 가는 상황의 생각과 비슷하죠.

세번째는, 4~5명이상의 여자들이 영화를 같이 보러왔습니다.
뭐.. 별 생각없습니다.
저중에 하나 작업(?)걸어볼까 하는생각을..=_=;;





그럼,
위의 상황에 남자를 투입해보겠습니다.
결과는..
뭐 말하지 않아도...
남자 둘이서 영화보러간다 하면,
그건 그렇다치고, 갈 수도 있죠. 다른 사람들의 시선이 중요한가요?
내가 떳떳하면 되는거구요. 정말 친한친구일 수도 있죠.
근데 4~5명의 남자가 영화만 보고 나왔다.
단순 목적이 영화만이었다면...

웃기지 않나요?


개인적인 편견인건가.
암튼 다른건 몰라도 저는, 남자 둘이 손잡고 사람들 많은 거리를 걷기엔 내심 자신감이 없답니다~
한번 해보세요.
그리고 주의를 둘러보세요. ㅜ'

그 편견이 나만의 생각이 아니었음을 확인하는 계기가 될 수도 있습니다.
다만 그 편견이 없어보이는 경우가 있습니다.



그건 아마도 세상에서 제일 무서운, 무관심이겠죠.
어느 누가 그랬더랍니다.
나는 그렇게 하고 길을 걸었는데, 사람들은 별로 나를 이상하게 보지 않던데?
그래?
그럼 너한테 그 사람들이 무관심했던거야..
그럼, 나 왕따 당한거야?
..
..
아니..
그건, 너가 못생겨서 그래.. -_-;

다음 이야기는 무관심이 될수도 있겠네요.


p.s. 앨리스도 담배를 피지 말라는법은 없답니다.

---