Search results for 'ETC'

Android M Developer Preview2 설치

2015.07.25 14:22

안드로이드 M 개발자 프리뷰가 나오고 두달이 됐고, 더이상 미뤘다가는 정식판이 나와야 설치할 것 같아 잠시 시간을 내어 설치했다. 첫 설치이기 때문에 OTA로는 설치가 안되고 컴퓨터에 연결해서 설치했고 그 과정을 간단히 정리한다.


0. 실행 환경

- PC: Mac / Yosemite (크게 중요하진 않을 듯)

- Device: Nexus 9


1. 매뉴얼: https://developers.google.com/android/nexus/images#instructions


2. android-sdk 설치

- sdk tools only 만 설치

- 설치 후 README에 있는대로 tools/android update sdk --no-ui 실행


3. 기기별 이미지 다운로드

- 다운로드 페이지: https://developer.android.com/preview/download.html

- 다운로드 후 압축 품


4. 기기에서 개발자 모드 활성화

- http://developer.android.com/tools/device.html

- 설정 > 시스템 > 태블릿 정보 > 빌드 번호 7번 클릭


5. 기기의 설정 > 시스템 > 개발자 옵션에서 oem 잠금 해제 사용하도록 체크


6. adb reboot bootloader


7. fastboot oem unlock

- 보증이 되지 않는다는 메시지가 나오지만 무시하고 진행


8. 기기별 이미지의 압축을 푼 디렉토리에 가서 sudo flash-all.sh 스크립트 실행

- 이 방법이 실패하여 다른 방법을 시도


9. 직접 image file을 업로드

- 참고 문서: http://www.androidpolice.com/2014/11/12/running-into-the-dreaded-missing-system-img-error-flashing-android-5-0-factory-images-heres-how-to-get-around-it/

- unzip image-volantis-MPZ79M.zip

- fastboot flash bootloader bootloader-flounder-3.47.0.0132.img

- fastboot reboot-bootloader

- fastboot flash recovery recovery.img

- fastboot flash boot boot.img

- fastboot flash system system.img

- fastboot flash vendor vendor.img

- fastboot flash cache cache.img

- fastboot reboot

10. 업그레이드 완료


Android 개발 환경이 설치되어 있지 않아 Android SDK 다운로드 등에 시간이 걸려 이틀에 걸쳐서 진행했는데 이런 과정을 다 합쳐도 두시간 이상 걸릴 것 같지는 않다. OS 업그레이드만 한다면 15분에서 20분이면 충분할 것으로 보인다.


곧 Developer Preview 3 버전이 나올 예정이고 (7월 하순 예정) 3Q 내에 최종 버전이 나올 예정이므로 Developer Preview를 설치하려고 마음 먹었던 사람이면 서두르는 편이 좋을 것 같다.





nundefined ETC Android, Android M, developer preview, Nexus 9, 개발자 프리뷰, 안드로이드

우리가 일하는 방법

2015.07.01 00:47

우리 팀은 JavaScript를 사용하여 웹 서비스나 회사 내부의 도구를 만드는 팀이다. 회사에 JavaScript를 전문적으로 사용하는 조직이 처음 만들어진 것이라 과거의 유산을 받을 필요 없이 팀의 개발 방법을 처음부터 하나하나 만들 수 있었다. 이 글에서는 팀을 만들면서 우리가 만들었던 개발 방법을  간단하게 정리한다.


처음 팀이 만들어졌을 때 우리 앞에는 과거 2~3년간 같이 업무를 같이 했다는 경험과 Github이 있었다. 경험은 각자가 가진 생각의 이질감을 줄이는데 도움이 됐고 과거의 경험으로부터 가져올 것과 버릴 것을 결정할 때도 도움이 됐다. Github은 그 자체로써 멋진 도구라는 공감대를 갖고 있었고 이전 회사에서도 SVN 대신 Git으로 이전하기 위한 논의를 진행한 적이 있기에 이견 없이 Github을 사용하기로 결정했다.


그리고 나서 가장 처음 시작한 작업은 Coding Conventions를 정하는 일이었다. 이전 회사에서 사용하던 conventions도 머릿속에 있었고 손에도 익었지만 그만큼 단점도 알고 있었기에 새로운 우리만의 conventions을 만들기로 결정했다. Conventions을 만들 때는 Google의 JavaScript Style Guide 를 기본으로 삼았다. 다양한 내용이 잘 정리되어 있다는 점에 모두의 의견이 일치했기 때문이다. 하지만 우리의 경험이나 선호도에 비춰 생각했을 때 우리와 맞지 않다고 생각하는 요소는 적절히 수정했다. Conventions를 어느 정도 만든 후에는 Github에 팀 전용의 계정을 만들고 conventions를 저장할 독립적인 저장소를 만들었다. 그리고 conventions을 markdown 형식의 문서로 만들고 저장하여 해당 저장소에 접근하기만 하면 언제든 내용을 확인할 수 있도록 했다.


업무에 사용할 에디터를 결정하고 열심히 만든 conventions를 지킬 수 있는 보조 도구를 에디터에 추가하는 것도 잊지 않았다. JavaScript를 개발하기에 좋은 에디터는 상당히 많지만 팀에서 권장하는 에디터는 Sublime Text 에디터다. 가볍기도 하거니와 확장성이 좋으며 개인이 구매해도 기업에서 사용할 수 있는 유연한 라이선스 정책을 갖고 있기 때문이다. (반대의 경우는 불가능하다.) 그리고 단축키로 conventions를 한 번에 정리할 수 있도록 플러그인을 만들었다. 또한 Jslint를 사용하여 자동으로 lint의 결과가 에디터에 반영되도록 했다. JavaScript를 사용한 개발 과정에 컴파일과 같은 과정은 없지만 lint 과정을 추가함으로써 오류가 발생할 수 있는 가능성을 낮출 수 있도록 했다.


Github의 경우 업무에서 사용해본 경험은 없지만 모두들 개인적으로 사용해본 경험이 있기에 일반적인 사용법은 크게 문제되지 않았다. 브랜치의 사용을 장려하는 Git의 특성상 브랜치의 관리 방법에 대해 논의를 했는데 생각보다 쉽게 결론이 내려졌다. 바로 GitFlow에서 사용하는 방식을 적용하는 것이었다. - 구체적인 방법에 대해서는 A successful Git branching model를 참고하기 바란다. - 우리의 경우 develop 브랜치를 중심으로 구현해야 할 기능별로 브랜치를 따고 개발한 후 develop에 머지하고 develop 브랜치에서 master 브랜치로 옮긴 후 배포를 진행하는 것을 핵심적인 방법으로 결정했다. 이 과정에서 GitFlow를 직접 사용할지 여부는 개발자가 결정하도록 했다.


Github을 사용하는 방법을 고민할 때 가장 고민을 많이 했던 부분은 코드 리뷰를 업무 과정에 녹이는 방법이었다. 각 개발자가 업무나 강의를 통해서 코드 리뷰가 가지는 장점에 대해 너무 잘 이해하고 있었기에 코드 리뷰를 업무 과정 중에 자연스럽고도 강제적으로 진행되도록 업무 과정을 짜고 싶었다. 처음 고민했던 것은 팀 저장소를 각 개인의 저장소에 포크하여 개발한 뒤 팀 저장소로 Pull Request (이하 PR)을 보내는 방식이었다. 그리고 PR을 받은 리뷰어들이 코드를 리뷰한 후 모두 동의하면 코드를 머지하는 방법이었다. 그런데 이런 방법을 택할 경우 저장소간 소스의 이동이 매우 번거롭다는 문제에 부딛혔다. 또한 로컬 컴퓨터로 체크아웃 하는 과정 자체가 포크와 유사한데 개인 저장소가 중간에 끼게 된다면 불필요하게 저장소를 복제하는 과정이 추가된다는 점도 쉽게 받아들이지 못한 이유였다. 여러 테스트 끝에 서로 다른 브랜치 사이에서 PR를 보낼 수 있다는 사실을 발견했다. - 지금 생각하면 당연한 이야기지만 다들 Github을 개인적으로만 사용했고 여러명이 사용한 경험이 없었기에 한참 돌아갈 수 밖에 없었다. - 그리고 이 방법이 불필요한 저장소의 생성을 막고 자연스럽게 리뷰할 수 있는 좋은 방법이라는데 다들 동의했다. 특히 Github의 PR 기능은 코드 리뷰를 하고 의견을 주고 받기에 매우 편리했다. 브랜치의 이름을 따는 방법에 대해서도 많은 이야기를 했는데 최종적으로 기능을 개발할 때는 'feature/기능명' 정도로만 브랜치의 이름을 정하는 수준으로 정리했다.


이런 방법에 따라 업무를 진행하면 다음과 같은 순서가 된다.

  1. 서로가 개발해야 하는 기능을 나누고 develop 브랜치에서 각 기능별 브랜치를 만든다. 반드시 develop을 기본 브랜치로 삼아야 하는 것은 아니다.
  2. 기능을 구현한다.
  3. 기능 구현이 완료되면 소스 코드를 팀 저장소의 기능별 브랜치로 push하고 develop 브랜치로 PR을 날린다.
  4. 해당 기능을 구현하지 않은 사람이 코드를 리뷰하며 코멘트를 단다. 해당 기능을 구현한 사람은 코멘트에 따라 코드를 수정하거나 본인이 작성한 코드가 더 나은 코드임을 리뷰어에게 설명하고 설득한다. 이 과정에서 온라인으로 진행이 어렵다고 판단하거나 직접 설명하는 것이 효과적이라고 생각하는 경우 직접 이야기를 하기도 한다.
  5. 리뷰 과정에서 리뷰어 사이에 의견이 나뉠 경우 서로 설득한다. 옳고 그름의 문제가 아니라 호불호의 문제인 경우 다수결을 따르기도 한다.
  6. 코드의 리뷰를 완료한 리뷰어는 리뷰를 완료했다는 사실을 표시하고 마지막으로 코드의 리뷰를 완료한 사람이 코드를 머지하고 브랜치를 삭제한다. 이 때 사전 협의 없이는 PR을 날린 사람이 자신이 작성한 코드를 머지하지 않는다.
  7. 리뷰 과정에서 문제가 발생하거나 코드를 머지하기에 충분하지 않다고 판단하는 경우 PR을 닫고 수정 과정을 거친 후 다시 PR을 날린다.
  8. 리뷰 과정 중 머지를 해서는 안되는 경우에는 PR을 닫거나 라벨을 이용하여 머지하면 안되는 PR임을 표시한다.


리뷰를 업무 과정의 필수인 방식으로 업무를 진행하면서 발생한 문제점도 있다. 예를 들어 리뷰어가 짝수이면서 의견의 충돌이 발생했을 때 의견의 조율이 어려운 경우가 있다. 그리고 리뷰를 하는데 생각보다 많은 시간이 걸린다는 점이다.


리뷰어가 짝수여서 의견 조율이 어려운 문제는 리뷰어를 홀수로 바꾸면서 자연스럽게 해결했다. 물론 하나의 소스 코드를 다수의 리뷰어가 보면 그만큼 리뷰에 걸리는 총 시간이 늘어나므로 무조건 많은 리뷰어를 배정하는 것이 좋은 것은 아니다. 하나의 PR을 리뷰하는데 적당한 인원은 3명이라고 생각한다. 물론 이 숫자는 리뷰어의 숙련도 등 여러 조건에 의해 변경할 수 있을 것이다.


리뷰에 시간이 많이 걸리는 점은 특별한 해결법이 없다는 생각을 하고 있다. 경험상 하나의 PR을 리뷰할 때 걸리는 시간은 리뷰어당 코드 작성 시간의 30% 정도이다. 따라서 3명이 리뷰를 하게 되면 리뷰에 걸리는 총 시간은 코드 작성 시간과 맞먹는 셈이 된다. 이 시간은 코드의 리뷰 후 수정된 코드를 다시 리뷰하는 과정에 필요한 시간까지 포함된 시간으로 머지까지 소요되는 총 시간이라고 할 수 있다. 시간적인 여유가 있을 때는 별다른 문제가 되지 않으나 업무 막바지와 같이 시간에 쫓기는 상황에서는 상당한 부담으로 다가올 수 있다. 이 시간을 줄이기 위해 코드를 작성한 사람이 리뷰 받을 대상 파일을 직접 지정하는 방법으로 신규 파일이나 로직의 변경이 있는 파일을 지정하기도 했다. 그러나 이미 전체 파일을 리뷰하는데 익숙하다는 점과 리뷰어도 리뷰를 통해 리뷰에 걸리는 시간을 점점 줄이게 되는 이유로 자연스럽게 이 방법은 사용하지 않게 됐다.


리뷰 과정을 통해 각 구성원들이 짜는 코드의 형태가 유사해지면서 다른 사람이 작성한 코드를 볼 때도 이질감을 없앨 수 있었다. 그리고 좋은 코드를 서로 칭찬하고 자신의 코드에 반영함으로써 각자의 실력이 향상되는 결과를 얻을 수 있었다. 반대로 수정 요청을 하는 경우 초기에는 코드 작성자의 감정이 조금씩 상하는 일도 있었으나 한, 두달의 리뷰가 계속되면서 감정이 상하는 일은 사라지고 서로 토론하고 더 좋은 방법을 찾는 분위기가 정착된 상태이다.


그러나 이 방법은 처음 팀에 합류하는 사람에게는 매우 큰 스트레스가 된다. 첫째, 리뷰라는 익숙하지 않은 업무 습관에 익숙해져야 한다. 많은 개발자들이 코드 리뷰를 시도하지만 여러 이유로 실패하곤 한다. 따라서 코드 리뷰라는 익숙하지 않은 개발 방법과 리뷰로 인해 필요한 일정 문제로 많이 힘들어하고는 한다. 둘째, 리뷰하는 과정에서 코드와 자신을 분리하는데 시간이 필요하다. 초기에는 대체로 코드 리뷰를 통해 코드가 아닌 개발자를 공격하는 듯한 인상을 받는다. 특히 초기에 기존 코드에 익숙하지 않기 때문에 리뷰를 통해 다른 개발자들에 비해 상대적으로 많은 이야기를 듣게 되는데 이 과정을 지나는 일이 쉽지많은 않다. 셋째, Coding conventions과 프로그래밍 패턴에 익숙해지는 것이 쉽지 않다. 신입 개발자가 아닌 이상 기존에 본인이 사용하던 스타일이 있고 그 스타일에 익숙해져 있는 상태인데 리뷰를 통해 기존의 스타일이 부정당하는 경우가 많다. 이것을 극복하면서 팀의 패턴을 받아들이고 개선할 부분에 대해 의견을 개진하는 일은 항상 쉽지 않다.


초기에 팀이 소규모일 때 이런 방법을 만들고 팀이 성장하면서 일반적인 규모의 팀 내에서는 잘 동작하는 것을 확인할 수 있었다. 이렇게 일하는 방법을 주변에 이야기하면 대규모 팀 혹은 여러 팀으로 이루어진 조직에서는 잘 적용되기 어렵지 않느냐는 질문을 받는다. 냉정하게 이야기하면 적용해본 경험이 없으므로 무조건 잘 된다고도, 실패할 수 밖에 없다고도 이야기하기 어렵다. 쉽지는 않겠지만 일단 시도해보는 것이 중요하다고 생각하며, 편의에 따라 예외상황을 만들지 않고, 개발자들끼리 많은 이야기를 하는 것이 이 방법으로 대규모로 적용하는데 중요한 요소가 되리라 생각한다.


생각해보건데 지금의 팀을 처음 만들면서 다행이었던 점은 처음 팀이 일하는 방법을 만드는데 충분한 시간을 쓸 수 있었다는 것이다. 그리고 그 시간동안 서로가 생각하는 다양한 방법을 이야기하고 시도해볼 수 있었다. 아마 이런 경험은 과거에도 없었고 앞으로도 높은 확률로 얻기 힘든 경험이 아닐까 하는 생각을 해본다. 다른 개발자에게도 이 방법이 도움이 되면 좋겠다.


nundefined ETC git, gitflow, Github, javascript, 개발방법, 자바스크립트, 코드리뷰, 코딩컨벤션

  1. Blog Icon
    정남훈

    좋은 글 잘 읽고 갑니다.

  2. 고맙습니다~ :)

  3. 코드리뷰를 할 때 참고할만한 기사
    http://www.bloter.net/archives/238819

Google I/O 2015 두 번째 날

2015.06.11 00:38

행사의 두 번째 날이 밝았으나... 이 날은 늦잠을 자고 말았다. 맞춰둔 알람은 제대로 듣지도 못하고 정신을 차리니 시간은 10시를 향해 가고 있었다. 이 때문에 9시 세션이었던 Polymer를 놓치는 불상사가 발생. 다행히 동영상으로도 제공되는 세션이라 최악의 상황은 면할 수 있었다.



오전부터 이번 IO의 기념품(?)인 넥서스9를 나눠주고 있었다. 집에서 이미 사용 중인 테블릿이 한 대 있고 그 활용도가 높지 않은 상태라 그런지 감동같은 감성적인 생각보다는 짬내서 안드로이드 M이나 올려봐야겠다는 생각이 들었다. 아직 올려보진 못했지만. 내심 테블릿 대신 핸드폰을 바랬는지도 모르겠다.



첫째 날 세션 중에 Notifications API가 구현되어 브라우저에 추가된 내용을 발표하는 자리가 있었는데 그 활용편이다. 웹사이트에서 알림을 사용하는 예제를 보여주는 세션이었다.



Notification을 구현하기 위해 위와 같이 세 가지 API를 같이 사용하게 된다.



Service worker에서 디버깅을 하려면 위 사진의 주소를 크롬브라우저에 입력하면 된다. 지금 사용 중인 브라우저에 입력해보니 구글 IO 사이트와 medium의 Service worker가 등록되어 있다.



성능 최적화 세션에 들어왔더니 이렇게 세 가지 숫자를 보여준다.



항상 느끼는 것이지만 이 동네 사람들은 경험을 정리하고 구조화하고 이름을 붙이는 것을 잘한다는 생각이 든다. 반면 우리나라 개발자들은 개발은 잘 하지만 이런 작업에는 약하다는 생각이 든다.



사용자의 각 동작을 RAIL에 맞게 분류한 화면이다. Animation은 16ms마다, 응답은 100ms보다 짧은 시간에, 로드는 1000ms 내에 화면이 갱신되어야 한다는 것이 RAIL의 개념이다. 시간표를 짤 때 처음 제목을 보고는 Ruby on Rails를 떠올렸다. 좀 노린 것일지도 모르겠다. 물론, 설명을 보고 금방 아닌 것을 알았지만.



왼쪽의 Paul Irish(@paul_irish)와 오른쪽의 Paul Lewis(@aerotwist). 위 사진의 RAIL 세션과 이어서 진행된 성능 최적화 세션은 두 명이 메인 스피커를 번갈아가며 진행했다. 개발자들을 대상으로 하는 직업탓인지 서로 이름이 Paul이라는 농담도 해가며 재미있게 진행했다. 위 사진에 보이는 슬라이드 첫 장에 Paul Irish의 이름밖에 없자 자기의 이름도 넣어달라며 장난을 치기도 했다. Paul Irish는 그에 응해 자기 이름보다 Paul Lewis의 이름을 더 크게 넣기도. 세션 내내 흥겨운 분위기였다. 



앞 세션에서 했던 RAIL를 다시 설명하고 있다. 이번 행사에서 모바일 웹 성능 최적화에 대한 세션은 다 RAIL 키워드를 중심으로 진행됐다. 당분간은 계속 이 키워드를 사용할 듯 싶다.



이 세션은 실제로 모바일 웹 성능 최적화를 진행했던 ESPN 사이트에 대한 설명이었는데 세션의 막바지에 청중들로부터 최적화를 하기를 원하는 사이트를 받아 분석하는 과정을 간단히 보여줬다. 슬라이드에 박혀 있는 고정된 그림으로 보다가 개발자 도구를 사용하여 문제가 되는 부분을 찾아가는 것을 보니 상대적으로 잘 와닿는 느낌이랄까.



시간표에 잡아뒀던 세션을 모두 마치고 행사장을 찍어봤다. 이틀동안 진행된 행사이긴 했지만 작은 세션들의 경우 두 번씩 하는 경우가 대부분이어서 실제로 느끼는 세션의 수는 더 적었다. IO에 다년간 참석했던 다른 사람들의 이야기를 모아보면 1. 작년보다 볼만한 것이 줄어든 것 같다. 2. 웹은 이제 두 번째 기술로 삼아야 하는 듯. 3. 작년에는 강의실 형태로 구성됐었는데 이번에는 이렇게 열린 형태로 구성되며서 강의 스타일보다는 구글 개발자와 직접 이야기하며 궁금한 점을 해결하는 형태로 바뀌는 것 같다. 4. 디자인 세션이 늘어난 듯. 아마 내년에는 더 늘어나지 않을까? 5. 시작은 개발자 행사였는데 점점 개발자 행사같이 생각되지 않는다. 등등이 있었다.


개인적으로는 안드로이드(모바일)이 50%, 사물인터넷이 20%, VR/AR이 20% 나머지가 10% 이하의 비중으로 느껴졌다. 특히나 웹의 경우에는 발전 혹은 혁신이라고 생각할만한 내용이 전혀 없었다. Service worker나 Notifications같은 경우에는 이미 한참 전부터 언급되던 것이 이번에 Stable 버전에 들어간 정도라 별로 와닿지 않았다. 이미 몇 달 전 국내에서 Service worker에 대한 이야기를 들었기에 신선함이 떨어졌을 수도 있다. 안드로이드 M에서 크롬이 웹뷰 대신 들어간다는 것도 있었지만 딱히 와닿지는 않고. 이는 개발 부담을 줄이려는 시도가 아닐까 싶기도 하다. 당분간은 Specification상에 존재하는 웹은 점점 발전하겠지만 사용자가 느끼는 웹은 상당히 정체되어 있을 것 같다. 물론 여기서 말하는 웹이란 브라우저에서 동작하는 것을 의미한다.


이런 행사에 참여하면 웹페이지를 통해 보는 것보다 더 생생하게 세상의 흐름을 느낄 수 있게 되는 것 같다. 무엇보다도 같은 경험을 공유한 사람들의 생각을 들을 수 있고 웹페이지에 나올 만큼의 뉴스꺼리는 아니지만 중요한 사실들을 알 수 있게 된다. (가령, 예전에는 웹쪽 일을 했던 구글러가 이제는 사물인터넷쪽 일을 한다던가 하는...) 이런 사실들이 모여 가리키고 있는 한 방향을 몸으로 느끼게 되는 것이 아닐까. 이런 행사에 참여하는 것이 여러 모로 쉬운 일은 아니지만 기회가 올 때마다 잡을만한 가치는 있다고 본다.



그리고 구글 IO의 세션 비디오가 공개됐다. 전체 세션은 아니고 강의실같은 장소에서 진행됐던 세션의 동영상이다. 한글 자막은 없지만 영어 자막이 포함되어 있으니 [cc] 메뉴를 눌러 켜놓고 보면 도움이 될 것이다. 한글로 기계 번역하는 메뉴가 있긴 한데 추천할만한 번역은 아니므로 영어로 보는 것을 추천한다.



nundefined ETC Android, Google, google io, Polymer, Rail, 구글, 구글IO, 안드로이드, 폴리머

Google I/O 2015 첫 번째 날

2015.06.09 22:31

올해 초만 해도 막연히 올해 미국을 한 번 가보고 싶다는 흐릿한 목표만 있었다. 이번 구글 IO는 '되면 좋고 아님 말고' 정도의 생각으로 신청했는데 덜컥 당첨되어 다녀올 수 있었다. 이렇게 컨퍼런스를 다녀오면 미국에서의 흐름은 어떤지, 한국과는 어떻게 다른지를 깨달을 수 있어 도움이 되는데 이번 컨퍼런스도 마찬가지였다.



행사장인 모스콘 센터 서관 입구. 오른쪽은 등록을 위한 줄이고 왼쪽은 입장을 대기하는 줄이다. 등록은 행사 전날부터 이루어졌기에 많이 붐비지는 않았다. 등록은 전혀 기다리지 않고 진행할 수 있었다.



행사장에 들어가기 위해 줄은 필수이다. 들어보니 전날 등록을 위해서도 줄을 한참 섰다고 한다. 줄은 모스콘 센터를 둘러싸는 형태로 되어 있었으며 거의 행사장을 한바퀴 감싼듯 했다. 다른 곳에서는 커피 등 간단히 먹을 것을 나눠준 것 같은데 내가 서있는 곳에서는 전혀 발견할 수 없었다.



사람, 사람, 사람. 줄을 서있는 사람의 숫자도 많았지만 그 구성도 다양했다. 한국인도 종종 눈에 띄었고 일본인도 쉽게 발견할 수 있었다. 중국어 사용자도 상당히 많이 눈에 띄었는데 어디서 왔는지는 확인하기 어려웠다. 원래 샌프란시스코에는 중국인이 많아 이곳 사람일 수도 있다. 또한 다른 개발자 행사에 비해 여자의 비율이 꽤 높은 느낌이었다. 추첨제로 바뀌면서 여성이 일정 비율이 될 수 있도록 한 것일까? 사실 관계는 확인할 수 없지만 여성의 비율은 확실히 높았다. (그런데 왜 위 사진에는 모두 남자만..;; )



사진에는 안나와 있지만 줄을 서있는 도중 줄의 끝을 알 수 없는 문제가 발생했다. 스태프가 줄 끝에 서있어야 하는데 줄 끝을 알고 있는 스태프가 아무도 없었던 것. 스태프에게 어디가 제대로 된 줄이냐며 묻는 사람들이 있었다. 그래도 소리지르는 사람은 하나도 없었다. 정말로 문의하는 수준. 그리고 크게 화내지도 않고 조용히 기다리는 모습이었다. 스태프가 어딘가를 갔다 오더니 곧 정리를 해줬기에 문제는 곧 해결됐다. 하지만 아직 내가 섰던 줄이 제대로 된 줄이었는지는 잘 모르겠다. 스태프가 좀 어리바리한 느낌이었음.



행사 시간이 다 되어 입장하는 중이다. 미동하지 않는 줄에 서있다가 줄이 줄어들기 시작하니 시작한다는 기대감에 즐거워지기 시작했다. 여기가 거의 입구 바로 앞인데 내가 입장한 후에도 상당히 많은 사람들이 계속 입장했다.



행사장에 준비된 아침식사. 아무것도 못먹고 나온터라 몇 개를 집었다. 미국의 컨퍼런스는 비싸기는 하지만 이런 형태로 돌려주는 것들이 꽤 있다. 특히 잘나가는 회사에서 주최하는 행사일수록 이런 부분에서 후하다는 느낌을 받는다. 빵과 함께 바나나와 사과도 집었는데 사과는 결국 맛을 못보고 체크아웃 하면서 호텔에 버리고 왔다.



이번 행사의 경우 키노트 발표장의 혼잡을 줄이기 위해서였는지 등록한 순서에 따라 입장할 수 있는 곳이 나뉘었다. 나는 행사 당일 아침에서야 등록을 했기 때문에 키노트를 발표하는 행사장에 들어갈 수 없었다. 그러나 행사 전날 오후에 등록했던 다른 일행들은 키노트 행사장에 입장할 수 있었다. 이곳에서는 대형 화면을 통해 키노트 행사장을 중계해주고 있었다. 일정의 문제로 일찍 등록을 하는 대신 다른 일정을 선택한 것이기는 하지만 막상 키노트 행사장에 들어가지 못하니 아쉽긴 했다. 일정의 앞부분이 여유롭지 못했는데 아마 내 지갑에서 비용을 내는 것이 아닌 이상 어쩔 수 없는 부분일듯.



행사장에 들어가는 사람과 그렇지 못한 사람의 차이는 팔에 찬 태그의 끈 색에 따라 달랐다. 내 끈은 오렌지 색이었지만 행사장에 들어갈 수 있는 사람들의 끈 색은 파란 색이었다. 나중에 보니 녹색, 회색 등의 다른 색도 있었는데 키노트 행사장에 들어갈 수 있다는 것을 제외하고는 차이가 없었다.



키노트 시작 전에는 기다리는 사람들을 카메라에 비춰주기도 하고 핑퐁 게임을 하는 모습을 보여주기도 했다. 사진에는 없는데 행사장에 ㄷ자 모양으로 스크린을 꾸며 한쪽 끝에서 다른 쪽 끝까지 공이 움직이는 핑퐁 게임을 계속 보여줬다. 처음에는 화면을 왜 ㄷ자 모양으로 과도하게 꾸몄을까 의문이었지만 키노트를 보며 그런 의문은 자연스럽게 해소됐고 도리어 목적에 맞는 훌륭한 구성이라고 생각하게 될 정도였다.



키노트가 시작됐다. 이날의 키노트는 사람들에게 많은 호응을 받지는 못했다. 큰 박수도 한 번에 그쳤고 그마저도 기술이나 서비스의 중요한 내용을 발표할 때가 아니라 사진을 무제한 올릴 수 있다는 사실을 발표했을 때 터져나왔다. 때로는 연사가 발표를 하고 한 박자 있다가 조그맣게 박수가 나오는 모습을 보며 꽤 안타까웠다. 하지만 그만큼 새롭다고 할만한 것이 별로 없었다. 아니면 참석자들의 기대 수준이 너무 높았을지도.



이번에도 작년과 같은 카드보드를 참석자에게 줬다. 작년 버전에 비해 좋아진 점은 1. 6인치의 큰 폰을 사용할 수 있으며 2. 조립 단계가 3단계로 간략화된 것이었다. 작년 처음 카드보드를 봤을 때의 놀라움은 아직도 생생하게 기억하지만 새로 받은 카드보드는 아직 사용해보지 못했다. 못받은 사람도 있는 것으로 봐서는 누군가가 두 개씩 가져가기도 한듯.



행사장 1층에 마련된 I/O 2015 조형물.



작년에는 교실처럼 구획을 나눠놓았다고 하는데 올해는 넓은 공간에 위와 같이 거의 공개된 형태로 공간을 꾸며놨다. 이 외에도 반쯤 열린 공간과 강의실같은 - 일반적인 컨퍼런스에 가면 쉽게 접할 수 있는 - 공간으로 구성되어 있었다. 하지만 세션의 인기에 비해 공간이 너무 좁아 공간을 나누는 벽 뒤에서 들을 수 밖에 없는 경우도 매우 많았다. 뭔가 듣기에 좋은 형태는 아니었다. 실제로 공간에 비해 사람이 너무 많아 몇 개 세션은 듣기를 포기한 경우도 있었다.



행사장 전경. 



3층은 주로 데모를 볼 수 있는 곳으로 구성되어 있었다. 사진은 개인들이 꾸민 안드로보이를 등록하면 합창을 하도록 만들어둔 곳이다. 이 옆에는 스티커를 출력해주는 곳도 있었다. 두 번째 날, 안드로보이를 만들어 스티커를 요청하는 것까진 잘 했는데 결국 내 스티커를 받지는 못했다. 아마 전송이 성공하지 못했거나 누락되었거나 다른 사람이 가져간듯.



구글이 발표한 Expedition의 촬영장비. 16대의 고프로를 연동해서 촬영을 한다. 개인적으로는 안드로이드보다 Expedition과 같은 VR쪽에 더 관심이 갔다. 키노트에서도 보여줬듯 이미 파일럿으로 찍은 컨텐츠는 교육 현장에서 카드 보드를 사용하여 활용하고 있었다. 장비의 크기를 생각하면 카메라로 사진을 찍는 것만큼 촬영이 쉽지는 않겠지만 그 효과는 엄청날 것 같다.


구글이 키노트에서 발표한 Expedition 동영상.



Expedition과 함께 내 관심을 끈 기술. 저렇게 매달린 고정된 카메라를 사용하여 360도를 돌아가며 볼 수 있게 해준다. 백문이 불여일견. 동영상을 보면 쉽게 이해할 수 있을 것이다. 프로젝트의 정확한 이름이 기억나지는 않는다. 처음에는 카메라가 돌아가는 형태인 것으로 생각했는데 카메라가 고정되어 있어 이상하다는 생각을 했을 정도. 이 외에도 프로젝트 Tango라는 AR을 활용하는 데모가 전시되어 있었다. 국내 업체 중에는 SKT(P?)에서 데모를 제출했는지 관련자 분들이 몇 분 데모를 확인하고 있었다. 





강의실과 같은 곳으로 들어가면 이렇게 일반적인(?) 컨퍼런스의 모습을 만날 수도 있다. 재미있는 것은 들어갈 때 위 사진에 있는 태그를 찍는다. 스태프가 핸드폰으로 태그를 찍으면 행사 신청 후 별도로 등록했던 사진이 화면에 나타나면서 본인이 맞는지를 확인한다. 출첵이라도 하는 것은 아니겠지?



듣고 싶은 세션이 없을 때는 이렇게 마련된 공간에서 사람들과 이야기를 나누기도 하고 직접 컴퓨터를 가지고 데모를 만들어보기도 했다. 한쪽에는 직접 만들어볼 수 있는 환경이 만들어져 있기도 했다.



일층에 전시된 안드로보이.



행사장 이층에는 실제 구글의 개발자들과 질문하고 토론할 수 있는 공간이 있었는데 거기서 필기할 수 있도록 만들어 둔 종이 롤이다. 저렇게 해놓고 다 쓴 후에는 종이를 다시 꺼내어 새롭게 글을 쓸 수 있는 여백을 만든다. 각 세션의 시간표도 이와 비슷하게 종이를 가지고 만들었는데 재미있는 모습이었다.



행사장 외벽에 구글 IO 행사가 진행 중임을 알려주는 표시가 붙어 있다.



첫 날 일정이 모두 끝난 후에는 파티를 하기 위해 근처의 Yerba Buena Gardens로 향했다. 이곳에서 구글 IO 참석자들을 위한 파티가 열린다.



행사장은 넓었고 먹을 것과 마실 것이 무제한(?) 제공되고 있었다. 그런데 날이 추워서 반쯤은 추위에 떨었던 듯. 설마 하고 두꺼운 옷을 가져가지 않았는데 시간이 갈수록 너무 추웠다. 저녁 때의 샌프란시스코의 온도는 대략 12도 근처였던 것으로 기억한다. (한국에서 출국하던 날 한국의 기온은 30도였다.)



이 곳에서 노래를 부르기도 했다고. 너무 날이 추워져 행사가 마무리되는 것을 보지 않고 일행들과 함께 근처의 식당으로 향했다.


이렇게 첫 날 일정을 마무리했다.


nundefined ETC Android, expedition, Google, google io, 구글, 구글IO, 안드로이드

Swift 문법 간단 정리 #2

2015.05.16 17:02
  • function
    • func getColor(string: String) -> (red: Int, green: Int, blue: Int) {}
      • println(“\(returnVal.red) and \(returnVal.green) and \(returnVal.blue)”)
    • func makeColor(c1: Int, c2: Int, c3: Int)
      • func makeColor(withRed c1: Int, withGreen c2: Int, withBlue c3: Int)
      • 말을 만드는 것처럼 함수를 호출할 수 있게 (sentence-like)
      • func makeColor(#red: Int, #green: Int, #blue: Int)
        • 함수 내, 외부에서 같은 이름으로 파라미터를 사용
      • func makeColor(withRed c1: Int, withGreen c2: Int, withBlue c3: Int = 100)
      • func makeColor(c1: Int, c2: Int, c3: Int = 100)
        • makeColor(100, 100, c3: 150)
    • func joinItems(items: String…)
      • 가변 갯수 파라미터는 항상 파라미터 목록 마지막에
    • func sample(var name: String, count: Int)
      • var로 선언하면 함수 내에서 값을 변경할 수 있음
      • 함수 실행 중에 변경된 값이 함수 실행 후의 값에 영향을 주지는 않음
    • func sample(inout a: Int, inout b: Int)
      • var val1 = 100
      • var val2 = 200
      • sample(&val1, &val2)
      • 함수 밖의 값에 영향을 미침
    • 함수 타입
      • 파라미터와 반환값의 타입으로 구성
        • (String, Int) -> String
      • var func1: (Int, Int) -> Int = func2
        • (Int, Int) -> Int 함수 타입인 func1을 정의하고 func1은 func2를 참조한다
      • func function3(func1: (Int, Int) -> Int, a: Int, b: Int)
      • 반환값으로 사용하는 함수 타입
        • func sample1(input: Int) -> Int {}
        • func sample2(input: Int) -> Int {}
        • func chooseOne(left: Bool) -> (Int) -> Int { return left ? sample1 : sample2 }
        • let sample4 = chooseOne(false)
          • sample4는 sample2를 가리킨다
    • 중첩 함수
      • func chooseOne(left: Bool) -> (Int) -> Int {
            func sample1(input: Int) -> Int {return 1}
            func sample2(input: Int) -> Int {return 1}
            return left ? sample1 : sample2
        }
      • 외부에서는 sample1, sample2에 접근하지 못함


nundefined ETC IOS, SWIFT, 스위프트