tucan9389's blog

iOS에서 엑셀파일 만들기(feat. libxlsxwriter)

tucan.dev — Fri, 1 Jun 2018 16:24:38 +0900

libxlsxwriter 소개

libxlsxwriter는 C라이브러리입니다. (벌써부터 머리가 지끈..) Objective-C를 사용할때는 편하게 썼었는데 요즘은 Swift만 쓰다보니 C를 쓰는게 여간 부담스러운 일이 아닐 수 없네요. 여러가지 라이브러리를 써봤지만 실패를 하곤 결국 C 라이브러리까지 찾게 되었습니다. 그래도 한가지 다행인 소식은 이 라이브러리가 CocoaPods을 지원한다는 것입니다.

아래는 여러가지 엑셀 편집 라이브러리입니다. 저는 결국 libxlsxwriter를 사용하기로 했습니다.

https://github.com/renebigot/XlsxReaderWriter -> 특정 기능 사용시 엑셀 깨짐: https://github.com/joelparkerhenderson/demo_swift_excel_xlsx_reader_writer 예제
https://github.com/janx2/jxls/

Swift 프로젝트에서 c라이브러리 pod 세팅하기

libxlsxwriter를 사용하려면 pod으로 워크스페이스를 만들어줘야하는데요. 그밖에도 몇가지 세팅이 더 필요합니다. C라이브러리라그런지 프레임워크로 인식을 못하더라구요. 그래서 bridge-header.h를 만들고 #include로 라이브러리의 파일을 불러오면 프로젝트의 Swift에서 사용할 수 있습니다.

Podfile 만들기

Podfile을 만듭니다. 확장자가 따로 없는 텍스트파일입니다. Podfile은 .xcodeproj 와 같은 경로(프로젝트 경로라 부르겠습니다)에 저장해둡니다.

Podfile 의 내용물입니다. CocoaPods은 Objective-C나 Swift 언어의 프로젝트에서 사용하는 의존성 관리 툴인데, 사용하는 방법은 따로 찾아보시길 바랍니다.

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '9.0'
use_frameworks!

def my_pods
    pod 'libxlsxwriter', '~> 0.7.7'
end

target 'excel-example' do
    my_pods
end
target 'excel-exampleUITests' do
    my_pods
end

여기서 중요한 부분은 pod 'libxlsxwriter', '~> 0.7.7'입니다. 0.7.7버전의 libxlsxwriter 라이브러리를 설치하라는 부분이죠. (참고로 excel-example는 제 프로젝트 이름입니다.)

pod 설치

cd ~/{프로젝트경로}
pod install

excel-example-Bridging-Header.h 만들어서 설정

저는 use_frameworks!를 사용했었는데, libxlsxwriter는 C 라이브러리라 그런지 읽어오질 못했습니다. 그래서 따로 excel-example-Bridging-Header.h를 만들고 프로젝트에 명시해주었습니다(Build Setting에 들어가서 Swift Compiler - Code Generation > Objective-C Bridging header 를 excel-example/excel-example-Bridging-Header.h으로 설정해주시면 됩니다).

C 라이브러리 불러올 수 있게 Pod 경로 설정

이번에는 헤더파일을 불러올 수 있게 Pod 경로를 명시해줍니다(마찬가지로 Build Setting에 들어가서 Search Paths > User Header Search Paths에 Pods를 추가하고 recursive를 선택해줍니다).

여기까지 잘 따라오셨다면 이제 excel-example-Bridging-Header.h를 통해 C라이브러리를 불러와서 사용할 수 있습니다!

libxlsxwriter 사용법

`excel-example-Bridging-Header.h`에서 `xlsxwriter.h` 불러오기

#include "xlsxwriter.h"

저장할 경로 정하기

let fileManager = FileManager.default
let documentsURL = fileManager.urls(for: .documentDirectory, in: .userDomainMask)[0]
let url = documentsURL.appendingPathComponent("filename").appendingPathExtension("xlsx")
let path = NSString(string: url.path).fileSystemRepresentation
print("path:", url.path)

초기 설정

/* 새 워크북을 만들고 워크시트를 하나 추가하기 */
let workbook = new_workbook(path)
let worksheet = workbook_add_worksheet(workbook, nil);

아래같은 새 엑셀 파일을 하나 만들고 Sheet1 시트를 하나 만든 것입니다. 시트 이름을 바꾸려면 nil대신에 문자열을 넣어줍니다.

초기 설정

/* 0컬럼부터 5컬럼까지 13.7 너비 적용 */
worksheet_set_column(worksheet, 0, 5, 13.7, nil);

셀 생성

/* 0 row, 4 column에 "이름" 문자열 넣기 */
worksheet_write_string(worksheet, 0, 4, "이름", nil);
/* 1 row, 2 column에 1.25123 숫자 넣기 */
worksheet_write_number(worksheet, 1, 2, 1.25123, nil);


/* 포멧 생성 */
let my_format = workbook_add_format(workbook);
format_set_align(my_format, UInt8(LXW_ALIGN_RIGHT.rawValue));
format_set_align(my_format, UInt8(LXW_ALIGN_VERTICAL_CENTER.rawValue));
format_set_bold(my_format);
format_set_font_size(my_format, 20)
format_set_font_name(my_format, "Arial")
/* 포멧이 적용된 셀 생성 */
worksheet_write_string(worksheet, 0, 1, "타이틀", my_format);

셀 합치기

worksheet_merge_range(worksheet, 3, 0, 3, 5, "합쳐진 셀", my_format);

파일 닫기

workbook_close(workbook);

모든 작업이 끝났으면 파일을 닫아주셔야합니다. 그리고 닫은 파일을 사용하려하면 에러가 발생합니다.

전체코드

https://github.com/tucan9389/excel-example-ios

위 코드로 만들어진 엑셀파일

마치며

코드 분할

C 인터페이스를 사용하다보니 Swift 코드와 안 어울리는것 같습니다. 저는 ExcelMaker.swift 파일로 빼내서 ExcelMaker 클래스를 만든 다음 클래스 메소드 static func createXLSX(filename: String, info: MyInfo) { ... }를 만들어서 사용했습니다.

Excel 포멧의 한계

엑셀파일 만들기가 csv파일 만들기와 비슷할 줄 알고 쉽게봤다가 고생 좀 하면서 느낀점은, MS는 엑셀파일을 자기네 프로그램 안에서만 쓰게 하려고 이렇게 사용하기 어렵게 만들었나 싶습니다. 아마도 엑셀파일 용량 줄이고 최적화시킨다고 이렇게 된게 아닐까 생각이 드는데, 라이브러리를 쓰실때도 오피셜 라이브러리가 따로 없기때문에 문제가 생겼을때 처리하기도 매우 곤란한 상황입니다. 여하튼 제3자 개발자가 엑셀파일을 직접 건드리는 작업은 피하는걸 권장하고싶습니다.

엑셀파일 만들기가 csv파일 만들기와 비슷할거라 생각하고 덤볐다가 고생했습니다. 그리고 고생한 이유를 찾아보았습니다.

엑셀파일 포멧이 표준을 지키지 않습니다.마이크로소프트 자신만의 포멧을 만들어 엑셀을 지원하고 있는데, 아마도 용량을 줄이거나 최적화시키려고 그랬겠지요..
공식라이브러리는 당연히 없고, 그러다보니 엑셀파일을 만들 수 있게 지원해주는 비공식(이지만 거의 공식처럼 쓰이는)라이브러리도 약한 편입니다.물론 Swift 라이브러리를 찾아보려다보니 범위가 좁긴 했지만, 엑셀 정도로 자주쓰이는 포멧은 Swift용 라이브러리가 있을법도한데 Star가 100개를 넘는 저장소를 찾기 힘들었습니다.

참고

[번역] TOCO: 텐서플로우 라이트 최적화 컨버터

tucan.dev — Wed, 23 May 2018 13:16:09 +0900

원문: https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/lite/toco

Tensorflow Lite 최적화 컨버터는 Tensorflow 그래프를 Tensorflow Lite 그래프로 변환해줍니다. 추가적으로 더 사용할 수 있는데, 이 문서에서 세부적으로 다룹니다.

문서 사용법

정보 사용법은 아래 문서들에 있습니다.

컨버터는 Tensorflow에서 어느 부분에 해당될까요

앱 개발자가 학습된 Tensorflow 모델을 구하면, TOCO는 모델을 받아 Tensorflow Lite FlatBuffer 파일을 생성합니다. TOCO는 현재 SavedModels이나 frozen graphs(freeze_graph.py로 만들어진 모델)을 지원하고 있습니다. Tensorflow Lite FlatBuffer 파일은 클라이언트 기기에 올라갈 수 있고, 보통은 Tensorflow Lite 해석기가 디바이스 위에서 처리할 수 있는 모바일 기기입니다. 아래에 그 흐름이 표현되어있습니다.

[번역] 약간의 iOS 개발 팁

tucan.dev — Sun, 20 May 2018 20:50:14 +0900

원문: https://medium.com/developerinsider/best-ios-development-tips-and-tricks-6c42c1d208c1

이 글은 먼저 DeveloperInsider에 발행됩니다. 여기(원문)서 확인할 수 있습니다.

1. Xcode에서 빌드시간 확인하기

프로젝트의 정확한 빌드 시간을 모른다면 Xcode에서 아래 옵션을 켜자.

defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES

2. Swift 프로젝트 빌드시간 단축시키기

Xcode 9.2 릴리즈 노트에서는 BuildSystemScheduleInherentlyParallelCommandsExclusively 사용자 디폴트를 켜서 스위프트 빌드시간을 단축시켜주는 실험단계의 기능을 언급했습니다.

defaults write com.apple.dt.Xcode BuildSystemScheduleInherentlyParallelCommandsExclusively -bool NO

주의: 릴리즈 노트에 따르면 "빌드시간동안 메모리 사용을 증가시킬 수 있는 실험적 기능"이라고 했습니다.

3. Xcode에서 전체화면 모드로 시뮬레이터 사용하기

나는 Xcode 9 기능중에 전체화면으로 iOS 시뮬레이터와 Xcode를 실행시키는 것을 좋아한다. 이 기능을 사용하려면 그냥 터미널을 켜서 아래 명령을 실행시키면 된다.

defaults write com.apple.iphonesimulator AllowFullscreenMode -bool YES

시뮬레이터에 숨겨진 더 많은 기능을 사용하고싶으면 애플의 숨겨진 Internals 메뉴를 활성시키면 된다. 이렇게 하기 위해서는 루트 폴더에 AppleInternal이라는 빈 폴더를 만들자. 아래 명령을 실행시키고 시뮬레이터를 재시작하면 된다.

sudo mkdir /AppleInternal

4. iOS 시뮬레이터 화면 녹화하기

xcrun 명령어 유틸리티를 이용하면 시뮬레이터 창을 스크린샷 찍거나 비디오로 저장할 수 있습니다. 비디오를 찍기 위해서는 아래 명령을 실행시키세요.

xcrun simctl io booted recordVideo <filename>.<file extension>

예시:

xcrun simctl io booted recordVideo appvideo.mov

녹화를 멈추려면 control + c를 누르십시오. 파일이 만들어지면 현재 폴더에 저장됩니다.

5. 파인더에서 시뮬레이터에 파일 공유하기

Xcode 9부터는 시뮬레이터가 파인더 확장을 가지고 있습니다. 이것은 파이더 창에서 바로 파일을 공유할 수 있게 해줍니다. 그래도 파일을 시뮬레이터로 드레그&드롭해 주는게 더 빠른거 같네요.

아니면 아래 simctl 명령으로 이미지/비디오 파일을 전송할 수 있습니다.

xcrun simctl addmedia booted <PATH TO FILE>

6. sudo 인증시 지문 사용하기

맥북프로의 지문을 sudo 인증의 비밀번호로 사용하고 싶다면 /etc/pam.d/sudo를 수정하고 상단에 아래줄을 넣습니다.

auth sufficient pam_tid.so

이제 sudo로 지문을 사용할 수 있습니다.

7. 소리 알림과 함께 AutoLayout 컨스트레인트 디버깅하기

이번 방법은 AutoLayout 컨스트레인트를 디버깅하는데 훌륭한 벙법입니다. 그냥 실행시 UIConstraintBasedLayoutPlaySoundOnUnsatisfiable 인자를 넘겨주면 런타임시 컨스트레인트가 어긋날을 경우 소리가 납니다.

-_UIConstraintBasedLayoutPlaySoundOnUnsatisfiable YES

8. Xcode에서 사용할 수 없는 시뮬레이터 제거하기

이 조그만 명령어는 Xcode에서 사용할 수 없는 모든 시뮬레이터를 제거해 줍니다. 여기서 "unavailable"은 Xcode의 xcode-select 버전에서 사용불가능한 것을 의미합니다.

xcrun simctl delete unavailable

재밌었나요? 아래에 댓글을 달아주시면 고맙겠습니다.

이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은 - 블로그 댓글 - 페이스북 페이지(@나는한다번역-ios) - 트위터(@tucan9389) 으로 보내주시면 됩니다.

[번역] iOS Dev Weekly - 351 (서문)

tucan.dev — Thu, 17 May 2018 23:38:54 +0900

원문: https://iosdevweekly.com/issues/351참고: https://pilgwon.github.io/blog/2018/05/14/iOS-Dev-Weekly-351.html
pilgwon님 번역글을 보다가 빠진 부분이 있는것 같아서 제가 번역해봤습니다. 피드백은 댓글로 남겨주세요.

구글 I/O 컨퍼런스가 이번주에 열렸습니다. 여러분은 대부분 Google Duplex의 데모를 봤을 텐데요. 자세히 알아볼 예정은 아니지만, 제 생각을 정리하자면 다음과 같을 것입니다:

어시스턴트는 아래 몇가지 이유때문에라도 "이 전화는 구글 어시스턴트가 거는 것입니다.."같은 이야기로 시작해서 구별할 수 있어야합니다.
이런 세부 유스케이스에대한 기술 개념이나 윤리에대해서는 문제가 없습니다. 만약 이런 전화를 받는 사업자가 이런 종류의 전화를 원치 않으면 호환가능한 온라인 체계를 만들고 구글은 전화 대신에 이것을 사용할 수 있을 것입니다. 물론 우리는 미래에 이런 종류의 기술을 어떻게 다룰지 굉장히 조심스럽게 접근할 필요가 있지만, 아직 이게 종말의 시작까지는 아닌거 같습니다.
네, 수많은 어시스턴트는 단도직입적이고 짧았었습니다만 이것이 어쩌면 사람 반응을 줄이려고 했을지 궁금합니다. 만약 직접 대화를 시작하면 여러 대화가 정해지며 어시스턴트는 더 유연한 대화의 복잡한 대답을 시도하거나 다룰 필요가 없습니다. 이는 1번에서 언급한 것처럼 조수 자신을 확인한 경우에도 일어납니다.
항상 현실 세계에서는 잘못될 수 있으며, 이런 일이 일어났을때 어떻게 대처할지 저는 매우 궁금합니다. 어떤 부분에서 이게 컴퓨터라는것을 인정할 수 있을까요? 첫번째에서 이야기한것처럼 하면 훨씬 쉬워질 수 있을 것 같습니다.

구글도 모든 것을 생각했을 거라 확신하지만, 이것은 저도 처음에 생각했던 것입니다.

아무튼, 이 모든 것은 iOS(혹은 모바일)로 조금만 작업하면 할 수 있는 것들입니다. WWDC의 키노트는 일반 대중뿐만 아니라 개발자를 위한 키노트이기 때문에 우리를 위한 정말 유익한 뉴스와 눈에 띌만한 무언가가 몇 가지 있을 것입니다:

구글 어시스턴트는 엄청나게 많은 제3자앱을 지원하며, 이번 키노트에서 어마어마하게 많이 발표되었습니다. SiriKit은 지원된 도매인을 매우 잘 이해했야하므로 굉장히 한정적인 통합 가능성으로 출발했었습니다. 구글은 더 많이 개방된 API로 시작하였으며 이제는 그 도매인을 더 이해하기위해 모인 자료들을 이용하려하고 있습니다. 둘은 굉장히 다른 접근법입니다.
AR과 ML 프레임워크 이름 짓기가 웃긴 상황(원문 트위터)이 되고있습니다만 이런 기술들은 키노트에서 구글이 이야기한 거의 모든 주제였습니다. MLKit은 Firebase의 일부(원문)로써 iOS에서도 사용할 수 있으며 매우 흥미롭습니다.
App slices는 매우 멋지며 나는 사용자가 앱과 어떻게 상효작용하는지가 더 큰 부분이 되어간다는것을 확인할 수 있었습니다. 이것은 iOS 앱 확장같은 느낌이 났지만 다른 접근법을 사용합니다.
안드로이드 스튜디오(그리고 다른 리눅스 앱들)는 이제 크롬OS에서 돌릴 수 있습니다. 이건 데스크탑 리눅스의 해입니다!!

여튼 구글 I/O에서 나온 것들은 정말 흥미로웠지만 우린 iOS 얘기를 하려고 모였으니 iOS 얘기를 해봅시다.

Dave Verwer

이하, 아티클에대한 번역은 pilgwon 블로그 글을 참고해주세요.

[번역]앱에 Core ML 모델 합치기

tucan.dev — Thu, 17 May 2018 11:52:25 +0900

출처: [애플 공식 문서] Integrating a Core ML Model into Your App(원문)

앱에 간단한 모델을 추가하고, 모델에 입력 데이터를 넣은 뒤, 모델 예측을 실행시키는 예제입니다.

프로젝트 다운로드

SDKs

iOS 11.0+

Xcode 9.2+

Framework

Core ML

개요

이번 간단한 앱은 학습된 간단한 모델 (MarsHabitatPricer.mlmodel)을 사용하여 화성거주지 가격을 예측할 것이다.

여러분의 Xcode 프로젝트에 모델 넣기

모델을 Xcode 프로젝트에 넣기 위해서는 모델을 드레그해서 프로젝트 네비게이터에 넣어야한다.

Xcode에서 모델을 열면 모델 타입, 예상되는 입출력등 모델에대한 정보를 확인할 수 있다. 여기서 모델 입력값은 태양열 전지판과 온실 갯수, 그리고 거주지 크기(에이커 단위)이다.

코드에서 모델 생성하기

Xcode는 모델의 입출력 정보를 이용하여 자동으로 모델의 인터페이스를 생성하는데, 이 인터페이스는 여러분의 코드상에서 모델과 상호작용하는데 쓰일 것이다. MarsHabitatPricer.mlmodel의 경우 Xcode는 MarsHabitatPricer모델을 표현하는 인터페이스와 모델의 입력(MarsHabitatPricerInput), 모델의 출력(MarsHabitatPricerOutput)을 생성한다.

모델을 생성하려면 만들어진 MarsHabitatPricer 클래스 생성자를 사용하자.


let model = MarsHabitatPricer()

모델에 넣을 입력값 가져오기

이번의 간단한 앱에서는 사용자로부터 모델의 입력값을 가져오기위해 UIPickerView를 사용한다.


func selectedRow(for feature: Feature) -> Int {
    return pickerView.selectedRow(inComponent: feature.rawValue)
}

let solarPanels = pickerDataSource.value(for: selectedRow(for: .solarPanels), feature: .solarPanels)
let greenhouses = pickerDataSource.value(for: selectedRow(for: .greenhouses), feature: .greenhouses)
let size = pickerDataSource.value(for: selectedRow(for: .size), feature: .size)

예측을위해 모델 사용하기

MarsHabitatPricer 클래스는 자동으로 생성된 prediction(solarPanels:greenhouses:size:) 메소드를 가지는데, 이 메소드는 모델 입력값으로부터 가격을 예측하는데 쓰인다. 이번의경우 태양열 전지판과 온실 갯수, 그리고 거주지 크기(에이커 단위)를 넣는다. 이 메소드는 MarsHabitatPricerOutput 인스턴스를 결과로 내뱉는다.


guard let marsHabitatPricerOutput = try? model.prediction(solarPanels: solarPanels, greenhouses: greenhouses, size: size) else {
    fatalError("Unexpected runtime error.")
}

예측된 가격을 가져오기위해 marsHabitatPricerOutput 의 price프로퍼티에 접근하여 앱 UI에 표시하자.


let price = marsHabitatPricerOutput.price
priceLabel.text = priceFormatter.string(for: price)

주의
자동으로 생성된 prediction(solarPanels:greenhouses:size:) 메소드에서 에러를 던질수 있다. Core ML으로 작업하면서 만나게될 가장 일반적인 에러 종류는 입력 데이터의 내용과 모델이 기대하는 내용이 서로 일치하지 않는 경우입니다(가령 잘못된 이미지 포멧이라던지).

Core ML 앱을 빌드하고 실행하기

Xcode는 Core ML 모델을 디바이스에 최적화시켜 컴파일한 후 리소스 안에 넣어둘 것입니다. 최적화된 모델은 앱번들안에 들어가며, 이 모델은 앱이 디바이스에서 실행되는동안 예측을 만드는데 쓰입니다.

함께 보기

첫번째 단계

Core ML 모델 가져오기(원문) 여러분의 앱에서 사용할 Core ML 모델 얻기
학습된 모델을 Core ML 모델로 변환하기(원문) 제3자 기계학습 툴에서 학습된 모델을 Core ML 포멧으로 변환하기

iOS 기기에서 Tensorflow 모델 실행시키는 방법들

tucan.dev — Wed, 16 May 2018 15:27:56 +0900

1. Tensorflow mobile for iOS(Deprecated)

pod 'TensorFlow-experimental'
~~C++ 인터페이스~~
~~pod(의존성 관리 툴)으로 프로젝트 환경을 구축하면 450MB가 넘음. 여러 플랫폼을 묶다보니 용량이 큼. 예제를 앱으로 말면 약 25MB정도로 만들어짐.~~
Tensorflow Lite로 대체됨.

2. Tensorflow Lite

iOS 기기에서 TensorFlowLite 로 .tflite 모델을 사용할 수 있음

TensorFlow Lite를 바로 사용할 시 C++ 인터페이스
TensorFlow Mobile의 다음 버전
더 작은 바이너리 크기
적은 의존성, 더 나은 퍼포먼스

iOS 기기에서 .tflite 모델을 실행시킨 결과

3. Core ML

iOS 기기에서 Core ML 로 .mlmodel 모델을 사용할 수 있음

Swift/Objective-C 인터페이스(Core ML)
텐서플로우(.pb)를 CoreML(.mlmodel)로 변환하여 사용.
애플이나 구글의 공식 프로젝트는 아니지만 스타가 많은 프로젝트.

4. MLKit with Firebase

Firebase 프레임워크에 들어있는 MLKit 로 .tflite 모델을 Swift 인터페이스로 사용할 수 있음

Swift, Objective-C 인터페이스
18.05.09 구글I/O에서 발표
기본 ML 기능 제공
- Text Recognition (OCR)
- Face Detection
- Label Detection
- Cloud Landmark Detection
- Cloud Text Recognition
- Cloud Label Detection
- Custom Model Object Detection(.tflite 모델 사용)

iOS 기기에서 MLKit으로 .tflite 모델을 실행시킨 결과

+. tensorflow + swift

기계학습 모델을 만드는 새로운 방법.18년5월에 처음 공개되었고 개발중..

[번역]우리가 WeWork 인터뷰에서 사용하고 있는 제품 디자인 예제들

tucan.dev — Tue, 15 Aug 2017 17:18:09 +0900

제목: Product Design Exercises We Use At WeWork Interviews

원문: https://blog.prototypr.io/product-design-exercises-we-use-at-wework-interviews-2ee1f5a57319

저자인 Artiom Dashinsky는 @hvost와 dashinsky.com에서 만날 수 있습니다.

제품을 생각하는 스킬을 연습하고기위해 이 예제들을 사용해보고, 디자인 지원자들을 어떻게 시험하는지 배우자.

디자인 커뮤니티는 운좋게도 Dribbble, Behance, Daily UI등과같은 많은 훌륭한 리소스들이 있다. 이 리소스들은 다른 비주얼 작업을 볼 수 있게 해주고, 여러분의 것들을 보여주고 피드백을 받을 수 있다. 이에반해 체계적인 비주얼-중심의 디자인 커뮤니티 시장은 디자인의 Dribbble화(어떻게 생겼고 어떻게 동작할지에 사로잡힌)를 만들어낸다. 이 프로세스 입문의 디자이너들의 생각에 잘못된 이해를 만들어줬다. 바로 "제품 디자인 = Dribbble" 이다.

입문 디자이너들은 제품을 생각하는 스킬로 작업해야한다.

Julie Zhuo가 이야기하는 커리어 단계와 그녀의 놀라운 The Beginning of your Design Career글

오늘날 최고의 비지니스는 디자이너들이 미학보다는 회사가 옳은 사람들을 위한 옳은 기능을 만드는 것을 보장하는 역할을 해야한다고 이해하고있다. 불행히도 이런 비지니스들은 주니어 디자이너들을 고용해서 어떤 과제를 해결할지 적절하게 소통하고 있지 않았다.

제품 생각을 연습할 수 있는 리소스가 부족하기도하고, 이것은 개선하기위해 작업하는 디자이너 스킬과 최고 회사들이 그들에게 기대하는 스킬 사이에서 갭을 만들었다.

만화 저작권: Andrew Hwang

디자인 커뮤니티가 어떻게 도와줄 수 있을까

디자인 커뮤니티가 이 갭을 최소화시키는데 좋은 일을 할 수 있으므로, 그 결과 우리는 시장에서 디자이너를 더 잘 준비할 수 있고 산업 앞으로 갈 수 있다. 여기에 우리가 도울 수 있는 몇가지가 있다.

디자이너:

제품 생각을 연습하기위한 리소스를 만들기
인터뷰에서 해볼 수 있는 디자인 테스크 숙제를 공유하기. 그러나 여러분이 공유하는 것이 회사 작업과 관련된 민감한 정보를 드러내지 않도록 조심해라.

회사:

도전과제 종류의 명확성을 높히기위해 케이스 연구 만들기
당신의 고용 프로세스에 더 투명성을 넣어, 신입 디자이너들이 고용되고서 어떤 종류의 문제를 제품 디자이너들이 풀것을 기대하는지 배울 수 있게 할 수 있다.

첫걸음 떼기

WeWork Digital 디자인 팀의 창의적인 리드: Stephanie Wu and Andrew Couldwell. 사진: Nina Robinson for Inside Design: WeWork

기술 회사들은 제품 디자이너 직군에서 조금 다른 접근법의 인터뷰를 가진다. 그러나 이들 모두 지원지의 제품 생각을 확인하는 목적이다. 페이스북은 제품에대해 디자인 논평을 물어보고, 구글은 제품 생각과 관련된 화이트보드 과제를 한다 인터렉션 디자인에 아주 초점을 두면서 말이다.

WeWork에서는 제품 디자이너 인터뷰 프로세스 중 일부분은 화이트보드 과제도 포함된다. 우리는 커뮤니티에 그 몇가지를 공유하기로 결정했다.

이 과제를 어떻게 사용할까

디자이너는 그들의 제품 생각을 연습하는데 사용할 수 있다.
입문 디자이너는 포트폴리오에 넣는데 사용할 수 있다.(나를 믿어보자. 불필요한 위키피디아 리디자인보다 훨씬 낫다.)
회사는 고용 프로세스에서 사용할 수 있다.

우리는 왜 화이트보드 과제를 하는가?

제품 생각을 테스트하면서, 화이트보드 과제는 지원자를 아래와같은 능력에대해 테스트하기 좋은 도구이다.

팀과 효율적으로 의사소통하기
비판적으로 생각하고 좋은 질문 하기
피드백/건설적 비판 다루기
데드라인이 다가올때 새로운 문제에대해 높은 압박의 환경에서의 능력
팀이 매일매일 이 사람과 협력하고 싶은 종류의 사람인지

결과물에는 이것을 포함할 수 있다

모든 과제들은 우리 사무실 현장에서 시행되는 것이다. 지원자들은 60분이 주어지며, 곧 15-20분 발표와 토론을 한다.

과제 목록

아래에는 당신이 해볼 수 있는 17가지 과제가 있다.

1. 룸메이트

: 전세계 인구의 54%는 도시에 살며, 남자의 평균 결혼 나이는 29살이고(20년전 26세 이상) 여자는 27살이다(같은 기간의 23세 이상). 이런 트렌드에서, 도시 거주자들은 20대의 대부분을 룸메이트와함께 사는 경향이 있다. 그러나 더 많은 사람들이 도시로 들어오기 때문에 좋은 룸메이트를 찾고 유지하는 것은 더 힘들다.

모바일 제품 경험을 디자인하는데, 서울에서 이상적인 룸메이트를 안전하게 찾을 수 있게 해주어 밀레니얼 세대를 찾을 수 있어야한다. 룸메이트를 찾고 있을 뿐만 아니라 아파트도 찾고 있는 사람의 관점에서 경험을 디자인하라. 이상적인 룸메이트가 발견되고나면 이 제품이 더 나은 룸메이트 경험을 만들기위해 어떤 다른것을 할 수 있을까?

"좋은 룸메이트를 찾기/유지하기"같은 행로에서 고통스러운 지점을 확인해보고 이 고통스런 점을 해결하는 방법을 찾는 당신을 지켜보고있다.

제약사항: iOS와 안드로이드의 현재 모바일 기능을 붙여야한다.

2. GoPro는 새로운 앱이 필요하다

GoPro의 미칠듯한 성곡적 액션카메라는 세계적인 발자취를 가졌다. 아제 카메라의 비용은 5만원 이하고 수많은 사람들은 그들의 삶에 모험을 기록하는데 사용하고 있다.

그러나 GoPro는 문제를 가지고 있는데, 현재 모바일 앱이 3가지에만 좋다는 것이다. 그들의 카메라로 찍은 사진을 보는데, 이 사진을 편집하는데, 세계의 다른 사람들이 찍은 사진을 보는데. 세계를 바꾸고있는 카메라를위해, 이 앱은 인정하는바와같이 무디며 표면을 밀어내지 못한다.

GoPro 회사는 당신에게 새롱누 모바일 앱을 만들 임무를 주었고, 하나는 사진 환경에서 뛰어나고(인스타그램, Vsco cam, snapchat), 하나는 밀레니얼 세대를 어필할 것이다. 이렇게 새롭고 개척적인 것에서 완벽한 GoPro 앱은 어떤 일을 해야할까?

제약사항: 이것은 iOS 앱이며, 제안된 모든 기술은 오늘이나 12달안에 시장에서 사용할 수 있어야한다.

3. 구글 엔터프라이즈 판매 깔때기(Google Enterprise Sales Funnel)

(역자: 번역하다가.. 힘들어서 원문 넣었어요.)

You are consulting Google on an important strategic decision for their enterprise offerings; they want to know whether it’s worth introducing a sales funnel management tool onto their Enterprise Gmail interface. Google believes that because a majority of their enterprise users discuss business on their email platform and because they are the lexicon of most people’s business contacts, that they are in a position to both make the sales process more efficient and make the likelihood of closing business higher.

26% of Google’s Enterprise users engage in sales weekly, 40% engage in some sort of funnel management (whether sales, hiring, or some other decision funnel).

A typical sales funnel includes Leads, Inquiries, Prospects, Quotes and finally a new customer.

Recommend a funnel management flow to Google. Make sure the flow accounts for a user making initial contact with a lead from within gmail and then managing that lead through the entire funnel. What else can gmail do to put the odds of closing business in favor of their user?

제약사항: 없음

4. 비지니스 승객

자동차가 스스로 운전하는 세상에서 살고있다고 가정하자. 집집마다의 경험을 디자인하자. 이것은 4명의 비지니스 직원이 주일에 뉴욕에서 볼티모어까지 최대 4시간 여행할 수 있게 만들 수 있다.

제약사항: 우리가 허용하는 기술 도약은 모든 자동차자 스스로 운전할 수 있는것 뿐이다. 제안된 다른 기술들은 반드시 오늘날 존재하거나 6-12개월엔에 현실적으로 존재해야한다.

가정: 비지니스 직원과 "새로운 클라이언트"의 어떤 종류도 고를 수 있다. 비지니스 직원의 나이는 28살부터 45살이다.

5. Spotify Artist Actalogue Manager

스포티파이(Spotify)는 아티스트에게 그들의 플렛폼에서 그들의 카탈로그 컨트롤을 제공하도록 결정해왔다. 제일 처음 아티스트들은 자신의 엘범을 관리하고, 자신의 아트워크를 올리고, 특정 제품을 판매하며, 그들의 음악에 가사를 넣는등, 그들이 필요한 조건에 달렸다.

맥-기반 에디터와 아티스트 관리 시스템을 만들어서 아티스트들이 Spoty에서 그들의 presence를 관리할 수 있도록 한다. 솔루션은 Spoty에 현존하는 모든 아티스트 컨텐트를 대상으로 하지만, 자유롭게 창의적으로 넣고 아티스트가 유용해할 수 있는 추가 기능을 넣을 수 있다.

제약사항: 당신은 맥 데스크톱 앱을 디자인하고있다. OS의 기능에 들어가있어야 할 것이지만, 그들이 여기에 적용하지 않으므로 어떤 웹과 관련된 기술 제약은 무시해도된다.

6. E-ink

지금 e-ink의 가격은 0원이다. 어떤 인터페이스가 집에서 매일매일 삶을 더 흥미롭게 만드는데 혁신적일 수 있을까? 포괄적으로 그리고 잘 생각해낸 리스트를 찾아보자. 비주얼없이 설명하기 힘든 몇가지 인터페이스 예시를 만들어야한다고 생각되면 먼저 리스트를 만들어라.

제약사항: 없음

7. Crisis News Network

"Crisis News Network" 혹은 CNN은 속보와 세계적인 다른 뉴스들의 가장 큰 기업합동(syndicate)이다. 그들은 millennial 청중에 포커스를 맞추고있다. 그들은 자신의 사이트(데스크톱)에서 뉴스 경험을 다시 생각하기위해 당신을 고용하였다.

오늘 세대의 뉴스 소비자를 위해 주목할만한 뉴스 사이트를 디자인하라. millennial들이 컨텐트를 소비하고 공유하는 방법을 직접 찾아보자. CNN은 "그들이 어떤것을 항상 해내는 것"에대해 독단적이고 싶어하지 않는다. 그들은 장벽을 깨고싶고, 그들은 몇가지 위험을 안고서도 새로운 곳으로 가고싶어하고, 당신이 업계에 변화를 만들기를 기대하고 있다.

홈페이지와 스토리페이지를 디자인하라.

제약사항: 현존하는 웹 기능을 사용하라.

8. 오디오북을 개인화하기

오디오북과 팟케스팅은 모바일에서 오디오 부분을 가장 빠르게 성장했다. 오디오북을 듣는 사용자들은 페이지 한쪽 모서리를 접거나, 원하는 곳에 밑줄 긋거나, 좋아하는 페이지를 메모하는 일을 즐기지 않는다... 그들은 책을 소유하고 오랫동안 보아서 향수를 불러 일으키는 면을 잃는다. 오디오 경험으로 모바일에서 너무 많이 있게된다.

매우 개인적이고, 인터렉티브한 오디오북 혹은 팟케스트 모바일 앱을 디자인하라. 그리고 책이 할 수 있는 것보다 더 유용한 기능을 가져다 주어야한다.

제약사항: 제안된 모든 기능은 현존해야하거나, 다음 6개월안에 실현가능해야 한다.

9. 오디오북에서 특정 오디오 섹션과 인터렉트하기

주머니에는 iPhone을 가지고있고, 손목에는 Apple Watch, 헤드폰을 끼고있으며, 삶을 바꾸는 오디오북이 그 안에서 실행하고있다. 사용자가 아래중 하나 혹은 그 이상이 되는 인터렉션 플로우를 디자인하라.

- "하이라이트" 오디오, 책에서 텍스트에 하이라이트하는 것과 비슷하다. 사용자가 컨텐트에 하이라이트하면 이제 어떤 일을 할 수 있을까?

- 세계에있는 다른 청취자의 book을 듣기. 다른 청취자의 컨텐트에 당신의 이모션을 공유하자.

- 당신이 찾은 흥미로운 오디오북 일부분에 메모를 하기.

제약사항: 당신이 가진 기기의 기술적 한계내에서 작업하라.

10. 여행하는 영업사원을 위한 캘린더

발렌티나(사람이름)는 행운의 500개 회사를위해 영업과 비지니스 개발을 선도한다. 그녀는 한달 4주중에 3주를 여행하며, 여행은 거의 대부분 국외로간다. 다른 타임존 여행과 다른 도시에서 바쁜 회의 스케줄 사이에서, 그녀는 올바른 시간에 올바른 장소를 보여주는 과제를 찾아냈다. 회의시간을 제안하고, 타임존 변경을 책임지고, 그녀가 항상 회의에 제시간에 가도록 선처할만큼 스마트한 캘린더 플로우와 인터페이스를 디자인하라.

제약사항: 솔루션은 모바일친화적으로 만들고 오늘날의 실용적인 기술을 사용해야한다.

11. 매일 음식 섭취

게리(사람이름)는 Gen-Xer이다. 그는 아직 30대 초반의 독신자이다. 전문대 교육을 받고 기술 분야에서 뛰어나다. 최근 그는 의사에게서 비만 초기 증상을 진단받았다. 게리는 어떤 기기를 이용하여 그의 일일 음식 섭취량을 추적하고 과식하는 신호를 그에게 보여줄때 중재하도록 만들어 유입 흐름에 가장 낮은 장벽을 디자인하라. 그의 삶은 이것에 달렸다.

제약사항: 모든 기술과 제안들은 반드시 오늘날 사용할 수 있는 것이여야한다.

12. Garbage

평균 중산층의 미국인 가족은 그들의 라이브스타일을 유지하기위해 4천파운드 이상 버린다. 하루기준 대부분은 버려지거나 재활용된다. 미국인들이 버리는 것을 어떻게 스스로 더 인지하게 만들 수 있을까?

기술은 여게서 돕는 역할을 맡았다고 가정하자. 사용자 인터페이스가 쓰레기 처분을 관리하는데 도움을 주게 만들자. 하드웨어와 소프트웨어가 함께 이 문제를 해결하는 가능성으로 자유롭게 재치있게 해보자.

제약사항: 제안된 기술은 오늘날 존재하거나 6개월내에 시장에서 사용할 수 있어야한다.

13. NYC 메트로카드

NYC 메트로카드 시스템은 몇년동안 바뀌지않고 남아있다. 메트로카드 기계의 인프라 비용, 메트로카드를 사기위해 오랫동안 줄을 서서 기다리고, 더러운 기계를 만져야하고, 메트로카드를 잃어버릴 수 있는 잠재성과, 당신 카드를 넣어 쉽게 게임할 수 있는 체제로 도시에 100만달러의 비용이 나가고 사용자 경험에서 필요한 것이 많이 남아있다.

메트로를 매일 사용하는 사용자와 한번만 메트로를 이용하는 멀리서온 방문자에게 물리적인 NYC 메트로카드 없이 이용할 수 있는 새로운 시스템을 디자인하라.

제약사항: 제안된 모든 기술은 오늘날 시장에서 사용할 수 있는 기술이어야한다.

다른 과제들

14. 당신이 많이 좋아하고 많이 사용하는 앱을 골라서, 어떻게 디자인할지 설명하고 왜 했는지 설명하라.

15. 오늘날 전세계 인구의 54%는 도시에 살며, 2050년에는 66%까지 증가할것으로 전망하고있다. 전반적인 세계인구 증가와 결합된 도시화는 2050년까지 도시 인구에 또다른 25억명이 증가할 수 있는 전방이다. 정부를 도울 수 있고 이 과제를 다룰 수 있는 디지털 제품을 생각해보라.

16. 애완동물 관리는 600억달러 규모의 시장이다. 이런 종류의 서비스 수요를 활용할 수 있는 제품을 생각해보라.

17. 당신이 잘 몰랐지만 Amazon.com이 서비스 하고 있는 타겟 유저를 하나 골라라. 이 유저 타입을 끌기위해 Amazon.com을 어떻게 리디자인할 수 있을까?

우리는 구인중이다

WeWork는 뉴욕에있는 디지털 팀에 조인하기위해 재능있는 제품 디자이너를 항상 찾아보고 있다. 사람들이 일하는 것과 삶을 어떻게 바꿀지에대해 이야기를 더 들어보고 싶거나, 이 일에 동참하고 싶으면 나에게 한줄 남겨달라.

Ariel Verber, Shem Magnezi, Andrew Couldwell에게 감사하다.

이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은

블로그 댓글
페이스북 페이지(@나는한다번역)
이메일(canapio.developer@gmail.com)
트위터(@canapio)

으로 보내주시면 됩니다.

[번역]iOS11: 모두를 위한 기계학습

tucan.dev — Tue, 15 Aug 2017 15:10:38 +0900

제목: iOS11: Machine Learning for everyone

원문: http://machinethink.net/blog/ios-11-machine-learning-for-everyone/

WWDC 2017에서 한가지는 확실하게 만들었다. 애플은 기기에서의 기계학습을 확실히 밀고 있다.

그리고 앱 개발자들이 여기에 조인할 수 있도록 가능한 쉽게 만들고 싶어한다.

작년 애플은 기본 컨볼루셔널 신경망(basic convolutional networks)을 위한 Metal CNN and BNNS frameworks를 발표했다. 올해는 Metal, 새로운 컴퓨터 비젼 프레임워크, Core ML의 수많은 수가사항이 있다. 툴킷은 ML 모델을 여러분의 앱에 아주 쉽게 넣을 수 있게 해준다.

이 블로그 포스팅에서는, iOS11와 macOS10.13에서 새로운 기계학습에대한 내 생각(과 내 경험)을 공유하려고 한다.

Core ML

Core ML은 WWDC에서 많은 주목을 받았고, 그 이유는 알기 쉽다. 바로 많은 개발자들이 그들의 앱에 넣으려고 했던 프레임워크이기 때문이다.

이 API는 꽤 간단하다. 당신이 할 수 있는 것은 다음과 같다.

학습된 모델을 불러오기
예측 만들기
~~개이득~~!!!

이 말이 제한적으로 보일 수 있지만, 실제로 모델을 불러와서 예측을 하는 것은 보통 여러분의 앱에서 하고 싶었던 모든 것일 수 있다.

예전에는 학습된 모델을 불러오는 것이 굉장히 힘들었다(사실 library to take away some of the pain에대한 글을 썼었다). 그러니 이제 단지 두단계로 간단해져버려 굉장히 행복하다.

모델은 .mlmodel 파일안에 담겨있다. 이것은 새로나온 공개형 파일 포멧(open file format)으로 여러분의 모델, 입력과 출력, 클래스 레이블 그리고 데이터에 일어나는데 필요한 전처리에서 그 레이어를 표현한다. 또한 학습된 모든 파라미터들을 담고있다(가중치와 기저).

모델을 사용하는데 필요한 모든것이 이 한 파일 안에 들어 있는 것이다.

여러분은 간단하게 여러분의 프로젝트에다 이 mlmodel 파일을 떨어뜨리면 Xcode가 자동으로 스위프트(혹은 Objective-C)를 감싸는 클래스로 생성하며, 이런 과정이 모델을 사용하기 굉장히 쉽게 만들어준다.

예를들어, 여러분의 Xcode 프로젝트에 ResNet50.mlmodel 파일을 추가했으면, 이렇게 작성할 수 있겠다.

let model = ResNet50()

모델을 인스턴트화한다. 그리고 아래에는 예측을 한다.

let pixelBuffer: CVPixelBuffer = /* your image */

if let prediction = try? model.prediction(image: pixelBuffer) {
  print(prediction.classLabel)
}

그리고 이게 전부이다. 모델을 불러오거나 스위프트에서 그 결과물을 변환하기위해 다른 코드를 짤 필요가 없다. 이 모든것을 Core ML과 Xcode가 관리해준다. 멋지다!

주의: 화면뒤에서 무슨일이 일어나는지 알고싶으면, Project Navigator에 mlmodel 파일을 선택하여 버튼을 클릭하면 생성된 헬퍼 코드로 파일을 볼 수 있다.

Core ML은 모델을 CPU에서 돌릴지 GPU에서 돌릴지 스스로 결정할 것이다. 그리하여 가용의 리소스 사용을 최적화할 수 있게 해준다. 또한 Core ML은 특정 부분만 GPU에서 동작하고(많은 계산이 많이 필요한 작업) 다른 부분은 CPU(메모리가 많이 필요한 작업)에서 동작하도록 쪼갤 수 있다.

Core ML이 CPU를 사용할 수 있는 능력은 개발자들에게 또다른 큰 이점을 준다. iOS 시뮬레이터에서 돌려볼 수 있다는 점이다(어떤것은 Metal에서 불가능한데, 이것 또한 유닛테스트로 잘 돌아가지 않는다).

Core ML이 지원하는 모델은 무엇인가?

위의 ResNet50 예제는 이미지 분류기이지만, Core ML은 여러 타입의 모델을 다룰 수 있다.

support vector machines(SVM)
tree ensembles such as forests and boosted trees
linear regression and locgistic regression
neural networks: feed-forward, convolutional, recurrent

이 모든 것들은 회기(regression)뿐만 아니라 분류(classification)에도 사용될 수 있다. 추가로 여러분의 모델은 one-hot encoding, feature scaling, imputation of missing values등과같은 전형적인 ML 전처리 과정을 담고 있을 수 있다.

애플은 학습시킨 여러 모델을 다운로드 받을 수 있게 해놓았다. Inception v3, ResNet50, VGG16같은 것이 있는데, 파이썬 라이브러리 Core ML Tools로 자신만의 모델을 변환할 수도 있다.

현재 여러분은 Keras, Caffe, scikit-learn, XGBoost, libSVM로 학습한 데이터를 변환할 수 있다. 이 변환 툴은 지원하는 버전에대한 약간의 명세이다. 예를들어 Keras 1.2.2는 동작하지만 2.0은 아닌. 다행인점은 이 도구가 오픈소스여서 미래에는 더 많은 학습 툴킷을 지원할 부분에는 확신할 수 있다.

그리고 다른 모든것이 실패하면 언제나 여러분만의 변환기를 만들 수 있다. mlmodel 파일 포멧은 공개형이고 꽤 직관적으로 사용할 수 있다(photobuf 포멧 내에 있고, 스팩은 애플이 명세해놓음).

한계

Core ML은 모델을 빨리 불러와서 여러분의 앱에서 실행하기에는 훌륭하다. 그러나 이런 간단한 API로는 그 한계를 가지고 있다.

지원하는 모델 타입들은 감독 기계학습(supervised machine learning)이다. 비감독 학습 알고리즘이나 강화 학습은 안된다. (비록 "제네릭" 뉴럴 네트워크 타입을 지원하는데, 이것을 이용할 수는 있을것 같다)
기기에서 학습은 지원하지 않는다. 당신은 오프라인 툴킷을 사용하여 모델을 학습시키고 모델을 Core ML 포멧으로 변환해야한다.
Core ML이 특정 레이어 타입을 지원하지 않는다면, 사용할 수 없다. 이 점에서 여러분이 직접 계산한 커널로 Core ML을 확장시키는게 불가능하다. TensorFlow같은 툴들이 질반 목적 컴퓨테이셔널 그래프를 만들기위해 사용되는 곳은, mlmodel 파일 포멧은 유연성과는 좀 멀다.
Core ML 변환 툴은 제한된 수의 학습 툴과 명세한 버전만 지원한다. 예를들어 TensorFlow에서 모델을 학습했으면, 이 툴을 사용할 수 없고 여러분의 변환 스크립트를 작성해야할 것이다. 그리고 내가 덫붙이자면, 여러분의 TensorFlow 모델이 mlmodel에서 지원하지 않는 것을 하고 있다면, Core ML에서 모델을 사용할 수 없다.
중간 레이어(intermediate layer)에서 만들어진 아웃풋을 볼 수 없다. 네트워크의 마지막 레이어에서 나온 예측만 볼 수 있다.
100% 확신이 되진 않지만, 모델 업데이트를 다운받는 것이 문제가 있어 보인다. 여러분이 다시 학습시키고 싶은데, 바뀐 모델바다 앱의 새로운 버전을 내고 싶지 않으면 Core ML은 여러분에게 적절하지 않을 것이다.
Core ML은 (편의를위해) CPU에서 실행하는지 GPU에서 실행하는지 숨기는데, 이것이 앱을 위해 잘 동작할거라 믿어야만 한다. 당신이 아무리 아무리 원한다고 해도 Core ML에게 강제로 GPU에서 실행하라고 할 수 없다.

당신이 이런 한계들과 공존할 수 있다면, Core ML은 당신에게 맞는 프레임워크이다.

그렇지않거나, 전체를 컨트롤 하고 싶다면, Metal Performance Shaders나 Accelerate 프레임워크로 여러분만의 것을 만들어야할 것이다.

물론 실제 마법이 Core ML에 있진 않지만, 여러분의 모델에 들어있다. 여러분이 시작할때 적절한 모델을 가지고 있지 않다면 Core ML은 소용없을 것이다. 그리고 모델을 설계하고 학습시키는것은 기계학습에서 어려운 부분이다.

간단한 데모 앱

Core ML을 가지고 놀아보려고 간단한 데모를 만들었다. 언제나처럼 깃헙에서 소스를 확인할 수 있다.

이 데모 앱은 고양이 사진을 분류하기위해 MobileNet architecture을 사용했다.

원래 이 모델은 Caffe에서 학습되었다. 이것이 mlmodel 파일로 변환하는데 약간의 노력이 들게 만들었으나, 한번 변환한 모델로 만들고나니 앱에서 빌드하기 굉장히 쉬었다. (변환 스크립트는 깃헙 저장소에 들어있다)

앱은 아직 멋지지 않지만(단순히 정적인 이미지에대해 상위 5가지 예측의 아웃풋을 낸다) Core ML을 어떻게 쉽게 사용했는지 보여준다. 그냥 코드 몇줄만이 필요할 뿐이었다.

주의: 데모앱이 시뮬레이터에서는 잘 동작하지만 기기에서는 크래쉬가 난다. 읽어내려가서 왜 그런지 찾아내보자 ;-)

물론 안에서 무슨일이 일어나는지 알고싶었다. 실제로 mlmodel 파일이 mlmodelc 폴더에 컴파일되었으며 이 폴더는 여러분의 앱 번들 안에 있다. 이 폴더는 여러 다른 파일들, 몇몇 바이너리, 몇몇 JSON들을 가진다. 따라서 여러분의 앱에 실제로 넣기전에 Core ML이 어떻게 mlmodel을 변환하는지 볼 수 있다.

예를들어 MobileNet Caffe 모델은 소위 Batch Normalization 레이어라 불리는 것을 사용하며, 이것들이 변환된 mlmodel 파일안에 들어있다는 것을 확인했다. 그러나 컴파일된 mlmodelc에서는 Batch Normalization 레이어가 보이지 않았다. 이것은 Core ML이 모델을 최적화시켰다는 좋은 소식이다.

mlmodelc는 여전히 스케일링 레이어(scaling layer)를 포함하며 반드시 필요하지 않아 보이므로 좀 더 모델의 구조를 최적화할 수 있을것 같아 보인다.

물론 아직 iOS11 베타1버전이고 Core ML은 아마 더 개선될 것이다. 그 말은, Core ML에 넘겨주기전에 여러분의 모델을 최적화할 필요가 있다는 뜻이다. (“folding” the Batch Normaliza) 그러나 그렇게하면 특정 모델을위해 측정하고 비교해야할 것이다.

여러분의 모델이 CPU에서 실행될때와 GPU에서 실행될때 같은지도 확인해야할 것이다. 내가 언급한것처럼 Core ML은 모델을 CPU에서 돌릴지(Accelerate 프레임워크를 사용하여) GPU에서 돌릴지(Metal을 사용하여) 정한다. 결국 이 두 구현은 다르게 동작할 것이다. 그러니 둘 다 테스트해봐야한다!

예를들어 MobileNet은 "depthwise" 컨볼루션 레이어라 불리는 것을 사용한다. 이 원래 모델은 Caffe에서 학습되었고, 정규 컨볼루션의 groups 프로퍼티와 아웃풋 채널 수를 같게 만들어 depthwise 컨볼루션을 지원한다. 결과로나온 MobileNet.mlmodel 파일은 동일하지 않다. 이것이 iOS 시뮬레이터 안에서는 잘 동작하겠지만 실제 디바이스 위에서는 크래쉬가 난다!

시뮬레이터는 Accelerate 프레임워크를 사용하지만 실제 디바이스는 Metal Performance Shaders를 사용하여 생긴 문제이다. 그리고 Metal이 데이터를 인코딩하는 방법때문에 MPSCNNConvolution 커널은 제한되어 그룹의 수와 아웃풋 채널의 수를 같게 만들 수 없게 되었다. 아이고!

나는 애플에 버그리포팅을 제출했지만 내 요점은 이렇다. 시뮬레이터에서 모델이 잘 동작한다는게 디바이스에서 잘 동작할거라는 의미는 아니다. 테스트를 해보아라!

얼마나 빠른가?

나의 새로운 10.5" iPad Pro가 다음주까지 도착하지 않기 때문에(역자: 부럽습니다) Core ML의 속도를 시험해보지 못했다

나는 특별히 MobileNets을 실행시키는데 나의 Forge library를 이용할때와 Core ML을 이용할때 그 속도 차이가 어떻게 되는지 관심이 갔다(아직 초기 베타 단계에 있다).

채널을 고정하라! 공유할 데이터가 생기면 이 섹션을 업데이트 할 것이다.

Vision

다음으로 이야기할것은 새로나온 Vision 프레임워크이다.

여러분도 이름에서 추측했을지 모르겠지만, Vision은 컴퓨터비젼(computer vision) 테스크를 실행시켜준다. 과거에는 이를위해 OpenCV를 사용해야했었는데, 이제 iOS는 자신만의 API를 가지게 되었다.

Vision이 수행할 수 있는 일의 종류들이다

이미지안에서 얼굴 찾아내기. 각 얼굴에대해 사각형을 만들어준다.
안면의 세부적인 특징 찾아내기. 눈이나 입의 위치나, 머리의 모양 등.
이미지에서 사각형모양으로된 것을 찾아내기. 표지판같은것들.
비디오에서 움직이는 물체 추적하기.
수평성 각도 알아내기
두 이미지를 변형하여 그 내용을 정렬하기. 사진들을 합성할때 유용하다.
이미지안에 포함된 텍스트 영역 감지하기.
바코드 감지와 인지.

이 작업들중 몇몇은 이미 Core Image와 AVFoundation으로 가능하지만 이제 일관된 API로 한 프레임워크안에 들어왔다.

여러분의 앱이 이 컴퓨터비젼 작업중 하나가 필요할때, 더이상 여러분이 직접 구현하거나 다른 라이브러리를 사용할 필요가 없다. 그냥 Vision 프레임워크를 사용하면 된다. 더욱 강력한 이미지 처리를위해 Core Image 프레임워크와 합쳐서 사용할 수도 있다.

더 나은 것은, Core ML을 작동시키기위해 Vision을 사용할 수도 있다는 점이다. 그리하여 뉴럴 네트워크를 위한 전처리 단계로서 이런 컴퓨터 비젼 기술을 사용할 수 있게 해준다. 예를들어, 사람 얼굴의 위치와 크기를 감지하는데, 그 영역에 비디오 프레임을 자르는데, 이미지에서 얼굴이 있는 부분에 뉴럴럴 네트워크를 실행시키는데 Vision을 사용할 수 있다.

사실 이미지나 비디오와 함께 Core ML을 사용하면 항상 Vision을통해 가는것이 알맞은 방법이다. 가공되지않은 Core ML로는 여러분의 입력 이미지는 모델이 예상하는 포멧안에 있도록 해야하지만, Vision으로는 프레임워크가 이미지 리사이징 등에 주의해야한다. 이것으로 여러분의 추가 노력을 조금 절약해줄 것이다.

코드에서 Core ML을 작동시키기위한 Vision 사용은 다음과같이 생겼다.

// the Core ML machine learning model
let modelCoreML = ResNet50()

// link the Core ML model to Vision
let visionModel = try? VNCoreMLModel(for: modelCoreML.model)

let classificationRequest = VNCoreMLRequest(model: visionModel) {
  request, error in
  if let observations = request.results as? [VNClassificationObservation] {
   /* do something with the prediction */
  }
}

let handler = VNImageRequestHandler(cgImage: yourImage)
try? handler.perform([classificationRequest])

VNImageReuestHandler가 요청하는 오브젝트의 배열을 받아서, 아래처럼 여러 컴퓨터 비젼 작업을 함께 연결하여 할 수 있음을 인지하자.

try? handler.perform([faceDetectionRequest, classificationRequest])

Vision은 컴퓨터 비젼을 사용하기 아주 쉽게 만들어준다. 그러나 기계학습 사람들에게 멋진 일은 컴퓨터 비젼 작업의 아웃풋을 받아서 Core ML 모델에 넣을 수 있다는 점이다. Core Image의 파워와 합쳐지면 이미지 처리 파이프라인을 하나로 만들게된다!

Metal Performance Shaders

내가 말하고싶은 마지막 주제는 Metal이다. 이것은 애플의 GPU 프로그래밍 API이다.

올해 클라이언트를위한 많은 내 일거리는 Metal Performance Shaders (MPS)로 뉴럴 네트워크 구축과 최적화된 퍼포먼스로 맞추는 작업이 포함되있었다. 그러나 iOS10은 컨볼루션 네트워크를 생성하기위한 기본적인 몇 커널만을 제공했었다. 종종 이 갭을 채우기위해 커스터마이징한 커널을 짜야했다.

그러니 나는 iOS11에서 여러 이용가능한 커널 수가 늘었을때 행복했고, 그 이상의 기분이었다. 이제 그래프를 구축하는(building graphs) API를 가진다.

주의: 왜 Core ML 대신에 MPS를 사용할까? 좋은 질문이다! 가장 큰 이유는 Core ML이 여러분이 원하는 것을 지원하지 않거나, 프로세스 전체를 컨트롤 하고싶고 가능한 최대의 속도를 짜내고 싶을때 사용한다.

MPS에서 기계학습을위한 큰 변화들은 다음과 같다.

Recurrent neural networks. 이제 RNN, LSTM, GRU, MGU 레이어를 생성할 수 있다. 이것들이 MPSImage 오브젝트의 시퀀스에도 동작하고, MPSMatrix 오브젝트 시퀀스에도 동작한다. 이것이 흥미로운 이유는, 다른 모든 MPS 레이어들이 이미지만 다른다는 것이다(그러나 확실히 텍스트나 이미지가아닌 데이터와 작업할때는 매우 불편하다).
더 많은 데이터 타입들. 이전의 가중치는 32비트 부동소수라고 가정했었는데, 이제 16비트 소수, 8비트 정수, 심지어 바이너리까지 될 수 있다. 컨볼루션과 완전히 연결된 레이어들은 바이너리 가중치와 바이너리화된 인풋으로 할 수 있다.
더 많은 레이어들. 지금까지 우리는 plain-pld convolution과 max/average pooling으로 만들어야 했었다. 그러나 iOS11 MPS는 dilated convolution, subpixel convolution, transposed convolution, upsampling과 resampling, L2-norm pooling, dilated max pooling, 게다가 몇몇 새로운 활성 함수들(activation functions)을 가능하게 했다. 아직 MPS는 Keras나 Caffe 레이어 타입처럼 모든 타입을 가지진 않지만, 그 갭은 줄어들고 있다...
더욱 편리함. Metal은 항번에 채널 4개의 분할로 데이터를 구성하는데(이미지가 MTLTextrue 오브젝트에의해 돌아오기 때문에), 그것때문에 MPSImage으로 작업하는것은 항상 좀 이상하다. 그러나 이제 MPSImage는 데이터를 읽고 쓰는 메소드를 가지므로 한결 편해질것이다.또다른 편리함은 레이어에 batch normalization 파라미터를 설정하게 해주는 새로운 메소드를 가지는 것이다. 이 말은 더이상 여러분이 컨볼루션 레이어 가중치에 batch normalization을 접지 않아도 MPS가 알아서 다 해줄것이라는 의미다. 매우 편리하다!

성능 개선. 기존에 있던 커널들이 더 빨라졌다. 이 소식은 항상 좋다.
그래프 API. 내 생각에는 이것이 큰 소식이다. 모든 레이어와 (임시의) 이미지를 직접 생성하는것은 항상 성가신다. 이제 Keras에서처럼 그래프를 표현할 수 있다. MPS는 이미지가 얼마나 커져야하는지, 패딩을 어떻게 다뤄야하는지, MPS 커널의 offset을 어떻게 설정할지 등을 자동으로 계산한다. 뒷편에서는 퓨징 레이어(fusing layers)로 그래프까지도 최적화시킬 수 있다.

이제 모든 커널들이 NSSecureCoding으로 시리얼라이즈 가능해보이는데, 이 의미는 그래프를 파일로 저장하여 나중에 복구시킬 수 있다는 의미이다. 그리고 이 그래프로 인터페이스를 사용하면 이제 그냥 한 메소드 호출만 하면 된다. 아직 Core ML만큼 쉽지는 않지만, MPS 사용이 확실히 이전보다 작업이 많이 줄었다.

내가 생각하기에 아직 분명하지 않은 것은 자신만의 컴퓨트 커널을 작성할 수 있는지, 그래프에 이것을 붙일 수 있는지이다. 내 클라이언트 작업에서 나는 전처리 과정에서 종종 필요했었고, Metal Shading Language로 작성된 커스텀 shader를 필요로 했다. 내가 말할 수 있는 부분은, "MPSNNCustomKerneNode" 클래스가 될것 같진 않다. 더 조사할 필요가 있어보인다!

결론: 기계학습을 위한 Metal Performance Shaders은 iOS 11과함께 더 강력해졌지만, 아마 많은 개발자들이 (내부적으로 MPS를 사용해가며) Core ML와 붙여 사용할 수 있다.

주의: 여러분의 앱이 계속 iOS 10을 지원하지 않는한, 새로나온 그래프 API는 내 Forge library를 쓸모없게 만들었다. 곧 예제 앱을 새로나온 그래프 API로 포팅할 것이고, 그것에대한 세부적인 내용을 블로그에 포스팅할 예정이다.

남은것들

발표된 것 중에 다른 부분이다.

Accelerate: Accelerate 프레임워크에서 BNNS는 기능적 업데이트가 크게 일어나진 않았다. 결국 Softmax 레이어가 나왔지만, MPS가 얻은 새로운 레이어 타입은 없었다. 아마 맞을것이다. 딥 뉴럴 네트워크를위한 CPU 사용은 어쨌든 좋은 아이디어가 아닌것같다. 이 말은, 나는 Accelerate를 사랑하고, 이것으로 많은 즐거움이 있었다. 그리고 이번년도에 나는 스파스 메트릭스를 더 지원했었는데, 꽤 멋졌다.
자연어 처리(Natural Language Processing): Core ML은 이미지만을 위한게 아니라 텍스트를 포함한 수많은 종류의 데이터를 다룰 수 있다. 이 API에는 NSLinguisticTagger 클래스를 사용하는데, 얼마간 사용해봤지만 iOS 11이 나오면서 더욱 효과적게 되었다. 이제 NSLinguisticTagger는 언어 식별, 토큰화, part-of-speech tagging, lemmatization, Named Entity Recognition을 한다.

나는 NLP에 많은 경험이 없으므로 다른 NLP 프레임워크에대해 어떤식으로 stack up 되었는지 말할순 없을것 같지만, NSLinguisticTagger는 보기에 꽤 강력해 보인다. 여러분의 앱에 NLP를 넣고 싶으면 이 API로 시작하기에 좋아보인다.

이 모든게 좋은 소식인가?

애플이 개발자를위해 이 모든 새로운 툴을 제공하는것은 훌륭한 일이지만, 애플의 많은 API에는 중요한 "문제"가 있다.

오픈소스가 아니다
제한을 가진다
새로운 OS가 배포될때만 업데이트를 한다

이 세가지가 함게 있으면 애플의 API는 항상 다른 툴들에비해 뒤떨어질것이다. 만약 Keras가 멋진 새로운 레이어 타입을 추가하면 애플이 그 프레임워크와 OS를 업데이트 하기 전까지 Core ML로는 사용할 수 없을 것이다.

그리고 API의 어떤 부분은 여러분이 원하는대로 동작하지 않을때, 내부로 들어가서 고칠 수 없다. 여러분은 이것으로 작업해야하거나(항상 가능하진 않다) 다음 OS 배포까지 기다려야한다(모든 사용자들이 업그레이드하도록 해야한다).

물론 나는 애플이 비밀 소스를 줄거라 생각하진 않지만, 많은 다른 기계학습 툴킷들이 오픈소스니 Core ML도 오픈소스로 만드는 건 어떨까?

애플이 이것을 아는것은 아마 빠른 시일안에 일어나진 않을 것이지만, 여러분의 앱에 기계학습을 넣기로 했을때는 적어도 위의 내용들을 마음에 담아주자.

더 읽을거리...

YOLO: Core ML versus MPSNNGraph 21 JUN 2017

Google’s MobileNets on the iPhone 14 JUN 2017
iOS 11: Machine Learning for everyone 11 JUN 2017
Real-time object detection with YOLO 20 MAY 2017
Forge: neural network toolkit for Metal 24 APR 2017
Recurrent Neural Networks with Swift and Accelerate 6 APR 2017
Getting started with TensorFlow on iOS 6 MAR 2017
Matrix Multiplication with Metal Performance Shaders 22 FEB 2017
Machine learning on mobile: on the device or in the cloud? 16 FEB 2017
Apple’s deep learning frameworks: BNNS vs. Metal CNN 7 FEB 2017
The lost art of 3D rendering without shaders 18 JAN 2017
Convolutional neural networks on the iPhone with VGGNet 30 AUG 2016
The “hello world” of neural networks 24 AUG 2016
Using types to keep yourself honest 25 MAR 2016
Mixins and traits in Swift 2.0 22 JUL 2015

이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은

블로그 댓글
페이스북 페이지(@나는한다번역)
이메일(canapio.developer@gmail.com)
트위터(@canapio)

으로 보내주시면 됩니다.

[번역]Red, White 그리고 Blue

tucan.dev — Tue, 15 Aug 2017 11:25:57 +0900

제목: Red, White, and Blue

원문: https://medium.springboard.com/a-designers-guide-to-selecting-colors-for-your-product-9944756838d4

모두가 알아야하는 칼라 팔렛트의 8가지 규칙

사람과 컴퓨터간의 인터렉션은 그래픽적인 UI 요소를 기반으로하며, 여기서 칼라는 중요한 역할을 한다. Pierre Bonnard가 이렇게 말했다.

칼라는 디자인에 기쁨의 퀄리티를 더해주는게 아니라 그것을 강조하는 것이다.

새로운 제품을 디자인할때 무한개 종류의 칼라 조합이 나올 수 있으므로, 칼라 스킴의 칼라를 정하는 일은 보통 어렵다. 이 글에선 올바른 칼라 팔렛트를 선택할 수 있도록 8가지 기본 규칙을 다룰 것이다.

1. 칼라의 수를 제한하기

디자인 제품에 칼라를 적용하는 것은 균형과함께 많이 해보아야한다. 많은 칼라를 사용할수록 균형을 맞추기 힘들어진다. 여러분의 칼라 스킴에 최대 3개의 주요 칼라를 담아둔다면, 더 나은 결과물이 나올 것이다. 사람들이 어떻게 Adobe Color CC를 사용하는지 연구한 Toronto대학의 연구에 따르면, 많은 사람들이 두세개의 칼라로 조합한 간단한 칼라 조합을 선호한다고 말했다.

여러분의 팔렛트에 정해놓은 것들을 너머 추가적인 칼라가 필요하게되면, 셰이드(shade)와 틴트(tint)를 이용할 수 있다.

스킴은 어떻게 만들까

그래서 이 두세가지의 칼라는 어떻게 정할까? 칼라 휠(color wheel)이 도와줄 것이다.

이 12가지 칼라 휠은 칼라 스킴을 만드는데 중요한 도구이다

새로운 칼라 스킴을 만들기 쉽게, 미리 정의해둔 칼라 스킴 기준들이 있다(특히 초보자를 위한).

Monochromatic: Monochromatic 스킴은 같은 칼라에서 나오지만, 틴트, 셰이드, 톤으로 조정하기 때문에 스킴을 만들기 가장 쉬운 기준이다. Monochromatic 칼라들은 함께 잘 어울려 부드러운 효과를 만든다.

Monochromatic 스킴은 눈에 굉장히 들어오기 쉽다(특히 blue나 green hues). 페이스북 예시에서도 볼 수 있듯, 이 스킴은 깔끔하고 우아해 보인다

Analogous: Analogous 칼라 스킴은 연관된 칼라들로부터 만들어진다. 한 칼라는 주요 칼라로 사용되고, 다른 칼라들은 스킴을 풍성하게 하는데 사용된다. 이것은 상대적으로 뽑아내기 쉽지만, 전체적인 스킴이 이것에의해 과장될 수 있으므로, 여러분이 사용하는 칼라의 vibrancy를 잘 정하는것이 요령이다. 예를들어 제스처-주도 Todo앱인 Clear는 현재 작업들의 우선순위를 시각화하기위해 강한 인상(striking)의 analogous 칼라를 사용한다. 반면 명상 앱인 Calm는 사용자에게 편안함과 평화로움을 느끼게 하기위해 blue와 green의 analogous 칼라를 사용한다.

12색 칼라 휠에 서로 인접한 세가지 칼라를 사용하여 analogous 스킴을 만들었다. 제스처기반 to-do 앱인 Clear는 현재 테스크들의 우선순위를 표현하기위해 강렬하고 눈에띄는 analogous 칼라를 사용한다

Calm은 전반적인 분위기를 만들기위해 analogous 칼라들을 사용한다

Complementary: 그것들의 기본 양식에서 이 스킴들은 두가지 강하게 반대되는 칼라로만 이루어진다. 이 스킴은 보는이의 시선을 끄는데 사용된다. complementary 스킴을 사용할때는, 주 칼라를 정하는 것이 중요하고, 강조를 위한 보색을 사용한다. 예를들어, 인간의 눈이 다른 종류의 green으로 가득찬 물체를 보고 있을때, 약간의 red는 굉장히 눈에 띌 것이다.

보색은 어떤것을 눈에 띄게 하기 가장 쉬운 방법이다

Custom: 커스텀 칼라 스킴을 만드는 것은 많이들 생각하는것 만큼 복잡하지 않다. 훌륭한 칼라 팔렛트를 만들기위해 적용시킬 수 있는 간단한 요령이 있다. 중립적인 팔렛트(전통적인 monochromatic 스킴)에 밝은 강조의 칼라를 넣으면 된다. 새로 만들어진 스킴은 시각적으로 굉장히 강한 인상이 있을 것이다.

회색톤의 디자인에 한 칼라를 넣으면 간단하고 효과적으로 눈을 끈다. 드롭박스의 칼라 스킴에서, white와 grey의 조합으로 만든 레이아웃은 blue로 강조되어 튀어보인다

2. 자연에서 영감을 받기

최고의 색 조합은 자연에서 온다. 왜냐? 이 스킴들이 눈에 자연스럽게 보이기 때문이다. 영감을 받기 위해, 우리는 주변만 둘러보면 된다. 여러분의 하루 삶에서 특히 아름답거나 강한 인상의 칼라를 본다면 그것으로 스킴을 만들려고 해보아라. 간단하게 아름다운 순간을 사진으로 찍고 이것으로 칼라 스킴을 만들어보자.

최고의 칼라 조합은 자연에서 온다. 사진 한장에서 칼라 스킴을 만들 수 있다

3. 60–30–10 규칙을 따르려 하자

이 규칙은 오랫동안 사용해온 데코레이팅 규칙이다. 이것은 칼라스킴을 함께하기 쉽게 도와준다. 60% + 30% + 10% 비율은 어떤 공간에서 사용되는 칼라의 벨런스를 말한다.

이 개념은 사용하기 아주 쉽다. 60%는 주 색조, 30%는 두번째 칼라, 10%는 강조하는 칼라로 이루어진다. 이 생각은 두번째 칼라가 메인 칼라를 지지하지만, 서로 충분히 다른 부분에 놓는다. 10%는 여러분의 강조하고자하는 칼라이다. CTA나 다른 주목하고 싶은 요소에 이 칼라를 놓을 수 있다.

60%는 주 색조, 30%는 두번째 칼라, 10%는 강조하는 칼라로 이루어진다. 이 기술은 눈을 하나의 초점에서 다른 곳으로 편안하게 이동시킬 수 있게 한다

4. 그레이스케일 먼저 디자인하기

칼라를 가지고 노는것은 즐겁다. 이것이 왜 새로운 제품의 작업을 할 때 칼라 스킴 고르기를 가장 먼저 하는 이유이기도 하다. 이것은 매우 칼라 스킴으로 유혹되는데, 나는 여러분이 그레이스케일 디자인을 먼저 해보도록 하기를 추천한다. 그레이스케일 그라디언트로 여러분의 앱 프로토타입을 먼저 만들고 이것을 기본선으로 사용하자. 칼라를 넣기 전에 그레이스케일로 디자인 하면 여러분을 요소들의 공간과 레이아웃에 집중시킬 수 있다.

칼라를 나중에 넣고, 그 목적으로만 작업하자.

그레이스케일 레이아웃에 한 칼라를 넣으면 간단하고 효과적으로 이목을 끈다

5. 칼라 Black 사용을 피하기

현실 세계에선, 순수한 black은 거의 존재하지 않는다. 우리 주변에 있는 모든 "black" 물체는 대부분 불을 껐을때 그 색이 된다. 이 말은, 그들은 실제 black이 아니고, dark grey이다. 길은 black이 아니다. 그림자도 black이 아니다.

이 개의 칼라는 dark grey이지 black이 아니다

조심스럽게 골랐던 칼라들 옆에 순소한 black을 놓으면, black은 다른 모든것들을 압도해버린다. 이것은 자연스럽지 않기때문에, 눈에 띄게 된다. 우리가 매일 사용하는 많은 앱들은 기본으로 black을 가지지만, 이 black은 실제 black이 아니라 dark grey들이다. 예를들어 Asos 상단 바의 가장 어두운 색은 #000000가 아니라 #242424이다. 그러니 여러분의 칼라에 항상 채도를 조금 넣자.

ASOS에서 가장 어두운 칼라는 black이 아니다

6. 칼라 대비를 이용하여 중요성 만들기

칼라는 눈을 가이드해주는데 도움을 주는 도구이다. 어떤것을 더 두드러지게 만들고 싶으면, 칼라를 더 대비되게 할 수 있다. 일반적으로 높은 대비는 중요한 내용이나 핵심 요소에대한 좋은 선택이다. 사용자가 어떤것을 보거나 클릭하게 하고 싶으면, 눈에띄게 만들어라!

대비는 화면의 남은 부분에비해 다른 영역으로 보이게 만든다. 어떤것을 더 두드러지게 만들고 싶으면, 칼라를 더 대비되게 할 수 있다

7. 사용자의 감정에 영향을주는 칼라를 사용하기

칼라가 고유의 의미를 가지고 감정을 자극할 수 있다는 사실은 이미 잘 알려진 사실이다. 이 의미는 사용자가 여러분의 제품을 지각하는데 직접적인 방법으로 영향을 줄 것이라는 의미이다.

당신이 앱/사이트를 위해 칼라 팔렛트를 선택할때는, 이것들이 어떻게 생겼는지 그냥 생각하지 말고, 이것들이 어떤식으로 느껴지는지도 생각해야한다. 당신이 고른 칼라는 여러분이 만들고자 했던 브렌드 아이덴티티와 잘 맞을수도있고 맞지 않을 수도 있다. 시작해보기위해, (서양의) 각 칼라와 기본적인 연관에대해 빠른 참조 가이드를 모아놓았다.

Red, Orange, Yellow

Red (정렬적인, 강력한, 위험한, 중요한): Red는 극도로 자극적인 칼라이다. 속도나 힘에대한 인상을 남긴다. 에너지의 칼라로 알려져있다. 이것은 혈액순환을 증가시키고 신진대사를 촉진하는 심리적 효과가 증명되어있다. 사람들이 왜 red를 볼 때 강하고 빠른게 읽는지에대한 이유이다. red를 사용하면, 사용자의 주의를 잡거나 주의가 필요한 개별 요소에 강조할 수 있다.
Orange (명량한, 에너지있는, 매력적인, 싼): Orange는 따뜻하고 활기찬 칼라이다. 에너지있는 아우라를 가지며, 사용자에게 따듯하고 환영하는 느낌을 만들어 줄 수 있다. 몇 연구자들은 Orange가 싸다는 느낌을 만드 는 것을 발견했다.
Yellow (쾌활한, 친근한, 자극하는, 시선을 끌고 싶어하는): Yellow는 당신이 정한 셰이드에따라 극도로 다재다능해지는 칼라이다. Light Yellow는 해와 관련 있어서 적극성이나 따뜻함과 소통한다. (gold와 같은) Dark Yellow는 고대나 시대의 인상을 준다. 이 darker 셰이드는 종종 영원이나 현명함에 관련되있다.

Green, Blue, Purple

Green (자연의, 안전의, 신선한): Green은 환경의 의미를 반경하고 자연과 가까운 의미를 가진다. 또한 성장을 나타내고, 이것이 왜 비지니스와 연관되는지의 이유이다. Green은 옳고 그름의 의미도 나타낸다.
Blue (고요한, 책임의, 신뢰할 수 있는, 의존하는): blue 칼라는 고요함과 편안한 감정과 관련되있다. 설득력과 신뢰도에도 관련이 되있고, 믿음과 전문가적인 이해를 준다. Blue는 내부적인 보안의 느낌을 발산한다. 이것이 은행이나 기술 회사가 blue를 사용하는 이유이다. 페이스북, 트위터, 링크드인같은 커다란 소셜 미디어는 모두 그들의 네트워크에 이 칼라를 사용한다.
Purple (럭셔리한, 미스테리한, 로멘틱한, 숭고한): 역사적으로 왕족과 연결되있는 purple는 그 제품이 최고급이라는 느낌을 넌시시 비친다.

Pink, Black, White, Gray

Pink (여성의, 순결의, 어린): Pink는 여성스러움과 관련되있는 것으로 알고있다.
Black (강력한, 세련된, 미스테리의, 뚜렷한): Black은 red를 포함한 다른 칼라들보다 빨리 주의를 끈다. 텍스트나 강조에만 일반적으로 사용되는 이유이다.
White (순수한, 건강한, 깨끗한, 순진한): White는 주변에 있는 다른 칼라들을 강조하고, 두번째 칼라로 인기있다.
Gray (자연적인, 형식적인, 세련된, 무미건조한): Gray는 중립을 나타내고, black이나 white의 성격을 가져갈 수 있다. 주 칼라로 사용될때, 형식적인 인상을 준다.

문화나 환경에따라 칼라의 의미가 다양해질 수 있다는 것이 중요하다. 이 부분에대해 더 많이 알고 싶다면, Symbolism Of Colors And Color Meanings Around The World 글을 확인해보자.

8. 디자인 접근성을 만들기

접근성(Accessibility)는 칼라로 디자인할때 핵심 고려사항이다. 오늘날의 제품들은 (사람의 능력에 상관없이) 모두를위한 접근성이 필요하다.

지시자로 칼라 혼자 사용되는 것을 피하기

약 8%의 남자들과 0.5%의 여자들은 색맥의 어떤 형태의 영향을 받는다. 12명의 남자들중 1명, 200의 여자들중 1명이다. 여러 형태의 조건이 있지만, red와 green 색맹이 가장 일반적이다. 색맹의 형태로 겪고있는 사람은 일반적으로 red와 green의 변색들을 보기 힘들 것이다.

정산적인 시각으로 보이는 칼라와 red-green 칼라 결핍으로 보이는 동일한 칼라(제2색맹과 적녹색맹)

색맹은 (red-green, blue-yellow, moochromatic을 포함하여) 다른 형태를 받아드리므로 여러분의 제품에서 중요한 상태를 소통하기위해 여러 시각적 힌트를 사용하는 것이 중요하다. 칼라를 추가하고, 선, 지시자, 패턴, 텍스쳐, 엑션과 내용을 설명하는 틱스트등을 사용하자.

red 문자를 보지 못하는 사람들에게 극도로 답답한 경험을 줄 수 있으므로, red나 green 칼라만 사용한 정보전달은 피하라

텍스트에 낮은 대조는 피하라

칼라 대조는 디자인의 사용성에대해 칼라 이론이 중요하게 생각하는 한 분야이다. 텍스트에 칼라를 사용하고 있으면, 두 칼라가 서로 낮은 값 대비(low value contrast)로 옆에 놓이면 여러분의 카피는 굉장히 읽기 힘들어진다는 것을 알고 있어야한다.

낮은 대비의 텍스트는 잠재적으로 많은 앱들의 사용성을 망가뜨릴 수 있다

백그라운드와 포그라운드의 칼라가 색맹의 사람들과 시력이 낮은 사람들에게 충분히 대조되는지 검증하자. 그렇게 어려운 일이 아니다. 명암비(contrast ratio)를 확인하면 끝이다. 명암비는 한 칼라가 또다른 칼라와 얼마나 다른지 표현한다(일반적으로 1:1 혹은 21:1 이런식으로 쓴다). 비율에서 두 숫자의 차가 높을수록 두 칼라 사이에 상대적 휘도(luminance) 차이가 크다는 것이다. W3C는 바디 텍스트와 이미지 텍스트에대해 아래 명암비를 추천한다.

작은 텍스트는 백그라운드에대해 적어도 4.5:1의 명암비를 가져야한다.
큰 텍스트(14pt 볼드/18pt 기본 보다 큰)는 백그라운드에대해 적어도 3:1의 명암비를 가져져야한다.

좋은 소식은, 이것을 직접 확인하지 않아도 된다는 점이다. Color Contrast Checker 도구를 사용하여 그냥 몇번의 클릭으로 칼라 조합을 확인할 수 있다.

Webaim 칼라 대조 체커

보너스: UX 디자이너를 위한 필수 도구들

쉽게 일하기 위해 칼라 팔렛트를 고르는데 최고의 도구들을 알려주겠다.

Adobe Color CC

Adobe Color CC(이전에는 Kuler로 알려졌다)는 칼라 스킴을 찾고, 수정하고, 만드는데 훌륭한 도구이다. 팔렛트에 있는 모든 칼라는 몇번의 클릭으로 개별적으로 수정하거나, 기본 칼라로 정할 수 있다. 팔렛트를 저장하고 라이브러리에 넣을 수도 있고, 이 사이트의 커뮤니티에서 만든 여러 훌륭한 칼라 스킴들이 있다.

Adobe Color CC는 다양한 칼라 스킴 선택을 빠르게 탐험해볼 수 있는 멋진 도구이다

Dribbble Search-by-color

다른 디자이너가 사용한 특정 칼라에대해 비주얼 조사를 하고 싶으면, dribbble.com/colors로 가서 필요한 칼라를 선택하자.

shot에 포함된 칼라의 최소 퍼센트를 지정할 수도 있다(이 shot은 30% blue이다)

shot에 포함된 칼라의 최소 퍼센트를 지정하기

Material Design

메트리얼 디자인 가이드라인은 일러스트레이션에 사용되거나 브랜드 칼라를 개발하는데 사용될 수 있는 굉장한 칼라 팔렛트를 제공한다. 이 팔렛트의 모든 칼라들은 서로 조화롭게 동작한다.

Colorzilla

Colorzilla는 구글 크롬과 모질라 파이어폭스에서 가능한 익스텐셔이다. 여기에는 color picker, eye-dropper, CSS gradient generator, palette browser을 포함하여 칼라 관련 것들을 담고있다.

Coolors.co

Coolors는 다중칼라의 스킴을 만드는데 강력한 도구이다. 선택된 칼라를 잠그고, 새로운 팔렛트를 생성하기위해 스페이스바를 누르면 된다. 이 도구의 멋진 점은 한 결과만 나오도록 제한하지 않았다는 점이다. 참조 포인트를 수정ㅎ여 간단하게 몇개의 칼라 스킴을 얻어낼 수가 있다.

내가 칼라 스킴을 만드는 개인적인 방법으로는 사진을 이용하는 것이다. 이 도구는 이미지를 업로드하여 그것으로부터 칼라 팔렛트를 만들어준다.

Coolors는 이미지를 업로드하여 그것으로부터 칼라 팔렛트를 만들어준다

Color Blindness Simulation in Adobe Photoshop

포토샵으로 당신의 디자인의 접근성 테스트를 할 수 있다. 그냥 View > Proof Setup으로 가서, 적녹색맹과 제2색맹(Protanopia-type이나 Deuteranopia-type), 두 타입중에 선택할 수 있다.

NoCoffee Vision Simulator for Chrome

디자인의 접근성 이슈를 막기위해, 디자인하는동안 스스로 색맹의 경험을 해보는 것도 좋은 방법이다. NoCoffee Vision Simulator는 어느 페이지에서도 칼라-시력 결핍이나 낮은-시력 조건으로 시뮬레이팅할 수 있게 해준다. 예를들어 "Color Deficiency"를 사용하여 "Deuteranopia"를 설정하면 웹페이지가 흑백으로 보인다. 이것이 시각적인 저하의 사용자에게 당신의 디자인 접근성을 만드는데 도움을 줄 것이다.

칼라는 디자이너의 툴킷 중에 가장 강력한 도구 중 하나이다. 그러나 동시에 통달하기에 까다로운 도구이기도 하다. 위에서 말한 규칙들이 새로운 디자이너들에게 좋은 토대가 되길 바란다. 이제 실전으로 가볼 시간이다. 칼라 스킴에서 훌륭해지는 최고의 방법은 실제로 만들어 보는 것이기 때문이다.

이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은

블로그 댓글
페이스북 페이지(@나는한다번역)
이메일(canapio.developer@gmail.com)
트위터(@canapio)

으로 보내주시면 됩니다.

[번역]인스트루먼트없이 누수 뷰컨트롤러 잡아내기

tucan.dev — Tue, 15 Aug 2017 10:23:44 +0900

제목: Catching Leaky View Controllers Without Instruments

원문: http://holko.pl/2017/06/26/checking-uiviewcontroller-deallocation/

레테인 사이클(retain cycles)에의해 생긴 메모리 누수를 찾아내는 방법 중 잘 알려진 방법은, 더이상 화면에 있지 않을때 모든 뷰컨트롤러들이 디얼록되었는지 확인하는 것이다. 이 과정은 각각이 할당해제되기 전에 직접 반복해서 시행해보아야하는데, 재밌지도 않을 뿐더러 여기서 에러를 만들어내기도 한다. 만약 좀 더 일찍 UIViewController 누수에대한

과정을 알 수 있었다면, 매일 개발하는동안 훨씬 낫지 않겠는가?

UIViewController의 잘 알려지지 않은 두개 프로퍼티에대해 감사하게 될 수도 있다.

isBeingDismissed: 모달로 나타난 뷰컨트롤러가 dismiss될 때, 이 프로퍼티는 true이다.
isMovingFromParentViewController: 부모 뷰컨트롤러로부터 이 뷰컨트롤러가 제거될 때, true가 된다. 이것은 UINavigationController 스택에서 뷰컨트롤러가 pop될 때와 같은, 시스템 컨테이너에서 제거되는 것도 포함된다.

이 프로퍼티 중 하나가 true면, 곧 뷰컨트롤러가 디얼록될 수 있다는 것을 알 수 있다. 정확히 얼마나 있어야 내부적으로 정리된 상태를 만들고 ARC가 디얼록할지는 모른다. 간단하게 생각해서 2초보다 더 길지는 않을 것이라 가정하자.

우리가 생각한 것을 코드로 만들어보자.

extension UIViewController {
   public func dch_checkDeallocation(afterDelay delay: TimeInterval = 2.0) {
       let rootParentViewController = dch_rootParentViewController

       // We don’t check isBeingDismissed simply on this view controller because it’s common

       // to wrap a view controller in another view controller (e.g. in UINavigationController)

       // and present the wrapping view controller instead.

       if isMovingFromParentViewController || rootParentViewController.isBeingDismissed {
           let type = type(of: self)
           let disappearanceSource: String = isMovingFromParentViewController ? "removed from its parent" : "dismissed"

           DispatchQueue.main.asyncAfter(deadline: .now() + delay, execute: { [weak self] in

               assert(self == nil, "\(type) not deallocated after being \(disappearanceSource)")
           })
       }
   }

   private var dch_rootParentViewController: UIViewController {
       var root = self

       while let parent = root.parent {
           root = parent
       }

       return root
   }
}

흥미로운 부분은 asyncAfter(deadline:execute:) 호출에서 일어난다. 먼저 sefl를 weak로 만들면([weak self]), 나중에 호출할 클로저에의해 리테인되지 않는다. 그리고 self가 nil이면 assert를 건다(여기서 self는 UIViewController). 뷰컨트롤러가 살아있게 잡아두는 리테인 사이클을 가질때만 nil이 아니다.

이제 마지막으로 해야할 일은 모든 뷰컨트롤러의 viewDidDisappear(_:)에서 dch_checkDeallocation()을 호출하는 것이다(부모로부터 제거되거나 dismiss된 후에도 살아있도록 잡아두는 것을 제외하고)

override func viewDidDisappear(_ animated: Bool) {
   super.viewDidDisappear(animated)

   dch_checkDeallocation()
}

만약 누수가 일어나고 있으면, assert에서 실패나 나올 것이다(-Onone 빌드에서만 가능).

여기서 우리는 그냥 메모리 그래프 디버거(Memory Graph Debugger)를 열어 사이클의 원인을 찾고 고치면 된다.

이 방법을 통해 새로 소개된 리테인 사이클을 빠르게 배우는데 도움이 될거라 생각한다. 여러분도 이 방법이 즐거웠길 바란다! production-ready 코드(더 많은 주석과 if DEBUG 확인으로)는 GitHub의 DeallocationChecker에서 확인해볼 수 있다.

이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은

블로그 댓글
페이스북 페이지(@나는한다번역)
이메일(canapio.developer@gmail.com)
트위터(@canapio)

으로 보내주시면 됩니다.

tucan9389's blog

iOS에서 엑셀파일 만들기(feat. libxlsxwriter)

목차

libxlsxwriter 소개

Swift 프로젝트에서 c라이브러리 pod 세팅하기

Podfile 만들기

pod 설치

excel-example-Bridging-Header.h 만들어서 설정

C 라이브러리 불러올 수 있게 Pod 경로 설정

libxlsxwriter 사용법

excel-example-Bridging-Header.h에서 xlsxwriter.h 불러오기

저장할 경로 정하기

초기 설정

초기 설정

셀 생성

셀 합치기

파일 닫기

전체코드

위 코드로 만들어진 엑셀파일

마치며

코드 분할

Excel 포멧의 한계

참고

[번역] TOCO: 텐서플로우 라이트 최적화 컨버터

문서 사용법

컨버터는 Tensorflow에서 어느 부분에 해당될까요

[번역] 약간의 iOS 개발 팁

1. Xcode에서 빌드시간 확인하기

2. Swift 프로젝트 빌드시간 단축시키기

3. Xcode에서 전체화면 모드로 시뮬레이터 사용하기

4. iOS 시뮬레이터 화면 녹화하기

5. 파인더에서 시뮬레이터에 파일 공유하기

6. sudo 인증시 지문 사용하기

7. 소리 알림과 함께 AutoLayout 컨스트레인트 디버깅하기

8. Xcode에서 사용할 수 없는 시뮬레이터 제거하기

[번역] iOS Dev Weekly - 351 (서문)

[번역]앱에 Core ML 모델 합치기

SDKs

Framework

On This Page

개요

여러분의 Xcode 프로젝트에 모델 넣기

코드에서 모델 생성하기

모델에 넣을 입력값 가져오기

예측을위해 모델 사용하기

주의

Core ML 앱을 빌드하고 실행하기

함께 보기

첫번째 단계

iOS 기기에서 Tensorflow 모델 실행시키는 방법들

1. Tensorflow mobile for iOS(Deprecated)

2. Tensorflow Lite

3. Core ML

4. MLKit with Firebase

+. tensorflow + swift

[번역]우리가 WeWork 인터뷰에서 사용하고 있는 제품 디자인 예제들

[번역]iOS11: 모두를 위한 기계학습

[번역]Red, White 그리고 Blue

[번역]인스트루먼트없이 누수 뷰컨트롤러 잡아내기

`excel-example-Bridging-Header.h`에서 `xlsxwriter.h` 불러오기