오늘(09년 8얼 25일) Yahoo! Korea에서 2번째 YDN이 있었습니다. 
이젠 쉬워요
Rails에서 쓰고 싶은데
진입장벽
우리가 익히 사용해왔던 Prototype.js, jQuery와는 틀린 Method Names를 가지고 있기 때문에 이것을 익히는데 시간이 소모될 듯 합니다. 하지만 과거처럼 어렵게 구성이 되어 있지 않아 쉽게 넘을 수 있을것 같습니다.
사실 이러한 진입장벽은 새로운것을 배울때 소모되는 지극히 당연한 기회비용이죠.
YUI에서는 축약식 Naming을 사용합니다.
예를들면 Drog&Drop기능을 "dd"로 선언하더군요.
이런류의 축약식 Naming은 양날의 검이죠. 코드를 짜는 사람의 입장에서는 쉽게 타이핑 할 수 있지만.. YUI를 잘 모르는 사람이 code를 보면 이게 무슨말인지 알 수 없으니 말입니다.
그리고 개인적으로 이런식의 Naming을 좋아하지 않습니다.
선입견을 버릴 수 있다면
Query날려서 Web상에 있는 Data를!
SQL과 비슷한 문법으로 Query를 날려 Data를 Collect해오는 것이 YQL입니다.
Crawler를 만들거나 API를 통해서 Data를 Collect해오는것을 만드는것은 사실 귀찮은 일인데, Query만 날리면 바로 값을 Return해주죠.
오! 귀찮은 일을 줄여주었군!
추가
정진호님께서 제가 했던 YQL의 질문에 대한 답변을 정정해주셨습니다.
물런 fallbacks를 마련해야겠죠?
효율과 한계는?
자 여기서 원래 할려고 했던 질문을 다시 정진호님께 해야 할 것 같네요.
1. 직접 Crawler나 API랑 통신하는 코드를 짜는데 시간을 들이고 안정적으로 Data를 Collect하는것 Vs YQL을 이용해서 빠르게 Collector를 만들지만, 속도와 안정성 측면에서는 모험을 해야 하는것
이 둘을 비교했을때 어떤것이 더 효율이 있을까요? (혹은 어느 수준까지는 YQL이 좋다)
2. YQL의 안정성이나 속도에 대한 통계수치가 나와 있는지 궁금합니다.
3. Query가 날라갔을때 그때 직접 Data를 Collect해오는것인지? 아니면 Cached Data를 가져오는 것인지도 궁금하구요
자.. 한줄요약
YUI 3는 쓸만해졌고, YQL은재미있는 물건이지만 이걸가지고 뭔가 하기엔 무리가 있다. 재미있는 물건으로 잘만 활용한다면 기획자와 개발자에게 엄청 큰 도움(?)을 줄 것이지만, 안정성과 속도에서는 검증이 되었는지 잘 모르겠다.(이 부분은 정진호님께서 답변을 해주세요~ ㅎㅎ)
참고로, 이 후기는
지극히 개인적인 경험을 기반으로
지극히 개인적인 의견을 덧붙이는 것입니다.
YUI 어려워요
과거 YUI를 가지고 개발을 하는것은 사실 어려웠었습니다.
과거 YUI를 가지고 개발을 하는것은 사실 어려웠었습니다.
prototype.js나 jQuery처럼 Core로 사용하기에는 복잡한 Relationships와 도움이 될만한 Reference가 적었기 때문이었죠.(제공하는 Reference는 Interface(Visual적인)에 대한 것들이 대부분이 었죠)
적어도 제가 YUI를 사용해볼려고 시도를 했을때는 그랬었습니다. 어쩌면 제가 못찾은걸 수 도 있겠죠 ;p
적어도 제가 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)
한번 사용해보는것도 나쁘지 않을 듯 합니다. (물런 실험정신 및 확인정신(사실인지)가 조금은 필요합니다. ;p)
사실 저는 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의 매력과 흥미가 사라지더군요.
재미는 있을 것 같은데,
결국은 내가 다 만들어야해
결국엔 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은
'웹[기술|표준|접근] > 그 외' 카테고리의 다른 글
| YDN 2회 간략한 후기 (5) | 2009/08/26 |
|---|---|
| SUBVERSION CLIENT FOR THE MAC (0) | 2009/02/11 |
| KCSC 불법정보(사이트)에 대한 차단 안내. (4) | 2008/10/24 |
| 브라우저 춘추전국시대가 아닌 엔진춘추전국시대 (0) | 2008/09/04 |
| 구글 크롬을 잠깐 써보니.. (0) | 2008/09/03 |
| Firefox3가 나오면서 개발자가 한번쯤 읽어봄직한 문서 (0) | 2008/06/23 |
TRACKBACK http://hiphapis.net/trackback/165
-
hiphapis의 생각 삭제
2009/08/26 00:23TRACKBACK FROM hiphapis' me2DAYYUI 3는 쓸만해졌고, YQL은 재미있는 물건이지만 이걸가지고 뭔가 하기엔 무리가 있다.
-
[후기] 야후 개발자 네트워크 Tech Talk : YUI/YQL 활용하기 삭제
2009/08/26 12:44TRACKBACK FROM 야후! 코리아 개발자 네트워크2009.8.25(화) 밤. 삼성동 야후!코리아 사무실에서는 “YUI/YQL 활용하기” 라는 주제로 야후 개발자 네트워크 Tech Talk가 열렸습니다. 원래는 야후! 본사에서 근무하는 두분의 개발자를 모시고 진행하는 것이었는데 한 분이 지난주 태국여행 중 댕기열이라는 열대모기로 전염되는 열병으로 입원, 급히 제가 대신 Pipes/YQL강사로 투입되는 해프닝이 벌어지기도 했습니다. 주중 퇴근 후 진행되는 개발자 이벤트의 특...
댓글을 달아 주세요
요한님! 참석해 주셔서 감사합니다.
2009/08/26 12:36 [ ADDR : EDIT/ DEL : REPLY ]선물 당첨 되신 것도 축하드리구요.
행사 후 요한님의 질문에 대해 다시한번 생각해 보니
Pipes 와 YQL이 트래픽의 제한이 있지만
반드시 프로토타입 제작에만 사용되는 것은 아닙니다.
즉, YQL을 이용해 가져오는 데이터는
그 특성상 실시간 업데이트될 확률이 적습니다.
따라서 자체적으로 데이터를 일정 부분 캐싱하는 알고리즘을
이용하면 도움이 됩니다.
참고로 야후 본사쪽에서는 외부 파트너의 컨텐츠를
YQL로 가져와서 캐싱을 한 후에 실제 서비스에 이용하고 있습니다.
따라서 실시간 데이터 업데이트가 아닌
데이터의 수집/가공 영역에서 YQL을 사용해 보시기를 권해 드립니다.
그리고 다른 질문자의 내용중 4000K는
Y!Pipes가 한번에 가져 올수 있는 HTML Page의 크기입니다.
정확한 수치는 본사 개발팀을 통해 확인 해 보겠습니다.
감사합니다.
다음에 다시 뵙겠습니다.
오랜만에 갔던 워크샵이어서 즐거웠었습니다.
2009/08/26 14:30 [ ADDR : EDIT/ DEL ]그리고 정정해주신 답변은 본문에 반영하였습니다.
이렇게 신경 써 주셔서 고마워요
참! 트랙백 이벤트 참여 하세요.
2009/08/26 12:39 [ ADDR : EDIT/ DEL : REPLY ]구형 가방을 받은 분들을 위해
상품은 신형 타거스 가방입니다.
무게가 50% 가벼워 졌답니다. ㅎㅎ
오오오옷!!!
2009/08/26 14:31 [ ADDR : EDIT/ DEL ]바로 트랙백 날렸습니다! :p
이벤트 당첨! 축하드립니다.
2009/09/07 10:31 [ ADDR : EDIT/ DEL : REPLY ]선물을 받으실 수 있도록 아래 포스팅 참고하셔서
주소를 메일로 보내 주세요. 빨리요! ^^
http://ydnkrblog.com/blog/?p=609
감사합니다~