이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.
Archive for WebDevelopment
April 21, 2007 at 11:52 pm · Filed under WebDevelopment, WebPlan, WebStandard
슬슬, 마이크로포맷도 수면위로 올라오는 듯 하다.
마이크로포맷을 웹페이지에 적용할 때 주의해야 할 몇가지.
1. AJAX나 DHTML로 마이크로포맷을 만들지 말 것.
물론, 웹브라우저나, OS단에서는 AJAX등으로 만들어지는 마이크로포맷도 충분히 처리할 수 있지만, 여전히 마이크로포맷의 목표는 (Human Readable) Machine Feed이기 때문에 AJAX등을 해석할 수 없는 기계에서도 읽을 수 있도록 JavaScript와 무관하게 HTML안에 마이크로포맷이 들어있어야 한다.
2. 당연한 이야기지만 표준 마크업을 준수해야 한다.
마이크로포맷은 상당히 플렉서블한 구조이긴 하나 어디까지나 표준 HTML을 준수해야만 한다. 마이크로포맷파서는 기본적으로 표준HTML을 파싱할 것을 가정하기 때문에, 마이크로포맷자체가 표준HTML 마크업을 따르지 않을 경우 파싱이 잘못될 수 있다.
3. 보이는 것이 전부는 아닐 수 있다.
CSS를 잘 이용하면, 마이크로포맷을 웹페이지에 적용했을 때, 사람의 눈에 보이는 부분외에도 숨겨진 정보를 제공할 수 있다. 당연히 시맨틱한 마크업이 우선되어야 하며, CSS로 제어가능해야한다.
4. WYSIWYG는 쥐약.
현존하는 WYSIWYG HTML에디터들은 마이크로포맷을 제대로 반영할 수 없다. 마이크로포맷이 필요한 컨텐트는 아직까지 손으로, 혹은 별도의 템플릿을 이용해서 마크업해야 한다.
일단 만들어진 마이크로포맷도 WYSIWYG 에디터를 이용하게 되면 포맷이 깨질 수 있다.
아마도 마이크로포맷을 위한 진화된 WYSIWYG - 이정도라면 이미 WYSIWYM이겠지만 - 을 만들어내면 대박… 
April 18, 2007 at 6:44 pm · Filed under WebDevelopment
1. 5시간 동안 이유없는 버그에 시달리다가 결국 소스 코드를 한 줄씩 쫓아가며 찾아본 결과 디렉토리의 퍼미션 문제로 판명. 이런 제길…
교훈 : 타인에게 배포할 라이브러리에는 친절한 Assertion이 반드시 필요하다. 에러가 나는 것을 감추려 들지 말 것. 어디가 문제인지 알아야 고치지…
2. timezone관련 루틴이 필요해서 뒤져보다가 php를 판올림해야 함을 알았다. 그러나 php 판올림 대신 관련 라이브러리를 직접 제작하려다 보니…
한시간이면 판올림했을 것을, 서너시간 걸려도 필요한 기능의 반도 못 구현했다.
교훈 : 결정은 빨리 내려야 한다.
어제오늘의 삽질목록…
April 9, 2007 at 4:00 pm · Filed under WebDevelopment, WebPlan, WebStandard, WorldWideWoops
웹사이트의 단축키를 위한 조언.
1. 사용하지 마라.
웹사이트의 단축키는 접근성과 편의성을 올려줄 수도 있지만, 그 반대일 경우도 많다.
가장 좋은 것은 단축키를 제공하지 않는 것이다. 표준 인터페이스만을 지키는 것이 좋다. accesskey는 계륵이나 마찬가지.
2. 사용자의 환경을 가정하지 마라.
사용자는 Windows XP + IE6만을 쓰는 것은 아니다. 대놓고, “우리는 Windows XP + IE6만 지원해요”라고 써놓지 않았다면, 사용자의 환경을 마음대로 추측해서 가정하면 안된다.
이것은 단지, “OSX와 FF도 고려해주세요..” 라는 뜻은 아니다.
예를 들어 어떤 사용자는 당신이 한번도 경험해보지 못했던 스크린리더를 이용하는 시각장애인일 수도 있다.
또 어떤 사용자는, 손에 익은 개발환경을 위해 수많은 단축키로 구동되는 어플리케이션을 사용하는 하드코어 개발자일 수도 있다.
당신이 이정도면 IE와 FF에서 무리없이 돌아갈 거라고 설정해놓은 단축키들은 사용자가 이미 다른 용도로 사용하고 있었던 단축키일 수도 있다.
3. 단축키에만 의존하지 마라.
애플아이폰에서 사파리로 웹서핑하는 사용자도 있을 수 있고, Wibro용 카PC에서 웹서핑하는 사용자도 있을 수 있다. 터치스크린에서 단축키를 쓴다거나, 운전중에 단축키를 사용할 수 있을까? 핵심기능이 단축키로 제공된다는 것은 접근성면에 심각한 장애를 준다.
4. 사용자를 시험에 들게 하지 마라.
제 아무리 편리한 단축키라 해도 단축키를 외우는 것은 사용자에게 쉬운 일은 아니다.
정말 우리 서비스는 겨우 7개의 단축키만 알고 있으면 되는데… 라고 할지라도, 사용자는 당신의 서비스만 쓰는 것은 아니다. 이 서비스에서는 이 단축키, 저 서비스에서는 저 단축키… 사용자가 편리하라고 제공하는 단축키인가? 아니면, 개발자인 당신이 편리하라고 제공하는 단축키인가?
5. 단축키를 사용자가 지정할 수 있도록 하라.
꼭 단축키를 제공하고 싶다면, 사용자가 지정할 수 있게 하라. default 키 조합을 제공하되, 키 조합을 바꿀 수 있는 수단을 제공하라. 그래야 사용자가 자신이 진짜로 손에 익은 단축키를 설정해서 사용할 수 있다. 그렇지 않은 단축키들은 모두 나름 UX 제고를 가장한 기획자와 개발자의 자기만족일 뿐이다.
March 28, 2007 at 10:35 am · Filed under WebDevelopment, WebPlan
엊그제, OpenID Consumer는 사용자마다 복수의 OpenID를 허용해야 한다는 이야기를 하자마자, myid.net이 잠깐 중단되었었다고 한다. 국내에는 현재 알려진 OpenID Provider는 myid.net이 유일한 상태에서 me2day나 springnote, lifepod(이건 아직 안열었지만) 등이 OpenID”만”을 지원하는 현실에 많은 이들이 불편해했을 듯 하다.
OpenID Provider가 365X24 무결점으로 돌아가면 제일 좋겠으나 그건 불가능하고, 결국 Consumer측에서 이러한 사고에 대한 준비가 되어있어야 한다. 각 사용자별로 복수의 OpenID를 하나의 계정에 등록해둘 수 있게 하여 필요할 때마다 추가, 변경, 취소가 가능해야하며, 각각에 대한 delegation도 가능해야겠다.
좋은 OpenID Consumer가 되려면 품이 많이 든다. 어쩌면 기존의 아이디/패스워드보다 더 공이 많이 들어야 하리라. 이럴 때일 수록, 최초에 도입하는 트렌드 리더들이 더 꼼꼼한 모습을 보여야 하겠다.
March 25, 2007 at 4:13 pm · Filed under WebDevelopment, WebPlan
최근, 스프링노트의 delegation 문제에 대해 고민하다가(내가 왜… 남의 서비스에 대해 고민을… -_-a) OpenID 컨슈머 구현시 delegation 부분과 관련하여 더 나은 사용성을 제공하는 방법에 대해 생각해보게 되었습니다.
1. What is my OpenID?
아주 원초적인 문제입니다만, 나의 OpenID Account URL은 무엇일까요?
여기 eouia.myid.net이라는 OpenID Account를 가지고 있는 사용자가 하나 있다고 합시다. 이 사용자는 OpenID를 제법 잘 이해하고 있어서, 재미없는(?) myid.net이라는 도메인 대신 자신을 더 잘 identifying해줄 수 있는 http://dnzin.com을 delegated URL로 쓰고 있다고 하지요.
이제, OpenID인증이 필요한 곳마다, 이 사용자는, eouia.myid.net과 dnzin.com 두 가지 중의 한가지를 입력하는 선택을 해야 합니다. 사용자는 두가지 URL이 모두 유효하며 동일한 사용성을 가지는, 동등한 인식키라고 생각할 것입니다. 즉, dnzin.com은 eouia.myid.net의 alias라고 여기겠지요.
그렇다면, Consumer측에서는 이러한 사용자를 위해 어떻게 해야 할까요?
간단하게는
- 입력받은 URL을 방문해서 openid server와 delegation정보(만약 있다면)를 받아와 진짜 OpenID URL을 확인한 후, 해당 정보로 OpenID 인증을 시도합니다.
겉으로 보기에는 이것으로 끝이겠지만, 실제로 뒷단에서는 조금 골치아픈 일이 생길 수 있습니다.
이 사용자의 unique id로써 무엇을 DB에 저장해야 할까요? (계정을 생성하고 유지하기 위해서는 DB에 해당 사용자의 세션을 만들 필요가 있으므로…)
아마도 eouia.myid.net을 이 사용자에 대한 unique id로 잡는 것이 상식적일 것입니다.
그래야만, 사용자가 delegation을 바꾸더라도 동일한 account를 유지할 수 있을테니까요.
예를 들어, 사용자가 http://dnzin.com 대신, http://eouia.com으로 블로그를 바꾸면서 delegation도 바꾸었습니다. 이런 경우에도, 사용자는 delegation을 통해 새로운 http://eouia.com으로도, 새로운 가입절차 없이 이전과 동일한 계정에 로그인할 수 있기를 원할 겁니다.
따라서, Consumer측에서는 로그인시에, 입력받은 URL이 OpenID일거라고 가정하고 바로 DB에 저장된 값과 비교하는 대신, 반드시 해당 URL을 방문해서 delegation 정보를 획득하여 매번 OpenID 인증을 시도해야만 합니다.
현재 스프링노트에서는, 가입시에는 delegation 처리를 하지만, 로그인시에는 delegation 처리를 건너뛰고 있는 듯 합니다. 또는, 조금 있다가 따로 이야기 하겠지만, 사용자의 unique id로 실제 openid url대신 사용자로부터 최초 입력받은 url을 키값으로 쓰고 있을지도요. (버그 게시판의 답변을 미루어보자면 그런 듯… 실제로 안이 어떻게 구현되어있을지 저는 모르죠. ^_^)
여기까지는 가장 기본적인 Consumer 구현법입니다만, 실제로는 좀 문제가 있습니다.
2. How to change my OpenID?
이 사용자가 어느날, myid.net은 싫어… 라며 다른 OpenID Provider로 자신의 OpenID를 바꾸게 되었습니다. 그럴 일이 있겠냐구요? 어느날 myid.net이 없어지거나, 혹은 더 좋은 OpenID Provider가 생겼다거나, 혹은 myid.net이 SRE를 지원하지 않아 불편해.. 라고 생각할 수도 있겠지요.
그래서, eouia.newopenid.com이라는 새로운 OpenID 계정을 사용하기로 결심했습니다. 그래도 delegation을 통해 이전처럼 eouia.com이라는 url로 동일하게 로그인이 가능할 거라고 기대하겠지요. (delegation의 장점이죠.)
그런데, Consumer측에서는 문제가 생겼습니다. 사용자 계정 정보를 실제 OpenID URL(eouia.myid.net)을 키값으로 삼고 있었는데, 전혀 다른 새로운 OpenID URL(eouia.newopenid.com)이 들어오면 이것이 동일한 사용자라고 판단할 수 없기 때문입니다.
그렇다면, 역시 DB의 키값으로는 최초 입력받은 URL을 키값으로 삼는 것이 해결책이라고 생각할 수도 있겠지만… 이 경우에는 delegated URL을 바꿨을 때가 문제가 됩니다. (1번 참조)
결국, 이 사용자에 대한 unique id로 OpenID URL도, delegated URL도 사용하기 곤란한 상황이 됩니다.
3. multiple OpenID
그렇다면, 아예 DB의 유니크한 키값으로 URL을 쓰지 않는 방법이 가능하겠죠.
사용자는 언제든지 사용하고 있는 OpenID를 변경할 수 있고, delegate URL도 바뀔 수 있으며, 그 모든 경우에 대해 동일한 사용자로 인정받기를 원할 수 있습니다.
하지만 한편으로는, 동일한 OpenID에 대해 별개의 Persona의 개념을 원할 수도 있지요. (이 부분은 다른 기회에 다시…)
뿐만 아니라 인증 자체가 내가 컨트롤 할 수 없는 Provider쪽의 시스템을 이용하는 것이기 때문에, 별도의 안전장치를 필요로 합니다. 예를 들어, 어느날 갑자기 myid.net의 인증서버가 고장이 난다면, myid.net을 이용하던 사용자들은 다른 Consumer서비스를 전혀 이용할 수 없게 됩니다. 마른 하늘의 날벼락이죠. (OpenID Provider들이 더 늘어난다면 분명 이러한 문제가 생길 경우도 예상할 수 있습니다.)
따라서 친절한 Consumer라면 이러한 문제들을 해결하기 위해 다음과 같은 방법을 고려해야 합니다.
1) 하나의 계정당 복수개의 OpenID를 등록해서 사용할 수 있게 할 것.
2) 기존의 계정에 새로운 OpenID를 추가등록할 수 있게 할 것.
3) 물론 당연히 각각의 등록된 OpenID에 대해 delegation을 허용할 것.
4) 사용자가 등록된 OpenID를 삭제할 수 있을 것.
4)이 좀 이해가 안갈 수도 있을테니 부가설명 들어갑니다.
여기, eouia.com이라는 도메인을 가지고 있는 사용자가 있습니다. 자신의 OpenID로 eouia.com을 사용하고 있었는데, 깜박 잊고 도메인 연장을 하지 않아 타인에게 이 도메인을 빼앗겼습니다. 그 후, eouia.com을 획득한 타인이 역시 자신의 OpenID로 해당 도메인을 사용하고, 이를 이용해 이전 사용자의 인증을 도용한다면 어떻게 될까요. 이런 경우를 막기 위해서 사용자는 자신의 OpenID를 서비스에서 삭제할 수 있어야 합니다. (혹은, 추후 OpenID 스펙에, 해당 URL은 더이상 유효하지 않음을 Consumer들에게 알리는 프로토콜이 들어가는 방법도 있겠지요.)
4. Best Practice
어쨌거나 이러한 프로세스를 Consumer에서 제공하기 위해서는 사용자별로 OpenID를 unique id로 잡아서는 안되겠지요. 사실, openid만 사용가능한 서비스들(국내의 경우라면 스프링노트나 미투데이 등)은 아마 대부분 이런 식으로 구현될텐데, OpenID만 사용가능하게 하는 것이 사용자 정책적으로 전혀 바람직하지 않을 뿐더러, 실제로 운용에 있어 위에 언급한 바와 같은 문제점들이 발생할 수 있습니다. 그런 면에서 본다면, 왜 스프링노트나 미투데이 등이 OpenID 전용으로만 서비스하는지 조금 이해하기 어렵습니다. (정식 오픈때도 설마 OpenID전용은 아니겠지요.)
결론내리자면,
1) 단일 OpenID URL에 종속적인 인증은 사용자의 사용성을 저해할 수 있습니다.
2) 서비스 설계시 OpenID의 변경 가능성 및 복수 이용에 대해 열려있어야 합니다.
3) 결정적으로 OpenID에만 의존하는 인증방법은 바람직하지 않습니다. OpenID외에도 인증방법은 여러가지가 있을테니까요. (1년 서비스하고 말거면 뭐 상관없겠습니다만.)
March 20, 2007 at 4:45 pm · Filed under WebDevelopment, WebPlan, WorldWideWoops
뭐가 잘났다를 떠나서,
이런 형태가 갑자기 주목받는 이유는, 네이버도, 이글루스도, 태터툴즈도 daily Archive를 지원하지 않아서가 아닐까?
반대로, Blogger.com이나 MovableType이 인기를 끌지 못해서가 아닐까?
옛날에는 그런 스타일의 블로깅이 제법 흔했었는데, 눈깜짝할 사이 어느새 individual Entry Archive가 한국 블로그의 대세가 되버린 듯. 그리고 그에 대한 반동.
March 20, 2007 at 2:00 am · Filed under WebDevelopment
몇가지가 있긴 하다.
1. 아직 완벽하게 익히지 못했다.
그렇다고 다른 랭귀지가 완벽하냐. 그건 절대 아니고, 가장 기초적인 syntax grammar조차도 일부러 안외우고 그때그때 레퍼런스에 의존하는 나로서는 RoR에 대해 충분할 만큼 레퍼런스를 숙지하지 못했다는 뜻. 사실, 아래의 변명들은 결국 이 이유에서 파생된다.
2. RoR의 생산성을 자신할 수 없다.
확실히, 단순한(?) 모델링에서 RoR이 멋짐을 깨달았지만, 복잡도가 증가할 수록 다른 수단과의 격차가 점점 줄어들드라. 이게 나의 잘못인지, 아니면 애초에 복잡계에서의 작업량 수렴의 한계치가 정해져있는 것인지는 아직 미정.
3. 이미 프레임워크를 쓰고 있다.
결국, RoR은 컨벤션의 통일에 의한 효율성과 메타프로그래밍의 용이성이 장점인 듯 한데, 아예 프레임워크를 안썼으면 모를까, 이미 다른 개발환경에서도 프레임워크를 쓰고 있는 나로서는 그다지 엄청난 마법의 지팡이같은 생각은 안든다. 예를 들자면, 코드가 좀 지저분하긴 해도 php로도 충분히 버금가는 퍼포먼스의 프레임워크가 존재할 수 있다. 심지어 비슷한 컨벤셔널 룰로.
4. I’m not native
Ruby 코드의 가독성이 좋다고 하던데, 왜 그런 이야기가 나오는지 수긍이 가긴 하지만, 뭐랄까, 문어체 스타일. 영어가 네이티브가 아닌 나로서는 소위 말하는 Fortran류의 수식형 코드쪽이 더 이해하기 쉽다. 아아, 네이티브 급의 개발자 분들에게는 아무 상관없고 오히려 장점이겠지만.
여튼, Ruby코드보다는 차라리 Perl코드가 더 잘 눈에 들어오는 구식 개발자라서 그런가 보다.
5. 이게 진짜 이유인데..
RoR로 한게 고작 그 정도야? 라는 평가를 스스로 내리거나 남들로부터 듣고 싶지 않기에… 사실, 별로… 남들이 해놓은 RoR도 그 코스트등을 곰곰히 살펴보면, 그다지 Agile하거나 Rapid하지도 않더라… 라는 걱정.
March 16, 2007 at 5:52 pm · Filed under WebDevelopment, WebPlan
바로 앞의 포스트와는 반대되는 이야기일 수도 있는데,
개인적으로 웹페이지에 단축키를 넣는 것을 그닥 바람직하게 생각하지 않는다. 왜냐하면 웹사이트는 사용자의 경험과 환경을 알 수 없기 때문에, 때로는 과잉 친절은 전혀 의도하지 않은 부작용을 낳을 수도 있기 때문이다.
예를 들어, “Ctrl + Space”를 중요한 단축키로 사용하는 어떤 서비스가 있다고 하자. 이것은 대개의 경우에 사용하는데 아무런 문제가 없지만, Mac사용자는(그리고 혹시 OS단에서 이미 선점하는 다른 어떤 환경에서도) 해당 기능을 사용할 수 없다. 왜냐하면 Ctrl+Space는 Mac OSX의 중요한 기능 중 하나인 Spotlight를 위해 예약되어있기 때문이다.
시각장애인들의 경우에도 비슷한데, 이들이 사용하는 각종 보조장치/프로그램의 단축키가 제법 많아서 웹페이지의 단축키와 충돌하는 경우들이 있기 때문이다.
확실히 단축키는 편리하긴 하지만, 그래서 더욱 조심스럽게 접근해야만 한다. 일단 단축키 없이 이용가능해야 하는 점이 가장 중요하고, 단축키를 사용할 때에는 기존의 사용자경험과 상충되지 않는지 확인해야만 한다. 그러나 사용자의 경험은 모두 제각각인데 어떻게 해결할 수 있을까.
가장 좋은 해결책은 아마도, 단축키 재정의가 사용자마다 가능하도록 하는 것. 사용자의 경험을 존중하는 서비스들이 많아지길.
March 16, 2007 at 5:42 pm · Filed under WebDevelopment, WebPlan, WorldWideWoops
현재까지 쓸만한 WYSIWYM 웹 에디터는 WymEditor가 유일했는데, 모 사의 모 클로즈드 베타 서비스를 사용해보니 WYM을 아주 간단하면서도 상콤하게 구현해놓았다.
Wiki이기 때문에 간단하면서도 상콤하게 WYM이 가능했던 것일까? 애초에 내가 생각했던 WYM의 문제점은 사용자들의 비시맨틱마크업에 대한 욕구를 어떻게 풀어나갈 것인가였는데, Wiki는 애초에 그것이 필요가 없으니까.
발상의 전환이랄까… 처음부터 안돼!라고 해서 사용자를 길들이는 것이 그렇게 힘든 일은 아닐 것 같다. 확실히 무지개 알록달록을 원하는 사용자들이 많긴 하지만, 그 요구를 들어줘야 하는 타당한 이유를 찾을 수 가 없다. (소비자는 왕이지만 폭군이 되도록 놔두는 것이 옳은 것은 아니라고 생각.)
아무튼, 훌륭하네. 간만에 괜찮은 서비스를 봤다.
자세히 보니 WYM이 아니라, 그냥 WYSIWYG다. -_-a
February 26, 2007 at 1:51 pm · Filed under WebDevelopment
가끔 헷갈렸는데 정리해본다.
1. URL로 특정된 HTML type 문서가 로딩된다.
2. HTML이 파싱된다.
3. link, script로 연결된 외부 스타일쉬트와 스크립트가 로딩된다.
4. 이상의 내용을 토대로 DOM이 만들어진다.(스크립트도 실행)
5. 만들어진 DOM을 브라우저에서 사용자에게 출력한다.
6. 이미지 및 외부 컨텐트가 로딩된다.
ps. window.onload 이벤트는 어느 시점에서 발생하는 걸까?
상식적으로 생각해보면 6번? 5번?
Next entries »