YDN 2회 간략한 후기

오늘(09년 8얼 25일) Yahoo! Korea에서 2번째 YDN이 있었습니다. 

이번 YDN에서는 YUI 3와 YQL을 소개 하였는데, 이에 대해 간략한 후기를 적어보도록 하겠습니다.
참고로, 이 후기는
지극히 개인적인 경험을 기반으로
지극히 개인적인 의견을 덧붙이는 것입니다.
YUI 어려워요
과거 YUI를 가지고 개발을 하는것은 사실 어려웠었습니다.
prototype.js나 jQuery처럼 Core로 사용하기에는 복잡한 Relationships와 도움이 될만한 Reference가 적었기 때문이었죠.(제공하는 Reference는 Interface(Visual적인)에 대한 것들이 대부분이 었죠)
적어도 제가 YUI를 사용해볼려고 시도를 했을때는 그랬었습니다. 어쩌면 제가 못찾은걸 수 도 있겠죠 ;p
이젠 쉬워요
YUI 3에서는 Core로 사용하여도 어려움 없이 사용할 수 있도록 Name Space가 구성되었습니다. (어쩌면 YUI 2에서 지원되었던 것일 수도 있죠.) 우리가 흔히 사용하는 prototype.js, jQuery의 그것 처럼요.
이제는 YUI로 쉽게 Event Bind할 수 있고, 쉽게 DOM을 Select할 수 있으며, 쉽게 Animation Effect를 구현할 수 있어요.

가볍고, 빨라요

발표 내용중에 “가볍고, 빠르다” 라는 내용도 있었는데

사실 다른 Libraries와 비교해서 그렇게 딸리지 않는다
내부적으로 테스트했을땐 타 Libraries와 충분히 경쟁력이 있다

라고 하셨어요.(이 부분은 제가 못들었고 같이 있던 분이 이런 말을 했다고 제게 말씀해주셨습니다.)

Rails에서 쓰고 싶은데
제가 봤을땐 이제는 나름 쓸만해졌다라고 판단이 되어, Rails에서도 사용할 수 있는 Convertor가 있냐고 질문을 했었는데 “잘 모르겠다”고 하시더군요.(이 질문이 Jenny에게 전달 되기까지 힘들었습니다 ㅠ,.ㅠ)
진입장벽
우리가 익히 사용해왔던 Prototype.js, jQuery와는 틀린 Method Names를 가지고 있기 때문에 이것을 익히는데 시간이 소모될 듯 합니다. 하지만 과거처럼 어렵게 구성이 되어 있지 않아 쉽게 넘을 수 있을것 같습니다.
사실 이러한 진입장벽은 새로운것을 배울때 소모되는 지극히 당연한 기회비용이죠.

YUI에서는 축약식 Naming을 사용합니다.
예를들면 Drog&Drop기능을 “dd”로 선언하더군요.
이런류의 축약식 Naming은 양날의 검이죠. 코드를 짜는 사람의 입장에서는 쉽게 타이핑 할 수 있지만.. YUI를 잘 모르는 사람이 code를 보면 이게 무슨말인지 알 수 없으니 말입니다.
그리고 개인적으로 이런식의 Naming을 좋아하지 않습니다.

선입견을 버릴 수 있다면

“무겁다”, “느리다”, “어렵다” 이러한 YUI의 선입견만 버린다면
한번 사용해보는것도 나쁘지 않을 듯 합니다. (물런 실험정신 및 확인정신(사실인지)가 조금은 필요합니다. ;p)
YQL

오해

사실 저는 Pipes가 생긴게 ERD같아서 설계할때 사용하는 UML같은 것인줄 알았었습니다. 그런데 그런것이 전혀 아니더군요. Data Collector(?)이고(자세한 설명이 필요하신분은 @phphloveme님께 질문을!)
YQL은 Pipes의 개발자용 업그레이드 버전이라고 축약할 수 있겠습니다.
Query날려서 Web상에 있는 Data를!
SQL과 비슷한 문법으로 Query를 날려 Data를 Collect해오는 것이 YQL입니다.
Crawler를 만들거나 API를 통해서 Data를 Collect해오는것을 만드는것은 사실 귀찮은 일인데, Query만 날리면 바로 값을 Return해주죠.
오! 귀찮은 일을 줄여주었군!
저는 “와.. 이제 Crawler랑 API랑 통신하는 코드 안짜도 되겠다! 만세!!”라고 생각하며 기쁜마음으로 어느정도의 트래픽이나 규모를 감당할 수 있느냐고 질문을 했었는데

이건 Data가 어떻게 모이나?(혹은 보이나?) 정도로 사용할 수 있는 Prototype용으로 사용할 수 있는 서비스

라고 하시더군요. 어떤 질문자분께서

사용해봤더니 하루에 4000K 트래픽밖에 허용이 안된다

라며 불만을 표하시기도 했었습니다.

재미는 있을 것 같은데, Prototype을 위한 서비스여서..
Prototype을 위한 서비스라 트래픽, 규모, 안정성 부분에 한계가 있어, YQL을 이용해서 서비스를 개발하기엔 무리가 있는것 같습니다.

결국은 내가 다 만들어야해
결국엔 Crawler나 API랑 통신하는 코드 다 짜야한다는 결론이 나옵니다.
이러한 결론을 도출하고 보니 YQL의 매력과 흥미가 사라지더군요.

추가
정진호님께서 제가 했던 YQL의 질문에 대한 답변을 정정해주셨습니다.

Pipes 와 YQL이 트래픽의 제한이 있지만
반드시 프로토타입 제작에만 사용되는 것은 아닙니다.즉, YQL을 이용해 가져오는 데이터는
그 특성상 실시간 업데이트될 확률이 적습니다.
따라서 자체적으로 데이터를 일정 부분 캐싱하는 알고리즘을
이용하면 도움이 됩니다.

참고로 야후 본사쪽에서는 외부 파트너의 컨텐츠를
YQL로 가져와서 캐싱을 한 후에 실제 서비스에 이용하고 있습니다.

따라서 실시간 데이터 업데이트가 아닌
데이터의 수집/가공 영역에서 YQL을 사용해 보시기를 권해 드립니다.

오.. 그렇다면 저의 바람되로 귀찮은 일이 줄어드는 것이네요
물런 fallbacks를 마련해야겠죠?

효율과 한계는?
자 여기서 원래 할려고 했던 질문을 다시 정진호님께 해야 할 것 같네요.

1. 직접 Crawler나 API랑 통신하는 코드를 짜는데 시간을 들이고 안정적으로 Data를 Collect하는것 Vs YQL을 이용해서 빠르게 Collector를 만들지만, 속도와 안정성 측면에서는 모험을 해야 하는것
이 둘을 비교했을때 어떤것이 더 효율이 있을까요? (혹은 어느 수준까지는 YQL이 좋다)

2. YQL의 안정성이나 속도에 대한 통계수치가 나와 있는지 궁금합니다.

3. Query가 날라갔을때 그때 직접 Data를 Collect해오는것인지? 아니면 Cached Data를 가져오는 것인지도 궁금하구요

자.. 한줄요약

YUI 3는 쓸만해졌고, YQL은 재미있는 물건이지만 이걸가지고 뭔가 하기엔 무리가 있다. 재미있는 물건으로 잘만 활용한다면 기획자와 개발자에게 엄청 큰 도움(?)을 줄 것이지만, 안정성과 속도에서는 검증이 되었는지 잘 모르겠다.(이 부분은 정진호님께서 답변을 해주세요~ ㅎㅎ)

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중