최근 진행되고 있는 프로젝트에서 AWS S3 와 CloudFront를 사용하여 동영상 서비스를 하고 있는데 CBT중이라 버그 리포팅이 자주 오고 있다.

분명히 테스트때는 정상 작동을 했는데 왜 항상 실제 사용하면 버그가 튀어나올까...?!

Video Thumbnail 파일을 새로 업로드 하였는데 이미지가 바뀌지 않는다는 내용의 문제가 접수되었다. 

Thumbnail 수정 로직은 기존에 사용하던 파일 이름에 확장자만 새로 올린 사진 파일을 따르게 되어있었다. 해서, 사진이 업로드된 S3에는 새로 올려진 파일이 존재하는데, CloudFront에 요청을 하면 캐시되어있는 예전 사진이 보여지는것이었다. 

파일이 새로 올라왔는데 CloudFront는 왜 새로운 파일을 캐시하지 못했을까?

문제 해결을 위해 문서를 찾아보니 다음과 같은 내용을 확인하였다.

CloudFront 배포에서 기존 객체를 업데이트하고 동일한 객체 이름을 사용할 수는 있지만 권장되지는 않습니다. CloudFront에서는 오리진에 새 객체나 업데이트된 객체를 배치할 때가 아닌 객체가 요청된 경우에만 엣지 로케이션에 객체를 배포합니다. 이름이 같은 최신 버전으로 오리진에서 기존 객체를 업데이트한 경우, 다음 두 가지 상황이 모두 발생하기 전까지는 엣지 로케이션에서 오리진으로부터 새 버전을 가져오지 않습니다.

• 캐시에 있는 객체의 기존 버전은 만료됩니다. 자세한 내용은 객체가 CloudFront 엣지 캐시에 보관되는 시간 지정(만료)단원을 참조하십시오.

• 엣지 로케이션에는 객체에 대한 최종 사용자 요청이 존재합니다.

문제에 대한 이유를 찾았으니, 문제 해결을 해보도록 했다.

CloudFront 엣지 캐시에서 객체가 만료되기 전에 이것을 제거하는것, 즉 CloudFront의 객체 무효화를 사용하면 된다. 

1. AWS Console에 접속하여 CloudFront 페이지로 이동한다.

2. 문제가 발생한 Distribution을 선택한다.

3. Invalidations탭을 선택한다.

4. Create Invalidation을 선택한다.

5. Object Paths에 Invalidate할 파일 이름을 적어준다.

이때 Origin Path를 제외하고 난 나머지를 적어주면 된다.

예를 들어, 

Invalidate할 파일이 S3 bucket에 /thumbnail/1234.jpg이고,

CloudFront의 Origin Path가 /thumbnail로 잡혀있다면, 

Create Invalidation의 Object Path에 1234.jpg를 적어주면 된다.

6. Invalidate버튼을 누르고 Status가 Completed가 되길 기다리면 된다. (생각보다 오래 걸린다...)

참고로 Invalidation은 무료 갯수가 제한되어있어서 그 이상 Invalidate을 하게 되면 과금되니 주의해야 한다.

과금 정보는 다음 페이지에서 확인 가능하다.

http://aws.amazon.com/cloudfront/pricing/

참고자료

http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/ReplacingObjectsSameName.html

Firebase: Robo Test

Firebase는 앱 개발을 위한 실시간 데이터베이스, 사용자 인증 및 호스팅 기능을 제공하는 서비스에서

Google에서 인수한 후 앱(Android, iOS, 모바일 웹)을 위한 통합 앱 플랫폼으로 확장되었다.

Firebase에서는 앱 개발을 위한 기능 뿐만 아니라 분석, 관리, 마케팅등을 위한 기능들이 다수가 포함되어 있다.

본 포트스에서는 Firebase의 앱 자동화 테스트 기능인 "Robo Test"에 대해서 살펴보려고 한다. 

테스트를 위한 대상 앱을 회사에서 개발한 "On-ly 앱"을 테스트 해보기로 결정하였다.

On-ly는 "스마트 게임 만보계"로

1) On-ly를 설치한다.

2) 평소대로 스마트폰(게임)을 사용한다.

3) 내가 스마트폰으로 게임을 얼마나 어떤 패턴으로 하는지 궁굼하면 On-ly에서 살펴본다.

와 같은 간단한 컨셉을 바탕으로 개발되었다.

1. On-ly 테스트 Coverage

테스트를 진행해 보기에 앞서, Robo Test가 "어디까지 테스트를 해줄 수 있을까? 또는 이런것도 테스트가 가능할까?"에 대해서 생각을 해보았다.

1) 게임 플레이 시간 수집

앞서 설명한 바와 같이, On-ly는 사용자의 게임 플레이 시간을 수집하여 정보를 제공하는 앱이다. 게임 플레이 시간 수집을 테스트하기 위해서는, "a) 게임이 설치되어 있어야하고, b) On-ly가 설치되어 있어야 한다. c) 게임을 일정시간(5분이상) 실행한 후, d) On-ly를 실행해야 한다."와 같이 타 앱과의 연계가 필요하다.

2) Facebook 연동(로그인 기능)

부가 기능(친구 데이터 공유, 데이터 persistency등)을 위해 Facebook 연동을 제공하고 있다. 만약, Robo Test에서 로그인이 가능하다면 서버에 저장된 데이터를 사용하여, UI 테스트가 가능하다.

3) 전체 페이지(State) 테스트

사용자가 접할 수 있는 On-ly의 총 페이지(State)는 43개이다. 43개는 동일한 기능(상세 팝압)은 1개의 페이지로 고려하였을때 확인된 수치이다. 실제로는 더많은 페이지를 접하게 된다. 이번 테스트에서는 전체 중 몇%의 페이지를 Robo Test가 테스트 할 수 있는지를 확인하려고 한다.

(* 페이지별 세부 테스트 또는 페이지의 연계성을 고려한 테스트는 고려하지 않음)

<On-ly 페이지별 스크린샷>

4) 시스템 권한

On-ly는 게임 모니터링을 위해, "android.permission.PACKAGE_USAGE_STATS" 시스템 권한이 필요하다.(*Android 5.1, Lollipop 부터 시스템 권한으로 변경됨)

시스템 권한은 앱을 설치후 사용자가 직접 안드로어드 OS 설정 페이지에서 권한을 추가해야 한다. 즉, 테스트시 안드로이드 OS와의 연계가 필요하다.

<PACKAGE_USAGE_STATS 시스템 권한 획득과정>

당연히 내부에서 테스트를 진행할 시 위 4가지만을 고려하는 것은 아니다. 더 많은 항목을 테스트 해야 한다. 단, 본 테스트에서는 Robo Test로 큰 틀에서 어느 범위까지 테스트가 가능한지를 확인하기 위해 위 4가지 항목으로 정해보았다.

2. Robo Test 실행

Test Lab을 사용하기 위해서는 Firebase가입 및 카드 등록이 필요하다. 시간당 $5로, 테스트 장비 대여 및 관리 비용이라고 생각하면 비싼 가격은 아니라고 생각된다.

<Firebase Pricing[6]>

2.1. 프로젝트 만들기

프로젝트는 Firebase console에서 "새 프로젝트 만들기"로 생성할 수 있다. 해당 프로젝트로 이동하면, 좌측 DEVELOP -> Test Lab을 확인할 수 있다.

<새 프로젝트 만들기>

2.2. 테스트 실행

메뉴의 DEVELOP -> Test Lab을 선택하고, "테스트 실행 -> Robo 테스트 실행"을 선택한다.

<Robo Test 실행>

테스트할 앱(On-ly)의 APK를 업로드한 후 "계속"을 선택한다.

<앱 선택(APK 업로드)>

테스트 실행 단계에서 가장 복잡한단계로, [실제기기, API수준, 방향, 언어, 고급 옵션1, 고급 옵션2]6개의 측정기준을 선택하는 단계이다.  "테스트의 개수 = 실제기기 수 x API수준 수 x 방향 수 x 언어 수"로 결정된다. 본 예제는 1x3x1x1=3으로 3개의 테스트를 진행한다.

고급 옵션은

1) 테스트 제한시간: 테스트를 실행할 최대 시간(분)으로, 기본은 5분으로 설정되어 있다.

2) 최대 깊이: Robo 테스트에서 앱 UI의 특정 분기를 얼마나 깊이 탐색한 후 UI 루트(기본 화면)로 돌아가서 다른 분기를 탐색할지를 결정합니다.

으로 기본값으로 테스트 하였다.

<측정기준 선택>

테스트가 모두 완료되면 아래와 같은 결과를 확인할 수 있다. 모두 통과 하였다. 이제 상세 결과를 확인해 보자.

<테스트 매트릭스>

3. Robo Test 결과 확인

3.1. 테스트 결과 항목

테스트 결과는 

a)로그: Device에서 발생한 level별 로그

b)스크린샷: 테스트를 진행한 페이지의 스크린샷 목록

c)활동 지도: 테스트를 진행한 과정의 activity diagram[7]형태의 diagram

d)동영상: 테스트를 진행한 과정이 녹화된 동영상

으로 구성되어 있다.

<테스트 결과 화면>

3.2. 결과 확인

"1. On-ly 테스트 Coverage"에서 생각해 보았던 내용을 충족시킬 수 있는지를 확인해 보자.

1) 게임 플레이 시간 수집 (테스트 할 수 없음)

"2.2. 테스트 실행"에서 확인한 바와 같이, 테스트 대상 앱 이외의 앱은 설치가 불가능 하다.

2) Facebook 연동 (실패 테스트만 가능)

테스트 Input에 사용자 데이터가 없다. 즉, 로그인 Action을 수행(테스트)할 수 는 있지만 로그인 성공에 대한 테스트는 불가능 하다.  아래 "활동 지도"에서 "Facebook 로그인" 페이지에서 실패를 반복하고 있다. 또한, 이로인해  테스트 시간을 모두 소비하여 다른 페이지는 테스트를 진행하지 못한것으로 판단된다.

<활동 지도 결과>

3) 전체 페이지(State) 테스트 (약 79%는 테스트 하지 못함)

Facebook 로그인을 실패한 페이지의 중복을 제거하면, 9개의 페이지를 테스트 하였다. On-ly의 전체 페이지(49) 중 약 21%의 페이지만을 테스트한 것이다. 

또한, 로그인 실패(수집된 데이터가 없는경우)한 경우만 확인을 하면 전체 17페이지 중 약 53%의 페이지만을 테스트 하였다.

<스크린샷 결과>

4) 시스템 권한 (테스트 하지 못함)

API 22(Lollipop)에서 새로 추가된 PACKAGE_USAGE_STATS를 위한 시스템 권한 획득에서 더이상 진행되지 않았다.  

<API 22 테스트의 활동 지도 결과>

4. 마치며

References

[1] Firebase Overview Google I/O 2016, https://www.youtube.com/watch?v=tb2GZ3Bh4p8

[2] Firebase Features[2], https://firebase.google.com/features/ 

[3] Google Cloud Test Lab for Robo Test, https://developers.google.com/cloud-test-lab/robo-ux-test

[4] Firebase Test Lab for Android Robo Test, https://firebase.google.com/docs/test-lab/robo-ux-test

[5] On-ly 앱, https://play.google.com/store/apps/details?id=com.embian.only

[6] Firebase Pricing, https://firebase.google.com/pricing/

[7] Activity Diagram Wiki, https://en.wikipedia.org/wiki/Activity_diagram

[8] Finite State Machine Wiki, https://en.wikipedia.org/wiki/Finite-state_machine

[9] Guided GUI Testing of Android Apps with Minimal Restart and Approximate Learning, http://www.cs.berkeley.edu/~necula/Papers/swifthand-oopsla13.pdf

[10] MobiGUITAR – A Tool for Automated Model-Based Testing of Mobile Apps, https://scholar.google.co.kr/scholar?q=A+Tool+for+Automated+Model-Based+Testing+of+Mobile+Apps&btnG=&hl=ko&as_sdt=0%2C5&as_vis=1

[11] Reducing Combinatorics in GUI Testing of Android Applications, https://seal.ics.uci.edu//wp-content/uploads/seal/PID4096715.pdf

[12] A GUI State Comparison Technique for Effective Model-based Android GUI Testing,https://scholar.google.co.kr/scholar?q=A+GUI+State+Comparison+Technique+for+Effective+Model-based+Android+GUI+Testing&hl=ko&as_sdt=0&as_vis=1&oi=scholart&sa=X&ved=0ahUKEwj6gMbo16nNAhXj3aYKHW5TA1sQgQMIGjAA

요새 AWS에서 제공하는 서비스들을 사용하여 동영상 스트리밍 서비스를 구축을 하고 있다. AWS쪽 관리와 운영 방법을 인수인계를 받는 중에 정리를 위하여 블로그를 작성해보기로 했다.

AWS S3와 CouldFront를 사용하여 동영상 스트리밍 서비스 해보기.

시나리오 

이 동영상 스트리밍 서비스는 권한이 부여된 사용자에게만 서비스를 하기 위하여 Signed Cookie와 Signed URL을 사용하여 서비스 한다. 

준비물은 다음과 같다.

1) AWS CloudFront, S3

2) 서비스 대상 HLS 파일

1. 먼저 S3에 Bucket을 생성한다.

2. 서비스 대상 HLS파일을 S3에 업로드 한다. 파일 업로드 방법은 다양한데, 이번 예제에서는 AWS Consol을 사용하여 업로드 해 보도록 하겠다.

먼저 폴더를 생성한다.

서비스 대상 HLS 파일들을 업로드 한다.

업로드가 완료되었다.

3. CloudFront 설정

CloudFront를 셋팅하기 위해 CloudFront페이지로 접근한다.

3.1 주요 설정

CloudFront의 주요설정은 다음과 같다.

Delivery Method 

- RTMP와 WEB이 있다. HLS는 WEB 방식의 Delivery를 사용하기 때문에 값을 WEB으로 선택한다. 

Origin Domain Name

- CloudFront로 서비스 하고자 하는 S3 Bucket이름이다. 클릭하면 select box가 나타난다.

Origin Path 

- S3 Bucket내의 DocumentRoot. S3 Bucket 내의 디렉토리 중 어느 위치를 해당 CloudFront의 /로 사용할 것인지를 나타낸다.

Restricted Bucket Access 

- S3에서 자체적으로 서비스를 하지 않고 CloudFront를 통해서만 서비스가 가능하도록 한다.

설정값은 Yes.

Origin Access Identity 

- S3 접근에 사용할 접근 정보. 이미 기존에 만들어진 것이 있기 때문에 기존 내용을 사용하면 된다. CloudFront의 좌측 하단 메뉴에서도 관리가 가능하다. 설정 값은 Use Existing Identity.

Grant Read Permissions on Bucket

- Origin Access Identity가 S3에 접근 가능하도록 하기 위해서는 S3의 Policy를 업데이트 해야 한다. 이것을 자동으로 해준다. 설정값은 Yes.

Forward Header 

- CORS가 정상적으로 적용되도록 하기 위해서는 Origin을 Forward해줘야 한다. 설정 값은 WhiteList.

Restricted Viewer Access 

- Signed Cookie, Signed URL이 필요하도록 할 경우 Yes. Signed Cookie, Signed URL을 통해서만 접근이 가능하도록 할 경우 설정한다.

그 외의 옵션은 모두 기본값으로 설정한다.

3.2 CloudFront Key Pairs

Signed Cookie, Signed URL을 사용할 경우 Security Credential에서 CloudFront Key Pairs를 설정해야 한다. Security Credential 메뉴는 우측 상단의 로그인 아이디를 클릭하면 메뉴에 나타난다.

여기에서 CloudFront Key Pairs를 추가하거나 Access Key ID를 확인할 수 있다.

4. 동영상 재생을 하기 위해 HLS 파일 주소 가져오기

지금 하고 있는 프로젝트에서는 Signed URL, Signed Cookie 생성시 expire time을 1분으로 주어 생성된 url을 1분간 유효하도록 하였다. 하지만 1분이 지나면 비디오 시청이 불가능해지므로, 비디오 재생 후 매 30초 마다 Signed Cookie를 발급받는 api를 호출하여 인증 갱신하도록 하였다.

4.1 동영상 시청을 위하여 Signed Cookie를 발급하는 API를 호출한다. 이 API는 CloudFront-Key-Pair-Id, CloudFront-Policy, CloudFront-Signature를 키값으로 하는 쿠키를 발급한다. Signed Cookie 생성은 아래 문서를 참고하여 만든다.

http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html

4.2 Signed URL로 비디오 파일을 요청한다. Signed URL은 암호화된 CloudFront-Policy, CloudFront-Signature와 위의 3.2에서 발급된 CloudFront-Key-Pair-Id를 포함하고 있다. 

Signed URL생성은 아래 문서를 참고 한다.

http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html

API에서 생성하는 Signed URL 구성은 다음과 같다.

http://도메인 이름/{Path가 포함된 file명}?Policy={암호화된 Custom Policy값}&Signature={암호화 된 signature값}&Key-Pair-Id={Access Key ID값}

chrome speech synthesis service 개발기

- "크롬을 음성합성 서버"로 사용해보자

"사장님, 스마트 미러가 리눅스에서 잘 안돼요. 어떻하죠?"

.

.

.

작년 말에 접하게 된 마이크로소프트의 에반군이 만든 garage 프로젝트인 스마트미러(Smart Mirror) 에서 확인 했었고, 거의 모든 오픈소스 스마트 미러 프로젝트는 라즈베리파이(RPi)등의 Arm기반 보드에서 "리눅스"로 돌리고 있었기 때문에 믿기 힘든 비보였습니다.

"쫌! 잘해봐. 말이돼냐? (썩소)"  "아니예요, 실제 잘 안된다고 어디서 본것도 같아요.(떨리는 눈빛)"

'에이 설마, 또 초짜 주우우니어 호빗 개발자의 닥질..'  여전히 그 생각이였고, 솔직히 다른 OS에서 다되는데 리눅스에서 안된다는 건 약간은 리눅스(마이프레셔스!)를 데탑으로 끌어 안고 사는 한때 호빗 개발자였던 골름의 밥상에 돌 던진듯한 느낌을 받는... 

그래도 한번 속는셈 치고 들어나 보기로 했습니다.

"그래 뭐가 안된다는 건데?(썩소2)"       "아, 제가 이번에 연동한게 유투브, 지도API, 어쩌구 저쩌구..."

"아 그러니까 뭐가 안된다는 건데?(확신찬 썩소썩소썩소)"           ".. 그러니까.. 저.. 말하는게 안되요!"

"응?!?  혹시 말하기 기능 넣었어?(반짝반짝)"   "..네.."  (이 시점에서 소으니:골름 = 1:0!) 

바로 소으니는 맥에서 잘되는걸 보여줬고, 리눅스에서는 안되는것도 보여줬다. (2:0!)

"아.. 그..러네.  그래도 니가 비동기 방식의 javascript 쓰다가 뭔가 잘못한거?" (쓸데없는 의심, 3:0!)

"네,  그런데 일단 코드가 너무 간단해서... 잘못하기 힘든데요?"

크롬에서 음성합성 예제: HTML5 Speech Synthesis API 사용

========================================

여기서 말하기 기능이라는 것은 '음성합성' 또는 'Speech Synthesis'라고 불립니다.  다들 아시겠지만, 우리가 은행이나 콜센터에 전화를 걸었을 때 자동으로 대답을 해주는 약간 어색한 사람 목소리를 위장한 마디마디 리코딩된 기계음 등이 이 부류입니다.   

var utterance = new SpeechSynthesisUtterance('Hello, 세상');

var voices = window.speechSynthesis.getVoices();

utterance.voice = voices.filter(function(voice) { return voice.name == 'Google 한국의'; })[0];

window.speechSynthesis(utterance);

'잉, 코드군이 너무 간단한데? ' 

뒷목이 뻑뻑한 느낌이 들더군요. 지은죄가 있는지라 몇일 구글군의 힘을 빌어 뒷북 뒤지기를

시작했는데, 음성합성을 쓰기 위해서 엔지니어링 관점에서 몇가지 알고 있어야 될것들이 나왔습니다.

음성합성(Speech Synthesis) 간략정리

=========================

0. Speech Synthesis는 나름 긴역사가 있다.  특히 예전에 sphinxsearch검색하면 검색결과 밀어 

버리고 쓸데 없이 나오던 sphinx도 speech 관련해서 꽤 유명한 놈이더라. (제대로 잡설!)

1. 웹브라우저가 사용할수 있는 Speech Synthesis API는  Speech Recognition API와 나름 2년이나 되었다.  (since google chrome 33+, 현재 쓰고 있는 버젼은 48+)

구글 크롬이야 당연히 지원하고 있었고, 사파리도 지원하고 브라우저들이 다들 지원하는 분위기다.

2.  위의 내용 1을 순진하게 믿고 테스트 하다보면, 지금 그닥 쓸만한 놈은 chrome이다.  

     그리고 된다는 SSML은 아직 안된다.  SSML은 음성합성을 XML로 표기하여 끝말올리기, 반복하기 등을 표기할수 있는 방법입니다.    

3.  그리고 결정적인, Speech Synthesis가 "리눅스에서는 안되고, 맥에서는 된다"는 틀렸다.  

정확한 정보는 "(목소리가 없기 때문에) chromium에서는 안되고, chrome에서는 된다" 이다.  (앗싸.  3:1!)

3번은 알고 나면 허무하지만, 약간의 보충설명이 필요합니다. 그래서 조금 내용을 살펴 보겠습니다.

Chromium은 Chrome과 다르기 때문에 

구글의 완성도 높은  아름다운 목소리를 가져올수 없습니다.

======================================

원래 웹브라우저의 Speech Synthesis API에 대한 표준화 문서를 보면,

Speech Synthesis API는 API이지 실제 voice라는 리소스는 웹브라우저가 

지원(provision)할수도 있고, OS가 지원하는 네이티브 리소스로 (따라서 chrome external) 

voice를 사용할 수도 있습니다. (양자택일!)

그런데, 대부분의 우리가 수행했던 Speech Synthesis의 테스트는 

구글 크롬(default로 날아오는 voice는 google이 제공)했기 때문에 문제가 없었고, 

쓸수 있는 API만 있지만, chromium은 google의 voice API 키가 없기 때문에, 

말할 '목소리'가 없습니다. 

기계가 목소리가 없어서 인간이 안되고 결국 허무하게 여기서 거품으로 끝난다는건 어디서 많이본 

동화같습니다.(아이씨- 언더더씨 네요.)

그럼 소으니가 말했던 스마트 미러가 맥은 되고 리눅스에서는 목소리가 안나오는 이유는 뭘까요?  

네. 우리가 쓴 node.js의 electron은 (예전에는 ATOM으로 불렸었죠) chrom"ium"의 분신이고

따라서 보이스 실물 리소스가 존재하지 않습니다. 구글에서 허락없이 땡겨올수 없기 때문이죠.  

하지만, Mac에서 제공하는 네이티브 목소리가 있기 때문에 맥(electron)에서는 잘 되었던거고,

리눅스(electron)에서는 안된겁니다.  여기서 "댕~"하는 상황은 리눅스의 chrome에서는 되니까

더 헛갈린겁니다.  알고나면, 구글의 chrome이니까.  구글 목소리니까 당연한거죠.

즉, 확실한건 chrome != chromium에서 생기는 문제인거요. 

아, 참고로 chromium을 걍 컴파일 해서 쓸까 (electron) 했는데요, 저같은 생각을

하는 골름들이 무지 많나 봅니다. chromium 사이트에 노란색 볼드체 으로 

이렇게 적혀 있네요. ㅎ

https://www.chromium.org/developers/how-tos/api-keys

"Do NOT post to the various Chromium groups/mailing lists for questions about the Speech API."

(헐- 넹. 골름골름)

쓸데없는 소리 이제 그만!  Show Me! Please talk to me!

======================================

1)  기본테스트:   

너그러운 마음에서 데모 한번 봐주시고,  

http://speech.embian.com/

2)  확장테스트:

재미로 준비한 추가 데모 꼭 해보시고, 한번 쭉 소리나는거 들으시고, 

*setting: 의 en-GB 를 ko-KR로 바꿔 들어 보세요 ㅎ

(강추! 우리집 꼬마가 좋아합니다.)

중국어/영어/일어/스페인어등 언어 공부하시는 분들 무료로 활용법을 찾으시면

만든 골름은 무지 감사할것 같습니다. 

http://speech.embian.com/rap

3)  혹시 수정이나 설치 필요하신 분 계시면 github에서 오픈소스로 제공합니다.

https://github.com/embian-inc/chrome-speech-synthesis

아, 외로운 친구의 PC/폰에 크롬띄워놓고 이성의 목소리로 "밥 먹으로 가요"를 

날려볼수 있습니다.  퍽이나 재미집니다.  골름골름~

맺음말

=====

동굴에 들어간지 오래 되어 소스가 날것이라 전혀 이쁘지는 않습니다. 

지나가던 저희 개발자 호빗 무리들이 무지 비웃었습니다. 

하지만, 골름은 사랑받기 위해서 

태어난 한때 호빗이였던 아이입니다.              이뻐해 주시면 좋겠네요. (최종스코어:  3:2!)

그럼 전 가족부양하러 물고기 잡으러 다시 동굴로 돌아갑니다.긴글 읽어 주셔서 감사합니다. 

마이프레셔스, 골름골름~

ps 결국 구글님이 무료로 열어줘서 편하게 쓰지 않을까 생각합니다. 언젠가는 ^^ 

아님 네이버님, 왓쓴님 이라도.  아니면 누군가는 문익점 되서 디지탈씨앗 몇개 날라야죠, 뭐. 

References:

Standard for Web Speech Synthesis: 

* https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#examples-synthesis

Standard for SSML

* http://stackoverflow.com/questions/21952736/the-right-way-to-use-ssml-with-web-speech-api

* https://www.w3.org/TR/speech-synthesis11/#edef_emphasis

Main Code of Speech Synthesis API Example

* http://blog.teamtreehouse.com/getting-started-speech-synthesis-api

12월 중순 쯤 회사내에 흥미로운 동영상이 공유 되었는데 바로 smart-mirror 라는 프로젝트였습니다. 아래 동영상을 보시면 smart-mirror에서 사용자의 음성으로 지도나 philips hue 전등을 컨트롤 하는 모습을 보실 수 있을 것입니다. 되게 fancy해 보이지 않나요? smart-mirror에서 사용한 언어는 javascript이며  speech recognition library로는 annyang 을 사용하고 있었습니다.

[  smart-mirror[링크] ]

회사 내에서도 우리도 해보자라는 의견이 나오기도 했고 마침 이전 프로젝트도 끝나고 시간이 남아 Garage Project로 smart-mirror를 하게 되었습니다.2주 동안 진행했던 이 프로젝트의 1단계 목표는 아래와 같습니다.

이 프로젝트에서 추가로 사용한 API는 다음과 같습니다. 

smart-mirror는 소프트웨어 측면보다 하드웨어 측면에서 준비하는 시간이 걸렸습니다.

준비물(원하는 결과물에 따라 가격이 달라질 수 있습니다. )

하드웨어 구성을 살펴 보면 라즈베리파이 2, USB microphone, 모니터, one-way mirror, philips hue 전등으로 구성되어 있었는데  라즈베리파이 2 + 모니터  대신 사용한지 오래된 노트북이나 태블릿 등을 사용하였고, philips hue 전등은 프리스비에서 구매하였습니다. 한가지 남은게 있다면  one-way mirror가 관건이었습니다. 현재 한국에서 one-way mirror를 구하는 것이 어려울 뿐만 아니라 상당히 비싼 가격에 판매되고 있어서 대체 할 만한 것을 계속 찾아보다 유리에 미러필름을  붙였습니다. 

미러필름의 판매처는 다음 링크에서 확인하세요.[사이트내에 가격이 30m가 180,000원, 1m~2m가 18,000원에 판매 되고 있습니다. ]

미러필름을 붙이는데 상당히 애를 먹었습니다. 특히 아크릴에 경우 반나절 정도 지나자 기포가 올라오는 단점이 있어서 유리에 미러필름을 붙였습니다. 

[one-way mirror 제작 과정]

[절연테이프를 붙인 one-way mirror 뒷면]

[one-way mirror 앞면]

2주 동안 작업한 이 프로젝트의 최종 결과물은 다음과 같습니다.

[스마트 미러] 

코드는 다음 링크에서 확인하실 수 있습니다. Github : https://github.com/embian-inc/smart-mirror-ko.git

시연동영상은 다음과 같습니다.

현재 smart-mirror는 mac,window,ubuntu 환경에서 모두 사용 가능하며 android의 경우 다음링크를 참고하세요. 

얼마전에 마무리 되었던 E2E Monitor 프로젝트의 고도화 작업이 있었습니다. 이 작업에 제가 참여하게 되었는데요.

(*혹시 E2E Monitor에 대해 궁금하시다면 다음 링크를 참조해 주세요!)

E2E Monitor 고도화 작업은 크게 두가지로 나뉘었습니다. 

이번 글에는 저랑 종민씨가 담당했던 E2E Monitor UI 고도화 작업에 대한 이야기를 풀어볼까 합니다. 

E2E Monitor UI 고도화 작업의 목표는 Dashboard 개인화였습니다. Dashboard 개인화란 운영자마다 또는 시스템 마다 보고 싶은 정보가 조금씩 다를 수 있기 때문에 사용자들이 원하는 데로 Dashboard를 편집 할 수 있도록 하는 것입니다.

본격적으로 작업을 시작하기 전에 Dashboard UI와 관련된 자료를 찾아 보기 시작 했고 Dashboard 개인화를 하는데 참고한 오픈소스는 아래와 같습니다.

1. http://nickholub.github.io/angular-dashboard-app/#/

이 오픈 소스의 경우에는 사용자들이 원하는 위젯을 추가 삭제할 수 있도록 구현 되어있었습니다. 아쉬운 점이라면 정렬이 되지 않아 다소 산만해 보이는다는 점입니다. 

[nickholub - angular-dashboard-app]

2. http://angular-dashboard-framework.github.io/angular-dashboard-framework/#/sample/01

이 오픈 소스의 경우에는 사용자가 위젯을 추가 삭제 할 수 있고, 일정한 비율로 정렬 할 수 있으며 , 원하는 위치로 drag&drop 할 수 있도록 구현되어 있었습니다. 

[angular-dashboard-framework]

위 2가지 오픈소스의 장점을 참고해 만들었던 E2E Monitor의 대략적인 스토리보드 중 하나는 아래와 같습니다.

[E2E Monitor  스토리보드]

이렇게 스토리 보드를 작성하고, 약 1개월 동안 개발을 하였습니다. 

E2E Monitor 2.0에는 Responsive Web, Dashboard Customizing, Widget Modularization 등의 기능을 추가로 개발하였는데요.

Dashboard Customizing에서는 편집모드에서 Dashboard 하나 하나를 이루고 잇는 그래프들을 하나의 위젯이라 생각하고 Drag&drop을 하는 기능이 필요했고, 이 와 관련된 라이브러리로 사용했던 것이 SortableJS입니다.

angular-dragdrop, ng-sortable 같은 라이브러리도 고려 하였으나 가장 많이 사용하기도 하고, 사용하기도 쉽고, 문서도 잘 되있어 SortableJS를 사용하게 되었습니다. 

그래서 Dashboard를 Customizing할 수 있는 E2E Monitor는 다음과 같습니다. 

Demo는 http://e2edemo.embian.com/#/e2emDashboard 에서 확인 하실 수 있습니다.

추후 고려해야 할 사항 

개발 완료 후 회사 분들과 함께 논의를 한 결과 좀 더 개선 해야 할 사항과 의견들이 있었습니다. 

 이러한 사항은 추후 E2E-Monitor v3.0에서 적용해 볼 계획입니다.