H3 참관기

작년에 이어 올해도 운이 좋게 등록할 수 있어서 H3에 다녀왔습니다.

예상한 시간보다 늦게 도착하게 되어 처음의 키노트는 생략하고 바로 첫 번째 세션부터 듣게 되었습니다.

모두의 도구로 프로토 타이핑을 시작하라

처음 이 세션을 선택했던 이유는 KTH라는 곳에서는 어떻게 프로토 타이핑을 하고, 모두가 사용할 수 있는 free한(가격과 팀에 관련된 모두가 자유롭게) 도구는 무엇일까 궁금해서 듣게 되었습니다.

이 세션을 발표하신 분의 팀에서는 evernote와 fireworks를 사용해서 프로토 타입을 만들고 공유하는 방식을 사용했습니다.

두 가지 도구의 특징은 다음과 같습니다.

evernote

• 전 세계 인구 중 3천4백만 사용
• 어느 환경에서나 사용이 가능 (모바일, PC 등)
• 공유 가능 (온라인으로 협업을 용이 하게 할 수 있다)
• 음성및 데이터 파일을 저장할 수 있다.
• 하나의 노트 파일은 50mb가 한계
• 버전 관리 가능
• 노티 기능이 있어 기존 데이터 파일을 복구 가능하다.
• 검색 기능 제공
• PDF 검색 가능함 (mac에서만 지원)
• fw.png 검색도 가능함.
• 암호화 가능(특정 부분에 암호를 걸 수 있다.)

기울임 으로 표시되어 있는 부분은 모두 프리미엄 서비스를 사용 시 이용가능한 서비스입니다.

fireworks

• 크로스 플랫폼 가능 (환경에 제약이 없음)
• 페이지 기능
• 포토샵으로 작성시한페이지당 한 장씩의 이미지를 만들어야 해서 document 작성 시 부적합
• 하나의 페이지 안에 여러 장의 이미지를 포함
• 150+ 이상의 파일을 하나의 페이지 안에 작성 가능
• 마스터 페이지 안에 하위 페이지를 둘 수 있다.
• 마스터 페이지는 모든 페이지에 공통된 기능을 가지고 있다.
• 에버노트에서 불러올 수 있다.
• 보는것은 포토샵이나 파이어웍스를 사용하지 않고 바로 볼 수 있다.
• 에버노트에서 불러온 파일을 수정할 수 있다.
• 파이워웍스로 포토샵을 쓰지 않고 수정가능
• 파일 크기가 작아진다.
• 심볼 기능
• 심볼로 만든 후 라이브러리에 등록할 수 있다.
• 등록된 심볼은 하나를 변경하면 그것이 포함되어 있는 페이지에서 동일하게 변경된다.
• common library 를 만들어 팀 작업할 때 불러와 쓸 수 있다.
• 에버노트에 파일 넣으면 동기화를 쉽게 할 수 있다.

느낌

우선 아쉬웠던 점은 위에 적은 기대들을 많이 충족 시키지 못했습니다. free한 도구들을 기대했었는데 저희 같이 작은 회사에서는 프로토타이핑을 하기 위해서 두 가지 도구를 구입 하기에는 부담이 되는 금액이었고, 실제로 프로토 타이핑을 작성하면서 생기는 문제점이나 사례들을 듣고 싶었는데 그런부분이 없었다는 점이 아쉬웠습니다

좋았던 점은 두 가지 도구를 사용할 수 있다면, 프로토 타이핑 자체보다 디자이너와 개발자 간의 피드백을 더 활성화 할 수 있겠다는 생각이 들었습니다.

우리가 모르는 node.js로 할 수 있는 몇 가지

node.js는 작년부터 관심이 있었는데, node.js로 무엇인가 재밌는걸 만들었다는 이야기에 혹해서 듣게 된 세션입니다.

이 세션은 발표자 분이 작년 피드백을 받고 “다 아는 내용이다!” 라는 이야기에 충격을 받아서 지루한 이야기를 하지 않겠다! 라는 이야기로 시작되었습니다.

총 3가지를 소개해 주셨습니다.

locally

• local 에서 서버를 쉽게 띄우기 위해 만듬
• node-optimist
• connect

하루프레스

• Static page Blog engine
• markdown -> html 로 생성
• Octopress 기능을 많이 따옴
• 1000라인 정도로 구현
• robotskirt (markdown library)
• ejs (template engine)
• twitter bootstrap
• shower

HTML5 와 Node.js 그리고 Arduino 를 이용한 홈 오토메이션

• node.js 와 arduino를 이용해 가전제품을 원격 제어 할 수 있는 것을 만들었다.
• 언제 어디서 원격 제어 가능
• 원하는 설정을 통해 온도가 적정이상 올라가거나 한다면 그 이상 올라가지 않게 가전 제품을 제어 할 수 있다.
• 웹에서 무엇을 켰는지 알 수 있고 그 사용량을 조회 할 수 있다.
• 음성인식을 사용 해서 제어 할수 있다. (현재는 크롬에서만 제공함)
• duino
• node 에서 arduino를 제어할 수 있는 framework
• web socket 사용
• twitter 를 이용해 제어 가능
• MAC OS에 의존성이 있다. (아직 멀티 플랫폼 지원은 하지 않음)
• data visualization 이 가능하도록 기획하고 있다.

느낌

보여주셨던 3가지 프로젝트 중에 제일 관심이 갔던 건 3번째 홈 오토메이션 이었는데, 하드웨어와 연동해서 실제 생활에서 활용할만 것들이었습니다. 그리고 개인적으로 최근에 미니 컴퓨터로 인기를 얻고 있는 resberry pi 를 사용해서 무엇을 만들어 볼까 고민하고 있던 차에 이번 세션을 들어서 좋았습니다.

로그 속에 있는 사용자 발자국 들여다 보기

로그에 관련된 지식이 부족하고, 로그를 분석해서 어떻게 시스템을 효율적으로 바꿀 수 있는지에 대한 이야기를 듣고자 세션을 듣게 되었습니다.

발표자 분의 전문 분야는 공간분석(GIS)으로, 평소에 분석하는걸 즐기셨다고 합니다. 발표전 간단한 예로 자신의 트위터 분석을 해본 결과 본의 아니게 진보성향자라 민간인 사찰 대상이 아니겠느냐는 걱정을 한다는 농담으로 시작되었습니다.

• 공간분석 사례
• 홍수
• 서울시장 선거분석
• 야구 관중 지도
• 카페, 음식점 분석

로그 속 사용자 발자국 찾기

• 예전에는 손 분석을 많이 했었다.
• DAISY (KTH에서 제작)
• Data를 수집/정제/분석을 위한 인프라 및 서비스 분석 플랫폼
• open source 기반

사용자가 말해주는 서비스 라이프 타임

• 114 전국전화
• 사용자 맞춤 정보를 제공해 주고 싶다.
• 낮 12시 밤 6시에 peak
• 시간을 쪼개고 그룹을 나눔
• 맞춤형 정보 제공
• 글로벌 사진 기반 SNS 푸딩2
• 인기사진 - 라이프 타임 그래프를 살펴본 결과 아마존 서버를 사용해서 아시아권 사용자들이 사용하는 시간과 배치하는 시간이 달랐다는걸 알 수 있었다.
• 동티모르 에피소드 - 타임존이 동티모르로 되어 있었던 경우 (LG(안드로이드기반) 옵티머스가 범인 )

통계 속 진실 혹은 거짓

• 유유제약회사 사례
• 사용자 로그분석을 하기 이전까지는 주력제품의 경쟁 제품이 경쟁사의 유사 제품이라고 생각하고 마케팅 했으나, 로그분석 이후 경쟁 제품이 계란이나 소고기임을 알아내고 마케팅 방향을 전환함.
• 치킨과 축구경기와의 관계
• 114의 로그를 이용해서 열대아와 주문의 상관관계를 분석하다가 음식점 전화번호를 많이 물어본날은 날씨보다 특정한 이벤트가 있던 날인걸 알게 됨.

느낌

기대 했던것은 시스템 로그를 기반으로 한 분석이었는데, 사용자 로그 분석이었다는 점이 아쉬운점이었습니다. 그래도 시장 조사나 마케팅을 위해서 사용자 로그 분석 활용 방안을 알게된 게 좋았습니다.

Three.js로 시작하는 WebGL

HTML5의 속성인 canvas 위에서 돌아가는 WebGL은 특별한 플러그인 설치 없이 브라우저에서 3차원 그래픽을 사용할 수 있습니다. OpenGL ES 2.0을 기반으로 돌아가는 WebGL을 배우기 위해서는 여러 가지 진입 장벽이 높은데, 비교적(?) WebGL에 비해서 쉬운 Three.js를 이용한 활용법에 혹 해서 듣게 되었습니다.

WebGL

• 웹 브라우저에서 제공하는 3차원 그래픽 자바스크립트 API
• 별도의 다른 플러그인이 필요 없음
• GPU 가속 지원
• IE를 제외한 최신 브라우저에서 지원함
• 모바일 브라우저는 아직 지원하지 않음
• (openGl(oepnGL ES(WebGL)))

Three.js

• 3차원 그래픽 왕초보를 위한 경량 자바스크립트 라이브러리
• 370kb로 작음

주변 상황

• 3D는 대세
• CSS 쉐이더
• 하드웨어와 네트워크의 발전
• 스크립트 언어의 발전
• 3D 하드웨어의 발전
• 게임
• 데이터 시각화
• 모델 뷰어
• 모델 편집

느낌

발표자 분이 작년 처음 WebGL을 접했을때는 많은 양의 코드에도 불구하고 삼각형 하나를 띄우는 거라 좌절해서 접을까 했는데, 작년 경품추첨 프로그램을 짜면서 다시 흥미를 가졌다는 이야기에 Three.js가 WebGL 비해 얼마가 얼마나 손쉽게 접근이 가능하길래 라는 의문이 들었습니다. 세션을 다 듣고 난후에는 WebGL을 자체는 배우기 버거워 보였는데, Three.js를 이용하면 기본적인 개념을 공부하고 접근하기에는 쉽다는 생각이 들었습니다.

아쉬웠던 점은 세션의 시간에 비해 전반적인 내용을 다 이야기 하려다 보니 굉장히 빠른속도의 진행으로 세션을 따라가기 힘들었습니다.(이건 개인적인 문제일 수도 있겠네요..)

행복한 개발을 위한 테스트 케이스

평소 TDD에 관심이 많지만 실제로는 거의 사용해 보지 못하고 있어서, 현업에의 활용방안을 알고 싶어서 세션을 듣게 되었습니다.

삽질이 싫어요!

가치 있고 생산성 있게 머리쓰는 개발을 하고 싶다.

디버깅은 삽질이 아니다.

하지만 삽질스런 디버깅은 싫다.

버그

• 기존 코드에서
• 추가 코드에서

발생과 인지 간격이 멀수록 삽질스러워 진다.

빠른 버그 인지!

• 행복한 개발의 핵심
• 유일한 방법은 오직 테스트 케이스

영향도 분석?

• 불가능하다.
• 어려운 게 아니라 아예 불가능

테스트 케이스의 목적

• 새로운 버그의 발생을 즉시 파악

테스트 코드?

• 작업 후 동작 확인 위한 코드
• 보통은 System.out.println() 혹은 직접 손으로 확인
• 테스트 케이스가 아니다. - 버그의 발생을 파악할 수 없다.

JUnit을 쓰면 테스트 케이스인가?

• 단지 쓰는것만으로는 아니다.

테스트 케이스란?

• 재사용 가능해야 한다.
• 자동화 가능해야 한다.
• 수정된/추가된 코드로 인하여 기존 코드에 버그가 발생하지 않았음을 보장할 수 있는 효율적인 유일한 방법
• 개발자 스스로 지금, 전부 실행시킬 수 있어야 한다.
• 삽질을 방지하자는 것

테스트 케이스는 목숨을 걸고 지켜야 한다.

• 실패 1개가 있었으면 (100 -1 =0)
• 테스트 케이스를 아예 안 돌린다.
• 작업한 코드를 검증하지 않는다.
• 신규 버그를 알지 못한다.
• 심지어 버그를 알고도 커밋한다. *전부 성공하던지 아예 없다.

손으로 해야 한다면 확인 안 한다.

• 시간, 복잡, 게으름, 몰라서

시스템 테스트, 혹은 QA

• 효율적이지 않다.
• 최소한의 대응이다.

뭔가 수정되었다면 수정된 것의 동작 기존것의 동작 확인은 당연.

추가되는 테스트 케이스

• 추가된 코드 동작 확인
• 추후 기존 코드 동작 확인

커밋의 조건

• 컴파일 성공
• 테스트 전부 성공
• 컴파일 경고 없어야함
• 커버리지 만족
• 컴파일 경고와 커버리지도 마찬가지

행복하지 않은 현실은?

• 테스트 케이스가 없다.
• 가짜 테스트 케이스 (가짜로 통과만)
• 실패하는 테스트 케이스
• 꺠지기 쉬운 테스트 케이스 (알지만 손이 많아가고 귀찮아서)
• 기반 전제에 기인
• 개발자 개인이 극복 어렵다.

프로젝트 차원으로 지원해야 (관리자, 경영자의 의지가 있어야 함, 관리자 경영자를 꺠우치게 해야 한다)

• 일정
• 테스트 용이한 아키텍처
• 편의성 있는 프레임웍

비용?

• 상상: 테스트 케이스 작성 비용 + 순간적 버그 필스 비용(~=0)
• 현실: 0 + 추후 버그 픽스 비용 + more more (사실 여러 가지로 마이너스 효과가 일어남)
• 일정은 어떻게든 극복될 것 같습니다. 비용이란 측면에서
• 한 곳 수정하면 온같 곳 다 신경 써야 하는…
• 아키텍처의 문제 - 모듈 간에 너무 끈끈, 테스트 편의성 고려하지 않음
• 각 모듈간의 의존성 제거

테스트 용이하도록

• 시스템 아키텍처
• 서브 프로젝트 간 관계
• 패키징 방법

프레임웍으로 지원해야한다.

테스트를 위한 프레임웍도 개발 범위에 포함되어야 한다.

개발자 지원

• 실제로 느끼는 것이 필요하다 - 기술적인 것이 아니다. 믿음과 경험, 감동, 습관

프로젝트 차원에서 지원하고 그보다 중요한 것은 개발자의 의지

유용할 수 있는 팁

• 테스트 케이스가 튼튼해지려면
• 기반 데이터를 전제 X
• 실행 순서를 전제 X
• 리소스를 공유 X (DB, 설정파일)
• Mock 서브시스템(DBMS) - 테스트 시 디비를 구축,
• 디비 스키마도 버전 관리,
• 테스트 시 Cassandra를 구동
• 각 테스트 케이스별 리소스 관리
• 설정 오버라이딩 - 테스트만을 위한 사항만 설정 (custom xml, properties도 오버라이딩.)
• 메소드 이름을 한글로
• 요구사항 이름의 테스트 케이스
• Jetty를 사용한 시스템 테스트 - embeddable WAS, 패키징 없이 테스트
• 시스템 테스트도 통합테스트도 자동화 해야 한다.
• 깨진 테스트 케이스 차라리 삭제.
• 깨지기 쉬운 테스트 케이스 커밋 전 리뷰를 통해 보안.

느낌

(위의 내용은 세션을 들으며 열심히 PT를 보면서 정리한 내용인데 이렇게 정리한 이유는 책에 내용이 없었기 때문입니다. 하지만 현재 모든 PT가 다 공개되어있군요..)

개념적인 부분과 실제 경험에서 나온 팁들이 좋았습니다.

기대 했던것은 어떤 기능의 한 부분을 예를 들며 실제 코드를 기반으로 TDD하는 과정이 있었으면 했었는데 그런부분이 없어서 아쉬웠습니다.

오픈소스로 개발 실력 쌓기

저는 보통 오픈소스라고 하면 어느 정도의 실력이 있고, 저같이 평범한 사람은 그냥 가져다 쓰는것에 불과하다고 생각하고 있던차에 오픈소스를 사용해서 개발 실력을 높일 수 있다는 말에 마지막은 이 세션울 들었습니다.

좋은 개발자

• 나의 삶과 주변의 삶을 기술로 변화시키는 개발자

개발자가 되기까지

• 대학교의 커리큘럼
• 학원의 커리큘럼

팀장님이 원하는 실력과 나의 실력의 차이.. 그래서 열심히 노력

보통은 자기의 분야에 대가나 유명한 작품들을 보고 공부를 하지만 프로그래머는 유명한 코드를 잘읽지 않는다.

오픈소스를 대하는 자세

• 동작 원리 분석

• 함께 만들고 싶다.

• 오픈소스 분석 (경험, Java source file 발견, 스프링 프레임웍등..)
• 빌드, 실행 (lucene을 예로 설명)
• 어떻게 빌드하지? - 빌드 스크립트를 다룰 줄 알아야 한다.(ant,maven 둥둥)
• 어떻게 IDE에 올리지? - 구글 검색
• 어떻게 실행 시키는 거지? - 테스트를 돌려보면 된다.
• 아키텍처 분석 - 어디서 부터 봐야하나? - 분석툴을 사용 (1000피트 뷰를 가져라: 넓은 관점을 가져라)
• 클래스, 메소드 분석
• 로직 및 알고리즘 분석

느낌

좋은 오픈 소스를 찾아서 그 오픈 소스의 코드를 분석하고 공부하면 실력을 높일 수 있다고 말 한 세션이었습니다. TDD와 마찬가지로 좋은 건 알지만 실제로 실천하기에는 내적으로나 외적으로 생기는 문제를 어떻게 해결하고, 그 방법을 활용할 수 있게 도달할까 하는 고민이 다시 드는 세션이었습니다.

기타 소감

올해 두 번째 H3 였는데, 이번에도 다른 개발자 콘퍼런스에 비해 좋았던 것 같습니다. 아쉬웠던 점은 제가 필요로 하다고 생각해서 들어갔는데, 예상과는 다른 내용이어서 당황한 세션들이 몇 개 있었다는 거네요.

그리고 조금 이해가 안되었던것중 하나가 처음에는 등록 접수를 받다가 키노트때는 접수를 안받고 키노트가 끝날때까지 기다린 다음에 접수를 받아서 키노트를 보고 나오는 사람들과 매우 혼란스러웠습니다. 이런 사소한 부분도 좀 신경 써줬으면 좋겠습니다.

그럼 내년 H3를 기다리며 이만 줄이겠습니다.

2012 H3 자료집

2012 H3 전체 발표자료