컨퍼런스가 있어서 샌프란시스코에 출장을 갔다왔는데 주말을 이용해서 출장일정보다 조금 더 일찍 갔다왔다. 여유시간동안 쇼핑도 하고 여기 저기 돌아다녔지만 관광이 주 목적이 아니었기에 meetup사이트에 가서 갈만한게 있는지 계속 검색해 봤다.(나중에 보니 Eventbrite도 같이 검색해 보는게 좋을듯...) 사실 혼자가서는 외국인과 대화할 일이 별로 없기 때문에 꼭 기술관련 밋업이 아니더라도 갈만한게 있으면 갈 생각이었지만 딱히 갈만한 건 눈에 띄지 않았는데 베이지역의 d3 유저그룹에서 d3 dat app이라는 밋업을 한다는 것을 알게 되어서 갔다가 왔다.

d3.js는 관심기술이기도 했으니 참가하기 딱 좋은 밋업이었다. 사실 신청할 때 대기자가 몇십명정도 있어서 기대안하고 신청버튼을 눌렀는데 내가 잘못봤는지 어땠는지 참가승인이 나서 낮에 관광을 갖다가 와서 저녁에 냉큼 다녀왔다. 뭐 관광지라서 저녁에 걸어다녀도 위험하진 않았다. 뭐 아무래도 영어로 발표하다 보니 다 이해하진 못했고 대충이나마 적고 내가 잘못 이해하거나 중요한 부분을 빠뜨렸을 가능성도 높다.

Application building with D3 - John Firebaugh

• 발표자료

이 발표는 밋업에서 봤지만 아마도 HTML5 Developer Conference에서 발표한 내용과 동일한 듯 한다. 이 발표는 오픈스트리트맵의 맵 에디터로 d3기반으로 만든 iD라는 맵 에디터에 대한 얘기였다. 일반적으로는 jQuery나 Backbone.js등으로 웹 어플리케이션을 만들고 좀 더 최신기술을 사용하는 경우에는 ember나 angular.js를 사용하지만 iD는 이런 것들이 아니라 d3.js를 기반으로 만들었다. jQuery와 d3를 비교했을 때 Dimension관련 부분은 jQuery에만 있지만 데이터 바인딩은 D3에만 있고 그 외 Ajax, CSS, 이벤트등 대부분의 기능은 양쪽 모두에 존재한다.

d3.js를 선택한 이유는 선언적인 방법이 명령형(imperative) 방법보다 좋기 때문이고 jQuery가 명령형이라면 d3.js는 선언적이다. 프레임워크는 비즈니스 로직은 프리젠테이션 로직에서 분리하기 쉽게 해주는데 backbone.js는 이부분이 개발자의 몫이고 ember나 angular.js는 스마트 템플릿을 사용하고 있다. d3에서는 3단계로 이뤄지는데 "진입(enter) -> 갱신(update) -> 종료(exit)"로 이뤄진다. 여기서 작업을 최소화 하기 위해서는 다음 규칙을 따르면 된다.

• 정적 프로퍼티는 진입 단계에서 선언한다.
• 동적 프로퍼티는 갱신 단계에서 선언한다.
• 대량 갱신은 개별적인 "instance changed" 이벤트를 사용하지 않는다.
• 실제로 변경되는 요소의 선택을 필터링한다.

iD에서 모델은 불변객체이므로 변경하지 않고 변경해야 할 경우에는 새로운 객체로 만들고 히스토리를 관리하고 있다.

그리고 d3.js의 단점 중 하나는 너무 크다는 것인데 이는 smash로 필요한 파일들만 가져와서 빌드할 수 있다.(써본적은 없지만 smash도 d3.js를 만든 Mike Bostock이 만든 도구로 이미 d3.js도 이를 사용해서 빌드하고 있다.) 앞에서도 말했듯이 dimension관련 부분이 d3.js에 없는 것도 하나의 단점인데 이는 직접 플러그인을 작성할 수 있고 d3 플러그인은 d3-plugins나 d3-bootstrap에서 찾아볼 수 있다.

Pick technology that fits your problem domain.

.append() IT TO THE LIMIT - HIGH performance d3 - Victor Powell

• 발표자료 & 데모

d3 사용할 때 퍼포펀스 향상에 대한 얘기였는데 d3를 자세히 몰라서 그런지 제대로 잘 이해해지는 못했다. 최적화를 할때는 언제 최적화를 하고 언제 최적화를 하지 않을 것인지가 중요한데 이는 대부분 개발자 시간이 CPU 시간보다 크기 때문이다.

"Premature optimization is the root of all evil" - 도널드 크누스

setInterval()보다는 requestAnimationFrame()를 이용한 transition()이 낫고 크기를 변경할 때는 redraw하는 것보다 scala(X,Y)이 낫고 transform보다는 cx, cy를 이용하는게 빠르다. 그리고 왠만하면 DOM은 건드리지 않는게 좋은데 특히 계산된 프로퍼티는 조작하지 않는 것이 좋다. 그리고 값을 변경할 때 변경되지 않은 요소들은 미리 필터링하는 것이 성능에 좋다.

기타...

메인 발표는 위의 두 가지였고 유저그룹이다 보니 이후부터는 공유할 거리가 있는 사람들이 5분 10분씩 나와서 자신들이 한 작업들을 공유했는데 유저그룹에서 이런 진행은 자유스럽고 좋아보였다.

Sara Quigley가 University of California System Campuses라는 캘리포니아 대학의 예산관련 비쥬얼라이제이션을 보여주었는데 그래프와 인터렉션을 깔끔하게 잘 만들었다. 이 인터렉션을 위해서 사용자가 어떤 값을 선택할 때 인터렉션을 보여주는 전략에 대해서 Strategic Dilemmas와 Strategy Spaces를 소개해 줬는데 잘 모르는 분야라 흥미로웠다.

CrowdSound라는 사이트를 준비하고 있는걸 보여주었는데 컨퍼런스 같은데서 청중들이 질문들을 올리고 발표자가 여기에 피드백할 수 있는(백채널이라고 하나?) 시스템에 대해서 보여주었는데 딱히 큰 건 없었다.

이 유저그룹에서 샌프란시스코의 교통수단인 Bart에 대한 비쥬얼라이제이션 사이트 Visualizing the BART Labor Dispute를 보여주었는데 실질적인 데이터로 유저그룹에서 저런 사이트를 만든게 재미있었다.(서울데이터로도 저런걸 만들 수 있을라나?) d3-tip을 쓰냐면서 좋으니까 꼭 쓰라고 했는데 이건 차트에서 툴팁 띄워줄대 유용할듯하다.