IT Reading

[itreading]

프로그래밍 이렇게 공부해보자

1. Cpp Quiz

주소 : http://cppquiz.org

난이도 : 조금 어려움

c++ 퀴즈를 푸는 사이트이다.

기본적으로 3가지 오류와 더불어 출력이 존재 할 경우 직접 값을 입력한다.

기괴한 문제를 많이 만날 수 있다. 더불어, 몰랐던 컴파일러 규칙들을 많이 만날 수 있다. 학교에서 굳이 애써서 만드는 중간, 기말류 일 수도 있지만, 평소 잘 모르고(굳이 알려고 하지 않고) 지나쳤던 중요한 포인트를 만날 수 있다. 만약, 시험문제가 이정도면 대박일듯!

2. Codecademy

주소 : http://www.codecademy.com

난이도 : 누구나

웹 기반 많이 사용되는 언어를 가이드를 따라하면서 배울 수 있는 사이트이다. HTML&CSS, jQuery, js, php, python, ruby 과정이 준비되어 있으며, 난이도는 누구나 쉽게 따라 할 수 있는 기초 언어 수준이다. 웹에서 바로 설명을 보고 받아쓰기 하듯 쉽게 할 수 있고, submit을 통해 즉각적으로 결과를 볼 수 있어서 좋다. 초보자가 이것 설치하고 저것 설정할 필요없이 즉각적으로 해보고 바로 결과를 볼 수 있다는 점에서 좋다.

3. Ruby warrior

주소 : https://www.bloc.io/ruby-warrior#/

난이도 : 누구나

프로그래밍 언어 루비를 게임 하듯이 배울 수 있는 사이트이다. 초창기 환상적인 인터랙션 방식의 학습으로 넷 상에서 이슈되었다. 접속을 하면 bgm부터 게임을 킨 듯한 느낌을 준다. 루비를 이용해 워리어가 미션을 수행하도록 하면서 배운다. 쉽고 재밌고 다른 사이트보다 쉽게 질리지 않는다.

4. Code

주소 : http://learn.code.org/

게이츠형이 게임만드는 인강을 찍어서 유명해진 곳. 미국에서 it 리더들이 프로그래밍이 필수 교과로 선정되어야 한다는 취지로 시작된 사이트이다. 10대 학생들의 눈높이에 맞추어 제작되어, 눈에 잘 보이는 프로그래밍 예시를 위주로 되어있다. 익숙한 식좀, 앵그리버드등을 예제로 하여 프로그래밍 강좌를 꾸려 초창기 이슈가 되었다. 누구나 아는 구글, 마이크로 소프트, 페이스북, 트위터, 로비오, ea가 이 프로젝트에 참여했다.

웹 상에 리소스가 넘쳐나고 있다. 정확히는 이전에도 웹상에 자료는 많았지만, 컨텐츠를 작성하는 사람 기준으로 컨텐츠가 정렬되었다. 현재는 리소스가 폭발적으로 늘어났으며, 컨텐츠 이용자 눈높이로 재정렬 되고 있다. 취향에 맞춰서 이용하면 될 것 같다.

[itreading]

타이젠(Tizen) 개발자 사이트와 SDK

최근 삼성전자의 TIZEN OS가 이슈가 되고 있다.

이 OS의 전략이나 성공 여부는 이곳에서 논할 사항은 아니니 제외하고 개발 블로그인 만큼 개발자 사이트와 SDK에 대해 살펴보려 한다.

많은 사람들에게 알려지지 않았지만, 사실 타이젠은 아래와 같은 개발자 사이트가 운영되고 있으며 해당 사이트에서 SDK도 이미 배포되고 있다. https://developer.tizen.org/

다만, 아직은 제대로 활성화 된 OS가 아니기 때문에 UX같은 부분은 아직까지 불편한 부분이 존재했다.

SDK

SDK는 이곳 에서 다운받을 수 있다. 운영체제별로 따로 설치 할 수 있는 설치파일을 제공한다. 심지어는 Mac OS도 제공을 한다.

설치하는 방법은 두가지가 있다. 설치 관리자를(약 4메가) 설치한 뒤에 실행 하면 나오는 화면에서,

이미지를 인터넷을 통해 다운 받던가,

개발자 사이트에서 이미지 바이너리(약 1.5기가 이상)을 받아서 설치관리자에서 Advanced를 눌러서 해당 이미지로 설치하는 방법 이 있다.

참고로 2번 방법이 훨씬 빠르기에 이 방법을 추천한다.

타이젠 SDK는 이클립스 기반으로 이루어져 있어서 많은 사람들이 익숙하게 느껴질 것이다.

API

타이젠으로 앱을 개발할 때는 아래와 같이 크게 2가지 방법이 있다.

Web App (HTML + JavaScript)

Native App (C++)

그래서 개발자 사이트에 문서를 보면 Web App 을 위한 API와 Native App을 위한 API가 따로 카테고리로 분류되어 있다.하지만 두 종류 모두 기능 적인 부분에서는 크게 다르지 않기 때문에 조금 더 선호하는 쪽으로 선택하면 될 것 같다. Web App API로도 디바이스의 센서와 같은 부분에도 접근 할 수 있도록 열려 있기 때문이다.

Sample Application

타이젠 개발자 사이트에서는 특이한 점을 하나 발견할 수 있다. 일반적인 개발자 사이트에서 제공하는 샘플 어플리케이션은 API를 활용하는 수준의 샘플을 제공한다. 타이젠도 역시 API 페이지에는 그러한 수준의 샘플 어플리케이션을 제공하는데, 추가적으로 제품화 될 수 있을 만한 수준의 샘플을 제공하고 있다는 점이 특이하다.

샘플사이트 [제공 하는 샘플 목록 일부]

이렇게 제공하는 샘플은 모두 웹 앱으로 만들어 진 것이며, 종류는 게임 부터 다양한 종류의 어플리케이션을 제공한다.(현재 총 16개의 샘플을 제공하고 있다.) 이 앱들을 통해 하나의 프로젝트를 구성하는 방법 부터 다양한 노하우 역시 알아 볼 수 있기 때문에 이 부분은 굉장히 칭찬해 주고 싶은 부분이다.

총평

타이젠 개발자 사이트를 둘러본 소감은,

"준비는 많이 되었지만, 아직 베타 수준" 인 느낌이 많이 들었다. 특히나 메뉴 구성이나 메뉴 네비게이션 부분이 굉장히 메뉴를 찾기 어려웠고, 구성도 깔끔하지 않은 느낌이었다. 예를 들면, Web API 레퍼런스를 보기 위해서는 수많은 클릭이 필요하고 심지어 아주 작은 삼각형을 클릭해야지만 서브 카테고리를 볼 수 있었다. 이러한 부분들은 아주 사소한 것이지만 최신 OS라는 이미지를 깎아 내릴 수 있는 부분 이기도 하다. 앞으로 발전될 여지가 아주 많기 때문에 이러한 느낌을 지울 수 있는 업데이트가 되는 날을 기다려 본다.

[itreading]

괜찮은 소프트웨어 디자인

original link: http://www.thingstocode.com/2014/03/good-enough-software-design/

disclaimer: 매끄러운 전달을 위해 일부 의역 및 첨언이 있습니다.

소프트웨어 개발에서 디자인은 매우 고된 작업입니다. 완벽을 추구하는 개발자들에겐 더더욱 그렇죠. 디자인 과정에서 개발자는 수많은 변수들을 고려하며 최적의 솔루션을 찾기위해 고민합니다. 대부분의 경우 디자인 결정은 쉽지 않습니다. 올바른 결정을 하기위해 지인을 찾거나 stackoverflow.com을 뒤지곤 하죠. 하지만 들인 시간과 노력에 비해 우리는 종종 우리가 찾은(혹은 새롭게 개발한) 디자인에 만족하지 못합니다. 과연 이게 최선일까? 이게 완벽한 디자인일까? 끊임없이 되묻게 되죠. 그런데 문제는 말입니다, 완벽한 디자인은 존재하지 않다는 겁니다.

고민의 탑

소프트웨어 디자인이라는 퍼즐을 풀기위해 우리는 많은 고민을 합니다. 대부분의 고민은 소프트웨어 요구사항을 만족하기 위해 어떤 방법을 선택해야 하는지에 초점이 맞추어져 있죠. 그런데 그 고민들을 자세히 들여다보면 대충 이렇습니다: MVC를 쓸까? 아니면 MVVM을 쓸까? 주어진 데이터모델에 ORM이 필요할까? ORM은 어떤걸 선택해야하지? 데이터베이스 동시성 문제는? 고민은 꼬리에 꼬리를 물며 점점 쌓여만 갑니다. 찾으려고 하는 소프트웨어 디자인은 이미 고민의 탑에 가리어 보이지 않죠.

소프트웨어 디자인의 기본은 큰 문제를 작고 쉬운 조각으로 나누어 단순한 해법으로 문제를 해결해 나가는 것입니다. 요구사항 단위로 혹은 세부기능단위로 나누어 하나하나 해결하다보면 어지럽게 흩어져있던 퍼즐이 하나하나 맞추어지는 것을 볼 수 있습니다. 큰 프로젝트일수록 고민의 탑을 쌓아올리기보다는 작은 문제를 하나씩 해결하며 반복적인 과정을 통해 요구사항이 내재하고 있는 문제점을 찾아 빠르게 해결하는 것이 좋은 개발방법이라고 생각됩니다.

또한 디자인 과정에서는 개발도구나 라이브러리로 고민하는 시간을 줄이고 소프트웨어 구조나 흐름, 무결성에 더 초점을 맞추는 것이 좋습니다. 어떤 데이터베이스를 쓰느냐보다는 디자인패턴을 통해 종속성을 없애거나 SoC(Separation of Concern)를 적용하여 계층간 분리를 디자인하여 유연성을 확보하는 것이 더 좋은 디자인이라고 생각합니다.

좋은 디자인을 위해 고민하는 건 좋은 것입니다. 하지만 언제나 그렇듯 적당히가 중요한것 같습니다. 고민의 굴레에 빠져 코드 한줄 못쓰고 디자인만 한다면 프로젝트는 끝나지 않을테니까요. Steve McConnel은 그의 저서 Code Complete에서 이렇게 말했습니다.

디자인은 언제 끝나는가? 디자인은 끝이 정해져있는 것이 아니기 때문에 보통의 경우 이 질문의 답은 "더 이상 시간이 없을때"이다.

요구사항에 대처하는 자세

요구사항이 변경되지 않는 프로젝트가 존재하기는 할까요? 하루가 다르게 변화하는 시장에서 살아남기 위해 프로젝트를 발주한 고객사도 스타트업을 준비하는 벤쳐기업도 변화에 적응하기 위해 모든 힘을 다합니다. 그리고 그렇게 요구사항도 변합니다. 끊임없이 변화하는 문제들 앞에 완벽한 요구사항은 존재하지 않습니다. 때로는 사라지기도 하고 없던 요구사항이 갑자기 나타기도 합니다.

요구사항에 대처하는 가장 올바른 자세는 요구사항은 변경될 수 있다라는 사실을 인지하고 지금 현재 꼭 필요한 것들만 정리하는 것입니다. "지금은 필요없지만 나중에 필요할거야'라는 의도로 만들어진 요구사항은 개발기간을 잡아먹을 뿐만 아니라 '나중에' 사용되지 않을 가능성이 높습니다.

필요한 기술

개발자들이 흔히 하는 실수가 바로 필요한 것보다 더 많은 기술을 집어넣는 것입니다. 우리 모두가 시간앞에서 평등하듯 개발자에게도 하루 24시간이 주어집니다. 4시간 걸려 만들 수 있는 간단한 프로그램이 요구사항을 만족한다면 굳이 48시간을 들여 크고 아름다운 프로그램을 만들 필요는 없다고 생각합니다. 개발자 개인의 만족을 위해 그렇게 할수 있을지 모르겠으나 시간대비 효율을 생각한다면 소프트웨어 디자인 과정에서 적절한 목표를 제시하고 그 목표를 충족시키는 것이 좋다고 생각합니다.

자신감을 갖자

소프트웨어 디자인은 전적으로 개발자의 경험에서 나옵니다. 서로 다른 개발자들이 다른 소프트웨어 디자인을 주장하는 것은 매우 당연한 일입니다. 이 때문에 한가지 문제를 놓고 여러 디자인을 비교하며 최선의 결과를 얻기위해 노력합니다. 하지만 디자인보다 더 중요한 것이 신속한 개발입니다. 여러 디자인을 놓고 비교하고 새로운 기술을 배우는 것도 중요하지만 프로젝트를 기간 내에 완수해야하는 개발자의 입장이라면 자신감을 갖고 본인의 경험이 찾은 최선의 디자인을 구현하는 것이 중요합니다.

물론 디자인에 문제가 있을 수 있습니다. 특정 클래스에 필요이상으로 의존도가 높아질 수도 있고, 잘못된 상속관계로 인해 골치가 아프거나 너무나도 당연한 디자인 패턴을 적용하지 못하고 지나칠 수도 있습니다. 이런 문제들은 충분히 발생할 수 있는 것들입니다. 이런 문제들을 해결하기 위해 리팩토링을 합니다. 완벽한 디자인이란 존재하지 않기 때문에 우리는 주기적인 리팩토링을 통해 '괜찮은' 소프트웨어를 만들 수 있다고 생각합니다.

완벽한 소프트웨어는 없다

사실 개발자가 본인이 만든 소프트웨어에 100% 만족하는 경우는 드뭅니다. 이건 비단 우리들만의 문제는 아닌듯 합니다. The Pragmatic Programmer의 저자 Andrew Hunt와 David Thomas는 이렇게 말합니다.

...완벽한 소프트웨어는 존재하지 않는다. 컴퓨팅이 시작된 이래로 그 누구도 완벽한 소프트웨어의 조각조차 만들지 못했다. 이 책을 읽고 있는 당신또한 다르지 않다. 이 사실을 받아들이지 못한다면 당신은 불가능한 꿈을 위해 시간과 힘을 낭비할 뿐이다.

애석하게도 틀린 말 같지 않습니다. 하지만 여러분은 괜찮은 소프트웨어를 만들 수 있는 방법을 알고 있으니 열심히 코딩하시기 바랍니다!

[itreading]

안드로이드에서 XML 데이터 객체로 바꾸기 - XmlPullParser

안드로이드에서 XML을 객체로 바꾸는 방법은 여러가지가 있습니다. 자바에서 제공하는 대부분의 라이브러리를 사용할 수 있는 안드로이드는 SAX, DOM 등을 사용하여 비교적 쉽게 XML을 객체로 변환할 수 있습니다. JAXB를 사용하여 seamless한 marshalling을 수행할 수 있으면 좋겠으나 안드로이드에서 직접 지원하지 않을뿐더러 모바일 환경에서 사용하기엔 조금 무거운 탓에 이상적인 구현이 아닙니다.

안드로이드 플랫폼이 추천하는 방법은 XmlPullParser를 사용하여 Xml을 객체로 변환하는 것입니다. 안드로이드 개발자 페이지와 IBM Developer Works에 비교적 간단하게 XML변환을 구현하는 방법이 있어 살짝 옮겨봤습니다.

다음과 같은 XML을 객체 리스트로 변환해 보겠습니다.

<?xml version="1.0" encoding="UTF-8"?> <rss version="2.0"> <channel> <title>android_news</title> <description>android_news</description> <link>http://www.androidster.com/android_news.php</link> <lastBuildDate>Sun, 19 Apr 2009 19:43:45 +0100</lastBuildDate> <generator>FeedCreator 1.7.2</generator> <item> <title>Samsung S8000 to Run Android, Play DivX</title> <link>http://www.androidster.com/android_news/samsung-s8000</link> <description>More details have emerged on the first Samsung...</description> <pubDate>Thu, 16 Apr 2009 07:18:51 +0100</pubDate> </item> <item> <title>Android Cupcake Update on the Horizon</title> <link>http://www.androidster.com/android_news/android-cupcake</link> <description>After months of discovery and hearsay, the ...</description> <pubDate>Tue, 14 Apr 2009 04:13:21 +0100</pubDate> </item> </channel> </rss>

위 XML의 item을 표현하는 Message 클래스를 만듭니다.

import java.net.MalformedURLException; import java.net.URL; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date; public class Message { private String title; private URL link; private String description; private Date date; // Message 클래스에 필요한 메소드를 추가합니다. }

XML을 읽어 List<Message> 형태로 객체 리스트를 반환하는 메소드를 가진 인터페이스를 선언합니다.

import java.util.List; public interface FeedParser { List<Message> parse(); }

XML 정보를 특정 url에서 읽어오는 것을 가정하고 다음과 같은 클래스를 만듭니다. 이 클래스를 상속받아 SAX, DOM, XmlPullParser등 을 사용하여 XML을 변환할 수 있게 준비합니다.

import java.io.IOException; import java.io.InputStream; import java.net.MalformedURLException; import java.net.URL; public abstract class BaseFeedParser implements FeedParser { // 읽어들일 XML 태그를 선언합니다. static final String PUB_DATE = "pubDate"; static final String DESCRIPTION = "description"; static final String LINK = "link"; static final String TITLE = "title"; static final String ITEM = "item"; static final String CHANNEL = "channel"; final URL feedUrl; protected BaseFeedParser(String feedUrl){ try { this.feedUrl = new URL(feedUrl); } catch (MalformedURLException e) { throw new RuntimeException(e); } } protected InputStream getInputStream() { try { return feedUrl.openConnection().getInputStream(); } catch (IOException e) { throw new RuntimeException(e); } } }

XmlPullParser는 InputStream을 받아 순차적으로 정보를 쌓아 객체를 만듭니다.

import android.util.Xml; import org.xmlpull.v1.XmlPullParser; import java.util.ArrayList; import java.util.List; public class XmlPullFeedParser extends BaseFeedParser { public XmlPullFeedParser(String feedUrl) { super(feedUrl); } @Override public List<Message> parse() { List<Message> messages = null; XmlPullParser parser = Xml.newPullParser(); try { // 스트림에서 인코딩을 자동으로 인식합니다. parser.setInput(this.getInputStream(), null); int eventType = parser.getEventType(); Message currentMessage = null; boolean done = false; while (eventType != XmlPullParser.END_DOCUMENT && !done){ String name = null; switch (eventType){ case XmlPullParser.START_DOCUMENT: // 스트림의 시작입니다. 리스트를 생성합니다. messages = new ArrayList<Message>(); break; case XmlPullParser.START_TAG: // 태그를 식별한 뒤 태그에 맞는 작업을 수행합니다. name = parser.getName(); if (name.equalsIgnoreCase(ITEM)){ currentMessage = new Message(); } else if (currentMessage != null){ if (name.equalsIgnoreCase(LINK)){ // XmlPullParser#nextText()는 String을 리턴하므로 Message 클래스에 // setLink(String)을 만들어 URL 객체를 생성할 수 있게 합니다. currentMessage.setLink(parser.nextText()); } else if (name.equalsIgnoreCase(DESCRIPTION)){ currentMessage.setDescription(parser.nextText()); } else if (name.equalsIgnoreCase(PUB_DATE)){ // XmlPullParser#nextText()는 String을 리턴하므로 Message 클래스에 // setDate(String)을 만들어 Date 객체를 생성할 수 있게 합니다. currentMessage.setDate(parser.nextText()); } else if (name.equalsIgnoreCase(TITLE)){ currentMessage.setTitle(parser.nextText()); } } break; case XmlPullParser.END_TAG: // 태그의 마지막을 읽었습니다. ITEM을 처리하는 중이면 리스트에 Message를 추가합니다. name = parser.getName(); if (name.equalsIgnoreCase(ITEM) && currentMessage != null){ messages.add(currentMessage); } else if (name.equalsIgnoreCase(CHANNEL)){ done = true; } break; } eventType = parser.next(); } } catch (Exception e) { throw new RuntimeException(e); } return messages; } }

이제 XML을 url로 읽어들일 준비가 되었습니다. 이렇게 만들어진 XmlPullFeedParser를 사용하는 방법은 다음과 같습니다.

XmlPullFeedParser parser = new XmlPullFeedParser("http://www.example.com/api/xml/100"); List<Message> messages = parser.parse();

[itreading]

여우비 엔진 살펴보기

'국산 인디 게임 툴'이 등장 했다.

한 문장이지만 굉장히 기대되고 자극적인(?) 문구가 아닌가?

국회에서 연일 게임을 마약취급하는 세태 속에서 이러한 희망찬 소식이 전해지니 더욱 반갑다.

해당기사 -http://finance.daum.net/rich/news/finance/photo/MD20140228100711944.daum

그래서 여우비 엔진은 어떤지 바로 탐방을 갔다.

기사화 된 것 치고는 매우 정보가 적다. 우선 여우비로 검색하면 여우비 엔진은 기사 이외에 정보가 없다. RPG 만들기 까페들에서 우선적으로 검색해서 여우비 엔진 본진을 찾았다.

우선 카페 글을 통해 얻을 수 있는 것은 '개발 중'이다.

http://cafe.naver.com/yeoubiproject.cafe

현재는 'yeoubi client betablue 103'를 통해 테스트중이고 개발 소식을 통해 프로젝트 진행 소식을 얻을 수 있다. 개발 소식은 생각보다 상세하다. 리소스들 폰트, 이미지, 사운드등을 어떤식으로 다루고 구현하고 있는지 대략적으로 알 수 있으며, 현재 에디터도 베타 수준으로 만들어 진것 같지만 공개되진 않았다. 에디터를 보면 고무적인 것은 루비 스크립트를 사용하며 에디터에서 인텔리전스, 프로젝트 관리까지 통합적으로 지원한다는게 놀라울 뿐이다. 다만, 게임쪽에서 좀 더 친숙한 루아가 아닌 루비를 선택한 점은 궁금하다.

아직은 여우비 엔진만 만날 수 있다. 다른 공개된 정보로 추측했을 때, 에디터, 스크립트, 맵에디터, 타일 편집기, 미디, 크로스 플랫폼등 확실히 짜임새 있는 구성으로 개발되고 있다. 짜임새 만큼이나 좋은 퀄리티로 공개 되는 날을 기대해 본다.

[itreading]

NIKE+ 개발자용 API 소개 (Developer.nike.com)

아는분들도 있겠지만, 많은 분들은 제목만 봐서는 무척 헷갈릴 수 있을 것이다. 나이키 API는 무엇인가? 진짜 스포츠 브랜드 NIKE인가 아니면 그냥 이름만 NIKE 인가?

결론부터 말하자면 여러분이 생각하는 그 스포츠 브랜드가 맞다.

나이키는 오래 전 부터 애플과 협업하면 NIKE+ 라는 피트니스 서비스를 해왔으며 최근에는 Fuel Band 라는 웨어러블 디바이스 까지 내놓았다. 그런 디바이스들에서 모이는 데이터를 활용할 수 있도록 나이키에서는 개발자사이트를 운영하고 있기에 이번 포스팅에서는 이것을 소개하려고 한다.

1.회원가입

나이키 개발자 사이트 에 들어가면 따로 회원가입을 하는 링크가 존재하지 않는다. 나이키 개발자 사이트는 나이키 플러스와 계정을 공유하기 때문에 나이키 플러스 사이트에서 회원가입을 해야한다.

2. API 구조

NIKE+를 활용하면 다양한 피트니스 데이터를 쌓을 수 있게 되는데, NIKE+ API를 사용하면 이런 데이터를 사용할 수 있게 되는 방식이다.

모든 방식은 RESTful 로 되어 있고, GET으로 인증정보인 Access_Token 을 포함해 전송하면 데이터를 얻을 수 있다. 예를들면 아래와 같다.

GET https://api.nike.com/me/sport?access_token={access_token}

그럼 아래와 같은 데이터를 얻을 수 있다. 양식은 JSON 이다.

{ "experienceTypes": [ "RUNNING" ], "summaries": [ { "experienceType": "ALL", "records": [ { "recordType": "LIFETIMEFUEL", "recordValue": "3953" } ] }, { "experienceType": "RUNNING", "records": [ { "recordType": "LIFETIMEFUEL", "recordValue": "3953" }, { "recordType": "LEVEL", "recordValue": "0" }, { "recordType": "LIFETIMEDURATION", "recordValue": "40:22:26.000" }, { "recordType": "LIFETIMEGPSRUNS", "recordValue": "1" }, { "recordType": "LIFETIMEHEARTACTIVITIES", "recordValue": "1" }, { "recordType": "LIFETIMEAVERAGEPACE", "recordValue": "7772970.6025488125" }, { "recordType": "LONGESTRUNDISTANCE", "recordValue": "9.5" }, { "recordType": "LIFETIMEDISTANCE", "recordValue": "18.698900000000002" } ] } ] }

3. API 리스트와 API 콘솔

사이트 메뉴를 보면 사용할 수 있는 API 리스트를 알 수 있다.

1. 활동내역 요약 정보 2. 활동 리스트 정보 3. 활동 타입으로 필터링한 활동 내역 정보(퓨얼밴드 Or 런닝만 지원) 4. 활동 상세 정보 5. GPS 데이터

그리고 아래를 보면 API Console 이라는 부분이 있는데, 여기서 API들을 테스트 해 볼 수 있다.

4. 한계점

우선 나이키 개발자 사이트에는 Mobile SDK 라던가, Fuel Band Dev KIT 등의 정보가 올라와 있지만 아직 오픈되지 않았다. 이상태가 꽤나 오래 지속되고 있는데 언제 오픈할지는 아직 미지수 이다. 이 때문에 생기는 문제가 있는데, 바로 Access Token 이다.

현재는 Access Token 이 있어야지만 그 계정의 데이터를 불러올 수 있는데, 나이키 API를 활용한 앱을 만드려면 개인 유저에세 Access Token 을 찾아서 등록하도록 해야 할 것이다. 거기에 추가적으로 이 Token은 30일 마다 refresh 되기 때문에 이부분도 확인해야 한다. 이것은 굉장히 불편하기 때문에 해당 내용을 자동으로 할 수 있도록 하는 우회적인 방법을 사용하기도 한다. (나이키 사이트에 로그인을 하도록 한다음, Access Token 정보를 HTML에서 읽어와서 등록하는 방식도 가능하다.)

또 하나의 문제는 FAQ에서 확인 할 수 있는데, 앱 하나당 한시간에 2000 Request 만 허용한다고 한다. 그 이상은 따로 연락을 해야한다는데, 이부분은 확인이 좀더 필요한 것이 아직까지 API 상에서는 App ID를 등록하는 부분이 없다. 유저의 데이터 요청을 한 시간에 2000개로 제한하는 것인지, 아니면 추후에 App ID를 등록해서 그 것을 2000개로 제한하는지는 아직 명확하지 않다.

5. 결론

CES, MWC 에서 보여지듯 웨어러블 디바이스가 요즘 무척 이슈가 되고 있는데, 그중 선두 주자라고 할 수 있는 NIKE에 Open API를 알아봤다. 하지만 아직까지는 굉장히 미흡한 것을 알 수 있는데 아마 열심히 준비하고 있을 것으로 생각된다. 개발자 사이트 메인에서 처럼 Mobile SDK 와 Fuel Band Dev KIT을 일반 개발자에게 배포하여 쓸 수 있게 한다면 정말 멋진 피트니스 앱들을 개발할 수 있을 지도 모른다. 풍부한 생태계를 먼저 만들어서 강력한 Lock-In 요소로 만드는 업체가 웨어러블 디바이스 시장에서 앞서 나갈 것으로 생각 되는데, 어떤 업체가 가장 앞으로 치고 나갈지 궁금해진다.

[itreading]

이클립스에서 라인넘버 표시하는 방법

이클립스 예전버전에서는 라인넘버 표시하기위에서 옵션을 복잡하게 들어가서 설정해야 했는데, 최신버전에서는 무척 쉽게 할 수 있게 변경되었다.

먼저 각 에디터 화면에서 가장 왼쪽에 빈 공간에 마우스 우클릭을 하면 메뉴가 나온다.

해당 메뉴에서 Show Line Numbers 를 체크해주면 끝!

사진을 참조하면 된다.

[itreading]

이클립스에서 한글 주석이 작게 표시될 때

이클립스를 사용하다 보면 한글로 주석을 다는 경우가 있는데,

한글이 보통 영어 보다 현저하게 작게 표시되는 상황이 발생될 때가 있다.

이 문제는 이클립스에서 에디터에 지정된 폰트를 수정해주면 해결할 수 있다.

우선 Window->Preferences에 들어가서 General->Appearance->Colors and Fonts에 찾아 들어간다.

-

자기가 사용하는 Editor를 찾는다. 이클립스는 각각의 언어 편집기가 Editor라는 형식으로 각각 존재하기 때문에 설정을 따로 해줘야 한다. (에디터가 따로 존재하지 않는경우는 Basic->Text Font를 수정한다.)

-

자바를 기준으로 Java-> Java Editor Text Font 를 선택하고 Edit 버튼을 누른 뒤에 나오는 폰트 편집화면에 아래쪽에 "영어" 로 되있는 것을 "그리스어" 같은 다른 것으로 바꾸면 된다.

-

아래 사진을 참조하면 된다.

여기까지하고 확인을 누르면 주석이 제대로 표시되는 것을 볼 수 있다.

[itreading]

공부하는 방법

모두가 공부하기를 원하는 이곳에서, 실제로 공부를 하든 아니든,

가장 적합한 책인것 같다. 

이 책은 저자 스스로가 메사추세츠 지방공대를, 지잡아님, 15살에 입학했다. 이후, 여기(MIT) 저기(하버드)에서 학생들을 가르킬때 뛰어난 학생들이 의외로 학습시에 헤매는 것을 보고 집필한 공부 안내서이다.

책 중에서, 저자가 중요하게 생각하는 10가지 습관이다.

1. 가장 알맞은 책을 선택하라.

어떤 주제를 놓고 공부할 때는 자신의 수준에 딱 맞는 책을 골라야 한다. 모든 내용이 담긴 어려운 책이 아니라 초보적인 내용을 다룬 책부터 시작해야 한다는 말이다. ‘피상적인 지식’은 늘 ‘기초적인 지식’일 수 있으나 ‘기초적인 지식이’이 곧 ‘피상적인 지식’은 아님을 기억하자.

2. 한꺼번에 너무 많은 주제를 공부하지 마라.

공부하는 동안에는 지금 공부하는 주제에 온 힘을 다해 집중해야 하지만, 한 과목을 공부하다가 지칠 때는 다른 과목을 공부하는 것도 현명한 일이다. 여기서 저자가 하고자 하는 말은 한꺼번에 너무 많은 주제를 공부하기로 마음먹고 성급하게 뛰어들었다가 쉽게 포기하고 다른 것으로 넘어가는 식으로 힘을 낭비하지 말라는 것이다.

해야 할 것도 많고, 하고 싶은 것도 이해한다. 하지만, 지금 당장 당신은 한가지 일에만 집중하자. '이' 한가지도 못하면서, 어떻게 여러가지를 하려고 하는가?

3. 서두르지 마라.

급할수록 돌아가라고 했다. 조급하게 굴수록 오히려 속도는 더 느려진다. 흔히 자기가 공부한 내용에 대해 생각할 시간이 없다고 믿기 쉽지만 공부한 내용에 대해 생각하지 않아도 되는 시간이란 건 없다. 이런 마음가짐을 가지고 끈기 있게 공부하다 보면 짧은 시간에 더 많은 것을 해낼 수 있는 능력을 갖추게 된다.

스스로를 잘 생각해보자. 여태까지 얼마나 빠르게 살고 그렇게 효율적으로 살아왔는가? 뭐라도 하나 끝까지 해보자. 하나씩 하나씩 하다보면 점점 익숙해진다.

4. 적절하게 건너뛰는 능력을 익혀라.

책에 인쇄된 모든 단어를 반드시 다 읽어야 하는 것은 아니다. 문단, 쪽, 때로는 장 전체를 건너뛰어야 할 때도 있다. 상황에 따라서 어느 부분을 건너뛰어도 좋은지 판단하는 능력을 키워야 한다. 물론 이것이 부주의하게 겉핥기 식으로 읽는 습관으로 이어지지 않도록 주의해야 한다.

국내와 달리 해외 서적에서는 꼭 1장부터 순차적으로 읽지 않는 책들이 많다. 국내 도서는 첫 페이지부터 마지막 페이지까지 순차적으로 나열하지만, 해외 서적은 그렇지 않은 경우도 많다. 특히나, 공학계열 원서의 경우 목차와 머릿말을 읽고, 필요 충족을 따져가면서 공부하는 것이 좋다.

5. 체계적으로 공부하라.

과목마다 시간을 정해 놓고 구체적인 계획에 따라 규칙적으로 공부해야 한다. 한 번에 한 과목씩만 공부하고 한 과목에서 다른 과목으로 옮겨 가며 체계적으로 공부하는 습관을 들이면, 언젠가는 휴식이나 오락 시간 없이 여러 과목을 자연스럽게 이어서 공부하는 능력을 갖추게 된다.

6. 집중력을 키워라.

평범한 사람과 똑똑한 사람의 차이는 원하는 것을 향해 집중력을 발휘하는 능력에 달렸다. 제법 긴 시간 동안 한 가지에 완전히 집중(몰입)하는 훈련을 꾸준히 해야 한다. 그런 능력을 갖출 수만 있다면 그보다 더 가치 있는 일은 없다.

칙센트 미하일의 'flow(몰입)' 이라는 책이 있다. 결국 모든일에 순도를 높이기 위해서는 '몰입'이 전제되어야 한다. '몰입'하는 습관을 아직 들이지 못해다면, 읽는 것을 추천한다.

7. 응용하라.

공부한 것은 꼭 응용해 본다. 책으로 읽은 내용은 가능한 한 직접 관찰하고 실험하고 실제 현장에서 경험하도록 한다. 이렇게 하면 배운 것이 진정 자신의 것이 된다. 책으로만 배운 지식은 그것만으로는 별 가치가 없다.

배운 것을 항상 머릿속에 두고, 언제 어느 순간이든 적용할 수 있는지 고민해보자. 물론, 국내에서는 이런 것에 거부감이나 배척감을 가진 사람이 많다. 하지만, 신경쓰지 말자. 약간의 '튐'이 당신을 바꿀 것이다.

8. 반복해서 읽어라.

중요한 부분은 스스로 철저하게 이해했다고 생각될 때가지 거듭하여 읽는다. 영국 사회학자 허버트 스펜서는 이렇게 말했다. “책 몇 권을 철저하게 읽는 것이 여러 권을 수박 겉핥기로 읽는 것보다 훨씬 낫다.”

본인이 이해 했는지 안했는지 확인하는 것은 의외로 쉽다. 아이슈타인 브라더의 명언을 생각해보자. 할머니한테 설명 할 수 없다면 당신은 이해한것이 아니다. 학교 다니면서 많이 경험 했을 것이다. 주위 친구들한테 설명하면서 본인이 정확히 이해하지 못했던 점을 찾았던 경험을 되새기자.

9. 독서 카드를 만들어라.

책을 읽고 나면 독서 목록을 작성하고 배운 내용을 요약하여 독서 카드를 만든다. 이렇게 목록과 카드를 만들어 두면 예전에 공부한 내용이 필요할 때 다시 찾아서 활용할 수 있다. 배우고 익힌 내용을 모두 머릿속에 기억해 두기는 어렵다. 따라서 필요한 내용이 어디 있는지 알거나 스스로 알아낼 수 있는 능력을 길러야 한다.

이와 더불어서, 책을 읽으면서 좋았던 점, 나빳던 점, 의뭉스러웠던 점을 정리해보자. 어느 순간, 좋은 책을 고르는 법을 느끼게 되고, '지뢰'들을 피 할수 있게 해준다.

10. 신체를 단련하라.

건강을 지키는 일이 책에서 읽은 지식을 머릿속에 쑤셔 넣는 것보다 훨씬 중요하다. 정신력을 극대화하려면 무엇보다도 몸이 건강해야 한다. 반대로 해석하면, 몸이 지치면 정신이 제 기능을 못한다는 말이 된다. 어떤 환경에서 가장 공부가 잘 되는지 관찰해 두었다가 그런 환경을 만들고 공부해야 한다.

뇌 활동에 영향을 미치는 성상세포(astrocytes)는 운동에 의해 영향을 받는다. 일회성 운동을 하게 되면, 직후에는 활성화 되나 다시 원래대로 복귀한다. 반면에, 지속적인 운동을 하게되면 활성화된 수치가 정상수치로 변모한다. 추가적으로, 과잉 운동은 오히려 적당한 운동보다 수치가 낮다. 따라서, 지속적으로 적당한 운동을 하는 것이 두뇌 활동에 좋다.

성공한 사람들의 경험담을 보면 위 대다수의 습관들을 이미 가지고 있는 것을 볼 수 있다. 최소한의 규칙들을 꾸준히 유지하면, 적어도 작은 성공으로 귀결되지 않을까?

[itreading]

DIP? SP?

안드로이드 개발에서 쓰이는 단위들에 대해 정리하면서 DIP와 SP에 대해 자세히 알아보려고 합니다. (원문 http://developer.android.com/guide/practices/screens_support.html)

PX - 스크린 픽셀을 나타냅니다 IN - 물리적인 스크린 크기를 기준으로 인치를 나타냅니다 PT - 물리적인 스크린 크기를 기준으로 1/72 인치를 나타냅니다.

DIP (Density-Independent Pixel, DP)는 안드로이드를 지원하는 다양한 스크린을 지원하기 위해 만들어진 가상의 단위로 160dpi 스크린에서의 1px을 1dp로 계산합니다. (160dpi는 medium 사이즈 안드로이드 지원기기의 표준 크기입니다) 포토샵 작업결과는 px로 계산되기 때문에 dp로 작업되는 안드로이드 UI에서 크기를 가늠하기 힘든 부분이 있는데요. px와 dp 관계는 다음과 같은 공식으로 표현됩니다.

px = dp * (dpi / 160)

SP (Scale-Independent Pixels)는 폰트를 위한 단위입니다. DP와 마찬가지로 스크린 사이즈에 비례하여 적용되며 추가로 환경설정에서 설정된 폰트크기에 맞춰 확대/축소됩니다.

dp, sp는 다양한 안드로이드 스크린 사이즈에 적합한 어플리케이션을 개발하는데 중요한 요소입니다. 안드로이드 개발자 페이지에서 제시하는 좋은 개발방법은 다음 4가지를 포함하는데요.

1. wrap_content, fill_parent, dp를 사용하여 XML 레이아웃을 정의합니다 2. 코드에 px값을 직접 저장하지 않습니다 3. AbsoluteLayout을 사용하지 않습니다 (더이상 지원하지 않아요...) 4. 스크린 밀도에 맞춰 다양한 비트맵을 준비합니다

UI를 정의할 때 dp를 사용하면 스크린 사이즈에 비례한 자연스러운 UI를 표현할 수 있습니다. 다만 이벤트 처리나 제스처 개발 시에는 사용자 인풋을 px로 계산해야 할 때가 있는데요 그럴때는 다음과 같이 시스템이 제공하는 스크린 밀도를 불러와 계산할 수 있습니다 (Context.getResources().getDisplayMetrics().density).

// The gesture threshold expressed in dp private static final float GESTURE_THRESHOLD_DP = 16.0f; // Get the screen's density scale final float scale = getResources().getDisplayMetrics().density; // Convert the dps to pixels, based on density scale mGestureThreshold = (int) (GESTURE_THRESHOLD_DP * scale + 0.5f);

Note. 마지막 줄의 0.5는 int로 자료형을 변환할 때 최대정수 값을 얻기위해 더했습니다.

[itreading]

WebView로 웹페이지에서 안드로이드 앱에 명령보내기

웹페이지가 안드로이드 앱에 명령을 보내는 방법은 WebViewClient의 shouldOverrideUrlLoading을 구현하는 것입니다. shouldOverrideUrlLoading은 WebView가 표시하는 웹페이지에서 발생하는 링크요청마다 호출되어 요청된 url을 어플리케이션이 처리할 지 WebViewClient가 렌더할 지를 결정할 수 있게 돕는 함수입니다.

다음 코드 블럭은 shouldOverrideUrlLoading을 구현한 예제입니다. 다음 예제의 WebView를 통해 표시된 웹페이지에 <a href='myservice://foo?action=1&option=2'>FOO</a>라는 링크를 클릭하면 다음 코드에서 ***라인을 실행하여 로그콘솔에 메세지를 출력하게 된다.

public static final String URL_HOOK_SCHEME = "myservice"; private WebView mWebView; @Override public void onCreate(Bundle bundle) { setContentView(R.layout.my_layout_with_webview); mWebView = findViewById(R.id.webview); mWebView.setWebViewClient(new WebViewClient() { @Override public boolean shouldOverrideUrlLoading(WebView view, String url) { Uri requested = Uri.parse(url); String scheme = requested.getScheme(); if (scheme != null && scheme.equals(URL_HOOK_SCHEME)) { Log.d("WebView", "overriden"); //*** return true; // true를 리턴하면 WebView는 해당 URL을 렌더하지 않는다. } else { return super.shouldOverrideUrlLoading(view, url); } } } }

필요에 따라 Host식별, Query Parameter를 추가 등을 통해 다양한 명령을 구현할 수 있다.

[itreading]

WebM(libvpx) 빌드 하기

VP9 빌드하기

인터넷에서 소비되는 컨텐츠 트래픽은 주로 영상(이미지+동영상)이다. 고전에는 부족한 인프라에서 끊김을 줄이기 위해 저용량에 초점을 두었지만, 요즘은 더 좋은 화질을 버퍼링 없이 제공하는 것이 가장 큰 화두다. hd를 넘어서 fhd, qhd, uhd 등 용어가 샘솟고 있다. 심지어 유투브에서도 많은 영상들이 720p를 지원한다. 예전 유투브를 생각하면 정말 큰 발전이 아닐수 없다. 하지만, 이런 고화질 영상에서 빠질 수 없는 요소가 코덱이다. 컨텐츠 제공 업체로서는 특허가 걸려있는 코덱은 고민거리가 아닐 수 없다. 비록, 인터넷 동영상에 한해서 mpeg la가 h.264 코덱을 한정적으로 풀었지만 재생 플레이어는 논외이다. (추가적으로 영상 압축 기법에 대한 라이센스와 구현체인 라이브러리 라이센스는 별개이다. hd영상이 대중화 되면서 퍼졌던 많은 코덱들이 대게 유료였었다.) 브라우저가 플레이어 역활을 하게 되면서 구글은 이에 대응하기 위해 On2 테크놀로지스를 인수하며 동영상은 WebM, 이미지는 WebP 포맷을 보유하게된다. 그리고 해당 동영상 코덱으로 한동안 잘 사용했던것이 VP8이다. 사실 발표전에는 VP8>>h.264라고 했으나, 현재 유투브 조차도 720p는 h.264으로 서빙하고 있다. (h.264가 없고, VP8만 지원하는 브라우저의 경우 720p 모드로 영상을 볼수 없다. ex: chromium, 크롬과 크로미움은 별개의 브라우저다. 크로미움은 오픈소스이고 크롬은 아니며 동일한 프로그램이 아니다. 라이센스가 걸린 h.264코덱은 크롬에서만 지원된다.) 시대가 더 좋아져서 더 좋은 화질을 서빙하는 시점이 점점 다가오면서, 기존 mpeg 에서는 h.265를 준비하고 있고, 구글에서는 이번 CES 2014에서 발표한 VP9이다. WebM, WebP는 아직 오픈 소스로 운영되고 있다. ( http://www.webmproject.org/ ) 해당 프로젝트 사이트에서는 윈도우에서 빌드 방법이 vp8 때 빌드 문서로 지금과 다른점이 있어서 빌드를 실제로 해보면서 이 쓰레드를 마무리 한다. ( VP8 빌드 문서 http://www.webmproject.org/code/build-prerequisites/ )

Build

1) MinGW(MSYS) 준비하기 VC 프로젝트 파일을 만들기 위해서 쉘 환경이 필요하다.

http://www.mingw.org/

최신 버전이 아닌 20101030 버전을 사용을 권장한다. a) pre-packaged repository를 이용하여 mingw-get-inst-20101030.exe 다운한다. b) 기본 폴더(i.e., C:\MinGW)에 설치한다. c) 컴포넌트 선택에서, C++ Compiler, MinGW Developer Toolkit, 을 선택한다. d) msys를 실행한다.

2) Git을 이용한 libvpx 받기 최신 source code 는 git 으로 부터 얻을 수 있다.

$ git clone https://chromium.googlesource.com/webm/libvpx

3) 프로젝트 파일 생성을 위한 makefile 생성하기

$ cd libvpx $ ./configure --target=x86-win32-vs8 --enable-static-msvcrt

target에서 vs8은 2005, vs9는 2008, vs10은 2010이다. 2010용 프로젝트파일을 원하면,

$ ./configure --target=x86-win32-vs10 --enable-static-msvcrt

--enable-static-msvcrt 은 static rundtime library를 위한 옵션이다.

$ make

make를 통해 프로젝트 파일을 생성한다.

3) VC에서 빌드하기

a) make로 생성된 vpx.sln 파일을 실행시킨다. b) vpxenc를 시작 프로젝트로 설정하고 빌드한다. 프로젝트 종속성에 의해 obj_int_extract, vpx, vpxenc 순으로 빌드된다.

빌드가 성공하면, encoder & decoder 와 lib이 생성된다.

vpxdec –codec=vp9 –i420 -o stream_320x256_420.yuv stream.vp9

위와 같은 명령어를 통해 디코딩을 진행 할 수 있다.

[itreading]

Contiki OS를 Arduino에 포팅하기

IoT OS를 표방하고 있는 Contiki OS는 다양한 MCU를 지원하며 쓰레드와 같은 다양한 라이브러리를 Things 들에서 사용할 수 있도록 해준다.

헌데, 최근에 많이 사용하는 Arduino에 이런 OS를 포팅해서 사용하면 더 다양한 것들을 개발 할 수 있을 것 같아서 찾아보았더니 Arduino를 지원하는 Contiki GiyHub를 찾을 수 있었다.

https://github.com/contiki/contiki-arduino

이번 포스팅에서는 이 소스를 사용해 Arduino에 포팅 절차를 설명하려 한다.

주의사항 * 여기서 사용하는 Contiki-Arduino 코드는 Arduino Due 에서는 적용되지 않는다. AVR MCU를 사용하는 것을 기준으로 설명하며 Arduino Uno로 테스트 하였다.

포팅 준비

우선 필자는 윈도우즈 환경에서 진행하였기에 포팅을 위해 아래와 같은 준비를 하였다.

리눅스 환경에서 포팅하는 것은 여기 를 참조하기 바란다.

GitHub에서 소스코드 다운로드

Windows 용 AVR-GCC다운로드

다운받은 WinAVR을 압축풀고 /bin 폴더를 환경변수로 지정

여기 까지 한 뒤에 윈도우즈 커맨드 환경에서 아무 폴더에서나 avrdude 가 실행되는지 확인하면 된다.

빌드

이제 빌드를 할 차례다. 다운받은 Contiki-Arudiono 소스에서 examples/hello-world 를 찾아가서 아래의 명령어를 입력한다.

make TARGET=arduino ARDUINO_MODEL=Uno

WinAvr을 이용해서 컴파일을 자동으로 할 것이다. 시간이 꽤 소모된다.

포팅

빌드가 완료되면 hello-world.arduino가 만들어 졌을것이다. 이제 해당 바이너리를 Arduino의 flash memory로 포팅하도록 .hex 파일로 변환 해야한다. 아래의 명령어를 입력하자

avr-objcopy hello-world.arduino -j .text -j .data -O ihex hello-world.hex

이제 그럼 hello-world.hex 파일이 만들어 졌을 것이다. 이제 이 파일을 Arduino Uno로 전송하기만 하면 된다. 이것을 위해 확인해야 할 것이 Arduino가 연결된 com 포트를 알아야 한다. 장치관리자에 가서 포트를 보면 Arduino가 연결된 포트를 알 수 있을 것이다. 필자의 경우에는 com5에 연결되어 있었다.

avrdude -D -p atmega328p -c arduino -P COM포트 -b 115200 -U flash:w:hello-world.hex:i -v -C 위에서환경변수지정한bin폴더주소/avrdude.conf 필자의 환경 실제 예시 avrdude -D -p atmega328p -c arduino -P com5 -b 115200 -U flash:w:hello-world.hex:i -v -C c:\winavr\bin\avrdude.conf

여기서 주의해야할 점 두가지가 있다.

미리 Arduino 플랫폼을 위한 소프트웨어를 설치해서 드라이버를 받아놓아야 함.

Arduino의 시리얼 모니터를 꺼놓아야 함. 켜놓으면 전송이 안됨

테스트

여기까지 진행해서 완료 했으면, 화면에 진행되는 모습이 나오며 포팅이 완료 된다. 그 후에 아두이노의 시리얼 모니터를 실행하면 Hello-World 가 정상적으로 표시되는 것을 볼 수 있다.

[itreading]

Square OkHTTP와 Android SSLContext 문제

Square에서 만든 OkHttp는 안드로이드를 위해 만들어진 HTTP 클라이언트로 SDK가 제공하는 Apache HttpClient에 비해 사용이 간편하고 효과적이며 (Connection Pooling, Response Caching, Transparent GZIP Supports, etc.) 구글이 개발한 개방형 네트워크 프로토콜인 SPDY를 지원하는 것이 특징입니다. 최근 들어 OkHttp를 사용하는 프로젝트가 많아지고 있는 추세이며 저또한 최근의 프로젝트에서 OkHttp를 사용하였습니다.

OkHttp는 HttpClient와는 비교할 수 없을만큼 편리한 사용성과 만족할만한 수준의 성능으로 저를 즐겁게 해주었습니다. 그런데 프로젝트 막바지에 Google Analytics (GA)를 적용하던 중 문제가 생겼습니다.

libssl: singal 11 (SIGSEV)

전혀 예상치 못한 에러와 함께 종료되는 어플리케이션을 보며 조금 이해가 안되더군요. 왜 잘 작동하던 libssl이 문제인거지? 이때까지만 해도 OkHttp에 문제가 있을거라고 생각조차 못했습니다.

조금 조사를 해보니 해당 문제는 square/okhttp 이슈트래커에서 8개월전에 논의가 되었던 이슈였습니다. 컨트리뷰터인 Jesse Wilson이 남긴 글에 보면 이렇게 나와있습니다.

So the problem is that Java and Android programs default to using a single global SSL context, accessible to our HTTP clients as the SSLSocketFactory. When OkHttp enables NPN for its own SPDY-related stuff, it ends up turning on NPN for the singleton shared SSL socket factory. Later when HttpURLConnection attempts to do SSL, it freaks out and crashes because NPN is enabled when it isn't expected to be.

결론부터 말하자면 문제의 원인은 안드로이드 어플리케이션의 기본 룰이 SSL 컨텍스트를 싱글튼으로 공유하는데 있었습니다. 저의 경우 libssl이 문제를 일으킨 직접적인 원인이 GA를 앱에 붙였기 때문인거죠.

SPDY를 지원하는 OkHttp는 SSLContext의 NPN(Next Protocol Negotiation)을 활성화하여 보안통신에서 어떤 통신 프로토콜이 사용되어야 할지 결정하게끔 합니다. 이 경우 OkHttp를 사용한 통신은 NPN 활성화 사실을 인지하고 이것을 문제삼지 않습니다.

하지만 GA의 경우 OkHttp 클라이언트가 아닌 HttpUrlConnection을 사용하기 때문에 문제가 됩니다. 앞에서 말한것같이 OkHttp도 HttpUrlConnection도 같은 SSLContext를 공유하는데 HttpUrlConnection이 SSL 통신을 하려고 보니 (HttpUrlConnection이 생각하기에) 활성화 되어있으면 안되는 NPN이 활성화 되어 있으니 바로 에러를 뱉고 죽는거죠.

문제를 파악했으니 해결을 해야죠. 가장 간단한 해결법은 OkHttp가 기본 SSLContext를 사용하지 않는겁니다. 다음 코드를 보면 OkHttp 클라이언트에 새로운 SSLContext를 설정하는 것을 확인할 수 있습니다.

OkHttpClient okHttpClient = new OkHttpClient(); SSLContext sslContext; try { sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, null, null); } catch (GeneralSecurityException e) { throw new AssertionError(); // 시스템이 TLS를 지원하지 않습니다 } okHttpClient.setSslSocketFactory(sslContext.getSocketFactory());

이렇게 하면 okHttpClient는 독립적인 SSLContext를 사용하게 되어 다른 코드 혹은 라이브러리에서 HttpUrlConnection(또는 다른 HTTP 클라이언트 라이브러리)으로 보안통신을 시도해도 문제를 일으키지 않습니다.

[itreading]

AllSeen / AllSeen alliance / AllJoyn 이란?

얼마전에 리눅스 파운데이션 주도하에 AllSeen Alliance 라는 것이 출범 되었다는 기사를 접했다. (http://www.engadget.com/2013/12/10/allseen-alliance-internet-of-things-lg-sharp-qualcomm/)

해당하는 기사를 보면 다양한 회사들이 모여서 공통적인 플랫폼의 스마트 홈 서비스를 만들 수 있는 솔루션을 만드는 조직을 구성했다는 이야기를 하고 있다.

기존에 많은 회사들은 UPNP를 확장한 DLNA로 스마트 홈 서비스를 대체했었다. 다양한 미디어 기기들이나, 가전제품에 DLNA를 서포트 한다는 스펙이 많이 적혀 있었던 것을 보았을 것이다. 이제 AllSeen Alliance 에서는 이 DLNA의 한계를 인식했는지, 새로운 플랫폼을 만들어서 퍼트리겠다는, 심지어 이 플랫폼이 IoT(Internet of things : 사물인터넷 - 모든 사물이 인터넷과 연결되어 서비스를 제공하겠다는 개념) 플랫폼의 역할 까지 할 것이라는 원대한 목표를 가지고 얼라이언스가 출범 된 것이다.

-AllSeen Alliance 파트너 회사들-

이 곳의 홈페이지를 들어가보면, 이 플랫폼에 대한 소스코드까지 벌써 오픈소스로서 공개 되어 있다. 그런데, 잘 살펴보면 소스코드의 이름이 무언가 다르다. AllJoyn 이라는 이름을 가지고 있는 패키지의 소프트웨어를 다운로드 할 수 있게 되어 있다.

그렇다, AllSeen Alliance의 현재 솔루션은 AllJoyn 이라는 퀄컴사의 M2M(Machine to Machine) 메세징 솔루션을 이용하고 있는 것이다. 앞으로는 다양한 회사와 연계되고, 오픈 소스로서 확장하기 위해 많은 변화가 있겠지만 지금 오픈되어 있는 오픈소스의 베이스는 퀄컴의 AllJoyn 인 것이다.

그래서 LG는 얼마전에 자사 제품에 AllJoyn을 서포트 하겠다고 발표했는데, 이것을 보면서 AllSeen Alliance에 가장 대표적인 파트너 사로 LG전자가 존재하는 이유를 알 수 있었다.

AllJoyn

AllJoyn은 ISC 라이센스를 따르는데, 거의 BSD와 동일한 아주 자유로운 라이센스 정책을 따르고 있다. 또한 굉장히 많은 OS를 지원하는데 지원하는 목록은 아래와 같다.

특히나 특이한 것은, Arduino 를 지원한다는 점과, Thin Client를 지원하고 있다는 점이다. AllJoyn 자체가 IoT를 표방하고 있기 때문에, 안드로이드나 iOS같은 아주 큰 스마트폰 OS 이외에 작은 센서 네트워크용으로 통신이 가능하도록 하였다. 그래서 이러한 플랫폼에도 지원할 수 있도록 Thin Client라는 것을 만들었고, 이 것을 arduino 용으로 포팅한 바이너리를 샘플처럼 제공하고 있다.

다만, 문제점이 있는데 이 Thin Client는 Standard 버전의 AllJoyn이 근처에 있지 않으면 동작하지 않는 다는 문제점이있다. Thin 하다 보니 모든 통신 프로토콜을 담을수가 없기에, 대부분의 처리는 Standard 버전의 Daemon을 통해 하도록 되어 있고 Thin Client에서는 Standard 클라이언트를 찾아서 그 곳을 게이트웨이처럼 이용하도록 되어 있는 구조이다.

사실 이러한 문제점은 굉장히 중요하다고 생각한다. IoT를 표방하는 플랫폼이 작은 개체 하나하나가 각각 스스로 동작할 수 없고, 주변에 무언가를 처리해줄 커다란 플랫폼이 존재해야 한다는 것. 이러한 제약사항으로 사실 AllJoyn은 제대로된 IoT 플랫폼이라고 말할 수 없을 것 같다. 아마 오픈소스화가 되고 개인들과 다양한 업체에서 활발히 컨트리뷰션을 진행한다면 이러한 문제점들이 언제가는 해결 될 수 있을 것이다. AllSeen Alliance 에서도 그러한 효과를 기대하고 있을 것 같다.

그런데...?

그런데 살펴보면서 아주 중요한 또 다른 문제점을 발견했다. 바로 파트너사가 너무나도 부족하다는 점이 었다. 사실 DLNA가 그나마 많이 퍼진 이유중에 하나가 200개가 넘는 수 많은 파트너사를 가지고 있었기 때문이다. 아직까지 AllSeen Alliance는 그 수가 너무나 부족하다. 진정한 공통된 스마트홈 플랫폼으로 만들어 지기 위해서는 수 많은 전자회사, 통신회사, 칩 제조사등등의 파트너사들이 연합에 가입을 해야 할 것이다. 이것이 AllSeen Alliance에 가장 먼저 해결 해야 될 요소 일 것이다.

정리하며

이번 포스팅에서는 스마트 홈을 위한 새로운 연합인 AllSeen Alliance에 대해 살펴보았다. 아직 까지는 확산여부를 알 수 없으나, 다양한 디바이스를 하나로 통일 시킬수 있는 이러한 프레임워크가 널리 퍼져서 모든 기기들을 하나로 묶을 수 있는 세상이 빨리 왔으면 싶다.

[itreading]

JQUERY PLUGIN을 이용해 이미지 ORIENTATION EXIF 정보 찾기

이번 포스팅에서는 jQuery 를 이용해 이미지가 촬영된 방향을 찾는 방법에 대해 알아보려 한다. 최근에 휴대폰으로 사진을 찍는 경우가 매우 많다. 그렇게 촬영된 이미지들은 사실 언제나 같은 방향으로 찍혀져 있는 것을 볼 수 있다. (물론 최근에 나온 이미지 뷰어들은 자동으로 보정된다...)내가 폰을 어떻게 들고 촬영했는지에 따라 이미지자체가 바뀌어서 저장되는 것이 아니라, 폰의 방향을 이미지의 EXIF 정보에만 기록하도록 되어 있기 때문이다.

대부분의 사진을 공유하는 서비스들은 이러한 정보를 활용하여 이미지를 보정해서 보여주기 때문에, 별 생각하지 않고 넘어갈 수 있지만 만약에 우리가 개발자의 입장으로 이러한 서비스를 개발하게 된다면 이러한 부분을 고려하지 않을 수는 없을 것이다. PHP 혹은 JSP 같은 언어들은 이러한 EXIF 정보를 활용할 수 있는 방법들이 많이 존재하며 기본 라이브러리에도 많이 반영되어 있다. 하지만, HTML+JS 로만 개발해야 되는 환경에서는 이러한 방법들을 모두 사용할 수 없기 때문에 다른 방법을 사용해야 한다.

여기에 플리커 에서는 이러한 방법에 대해 자세하게 기록한 테크리포트를 작성하였다.

다만, 해당 내용을 읽어보면 알겠지만, 무척 복잡한 방법을 사용하여야 한다.... 그래서 다양한 오픈소스들을 검색해 보았고, 괜찮은 오픈소스를 찾게 되었다.

바로  Jacob Seidelin 이 개발한 jQuery Exif JS 이다. 라이센스는  MPL 1.1 을 사용한다. (http://blog.nihilogic.dk/2008/05/jquery-exif-data-plugin.html)

우선 이 분께서는 먼저 EXIF-JS 라는 자바스크립트 라이브러리를 먼저 배포하고 있었는데, 이에 대한 jQuery 버전을 추가로 만들어서 배포하고 있다. 퓨어 자바스크립트 버전은 여기서 받을 수 있다.

다만 테스트를 진행하는 도중 크롬에서 동작하지 않는 버그를 발견해서 찾은 것이 jQuery 버전이다.(블로그 주소는 http://blog.nihilogic.dk/ 인데, 이상하게 필자의 PC에서는 Labs가 접속이 되질 않는다. )

라이브러리의 사용

그럼 이 라이브러리에 대해 좀 더 알아보자. 라이브러리의 코드는 여기

  먼저, 가장 중요한 것이 이 라이브러리는 이미지를 Ajax call 해서 가져오는 방식을 사용하기 때문에 로컬 서버라도 띄워서 테스트해야 한다는 것이다. 필자는 file:// 프로토콜로 테스트를 하다가 많은 시간을 "왜 안되지?" 하는데 잡아먹었다....

자 그럼 어떻게 사용하는지 아래의 코드를 보겠다.

<img id="img1" alt="" src="img1.jpg" /> $('#img1').bind('click', function(){ alert($(this).exif('Orientation') ); });

아주 간단하다. 먼저 img 태그에 exif="true" 라는 속성을 추가한다. 그 다음 jQuery 문법으로 exif("속성") 을 사용하면 데이터를 받아 올 수 있다. 사진의 방향은 Orientation 속성에 있다.

헌데 이렇게 코드를 사용해보면 정수형의 숫자로 표시되는 것을 볼 수 있다. 해당하는 숫자의 의미는 다음과 같다 .

대부분의 사진은 1, 6, 8 의 Orientation 값을 가지고 있을 것이다.

이제 해당하는 각도로 사진을 회전시키면 된다. . . . . .

그런데 지금까지 HTML-JS 로만 개발할 때의 상황이었는데, 사진을 회전시키면 된다고 설명하고 끝맺으면 이부분에서 다시 막힐 것이다. CSS3 에 image-orientation 이란 속성이 있는데 이것을 지원하지 않는 브라우저도 꽤 있기 때문이다.

그래서 jQuery 플러그인을 하나더 소개하려 한다. 바로 jQueryRotate 이다. MIT 라이센스이며 바로 최근까지도 업데이트 되고 있기에 꽤 신뢰성 있는 라이브러리 이다.

TIP - 만약 HTML5 지원이 잘 안되는 브라우져를 사용한다면 아래의 코드를 헤드에 넣는 것 잊지말자

<!--[if lt IE 9]> <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"> </script> <![endif]-->

참고 : http://blog.nihilogic.dk/2008/05/jquery-exif-data-plugin.html http://blog.csdn.net/daisyhd/article/details/6000962 https://code.google.com/p/jqueryrotate/ http://blog.rrikesh.com/jquery/how-to-get-exif-data-from-images-using-jquery/

[itreading]

iOS7의 Multipeer Connectivity Framework 살펴보기

[본 포스팅은 WWDC 2013 에서 발표된 자료를 토대로 작성하였습니다.]

iOS 7이 최근 업데이트 되면서 많은 사람들에게 이슈가 되고 있다.

가장 많이 이슈가 되는 것은 아무래도 사용자의 입장에서 가장 큰 변화인 Flat UI 겠지만, 개발자의 입장에서는 어떠한 기능들을 더 사용해서 개발할 수 있는지가 중요할 것이다.

이번 포스팅에서는 새롭게 추가된 것들 중, Multipeer Connectivity Framework에 대해 알아보려 한다.

한마디로 이 프레임워크를 설명한다면, 근접한 디바이스간에 데이터를 교환할 수 있도록 하는 프레임워크다.  이것은 개인적으로 생각하기에 게임, 교육 멀티미디어, 위치기반 서비스등에 많은 혁신을 가져다 줄 수 있을 만한 프레임워크라는 생각이 든다.

애플은 WWDC 2013 에서 이 프레임워크를 공개할때 이런 기능을 위해서 다양한 무선 기술을 사용한다고 이야기 했는데, 기중 특이한 것이 Peer-to-Peer Wifi-Networking 이다. 애플에서 설명하기로는 AP에 연결되어 있지 않아도, 서로 다른 AP에 연결되어 있어도 서로 통신 할 수 있도록 설계된 기능이라고 한다. 최근에는 Wi-Fi 와 Wi-Fi Direct 가 서로 다른 칩셋으로 동작하기 때문에 각각 동작할 수 있는데 이것과 비슷한 개념을 사용하는 것으로 보이지만 명확하게 어떤 것인지는 알 수 없었다.

[ Bluetooth, WiFi, P2P WiFi ]

발표자료에서 이 프레임워크는 아래의 기능을 제공한다고 설명하였다.

다양한 무선 기술을 종합하여 가장 적합한 방식으로 연결

편리하게 디바이스를 찾고, 초대할 수 있는 UI

메세지와 스트림데이터를 모두 지원

인증과 암호화

그럼 이제, 이러한 기능들을 어떻게 개발할지에 대해 알아보자. 애플에서 이야기 할때 이 프레임워크에는 아래와 같이 2가지 Phase 가 존재한다. 앞으로 이 단계들에 대해 살펴보자.

Discovery : 근접한 디바이스를 찾아주는 단계

Session  :  데이터를 교환하는 단계

1. Discovery Phase

디스커버리 단계는 근접한 단말을 찾아주는 단계이다. 디스커버리의 순서는 이렇다.

a) Browser의 기능을 가진 1단말이 근접한   Advertiser 기능을 가진 2, 3단말을 찾는다. b) 1 단말이 2, 3 단말에게 초대 메세지를 보낸다. c) 2, 3 단말이 Accept 를 한다. d) 1 단말이 완료 버튼을 누르면 세 단말은 Session을 가지고 통신을 할 수 있다.

  위에서 Advertiser 와 Browser 라는 용어를 사용했는데, 애플은 이를 아래와 같이 정의했다.

Browser - 주변에 근접한 기기를 찾을 수 있는 단말 Advertiser - 주변에 자신이 있다고 알릴 수 있는 단말

프레임워크에서 제공하는 API를 사용해서 Advertiser는 자신을 찾을 수 있게 Advertising을 시작해놓고 있으면, Browser가 해당 단말을 찾아서 초대하는 방식으로 세션에 참가하도록 만든다. 여기서 중요한것은 Browser는 MCBrowserViewController 라는 미리 정의된 ViewController를 사용하게 되어 기본적인 UI를 모두 제공해 준다는 점이다. 그래서 Accept를 누른 Advertiser들이 생겨나면 Browser의 View에 Done 버튼이 활성화 되어 세션을 활성화 시키는 데 까지 모든 UI를 제공해 준다.

2. Session Phase

위 처럼 디스커버리를 완료하고, 원하는 모든 참가자가 세션에 참가하고 나면 데이터를 주고 받을 수 있게 된다. 애플에서 이야기하는 데이터의 종류는 메세지, 스트리밍, 리소스 이다.

Message : 일반적인 데이터로 순차적으로 도착하는 것을 보장한는 Reliable 모드와, 속도를 우선시하는 Unreliable 모드가 존재. 모든 피어에게 전송가능 Streaming : 데이터 스트림을 계속해서 보내는 기능으로 한 피어에게만 전송가능 Resource : 파일을 보내는 기능으로 한 피어에게만 전송가능.

여기서 중요한 점은 위 세가지 데이터의 종류에 따라 보내는 메서드, 받는 콜백 모두가 달라서 사용의 주의를 필요로 한다,

자, 그럼 여기까지 디바이스를 찾고, 세션을 만들어 데이터를 전송하는 기능들에 대해 살펴 보았다.

그런데, 지금까지 보여줬던 기능들에서 아주 신기하고 특이한 기술들은 보이지가 않았다. 기존에도 많은 솔루션들이 기기를 찾고, 데이터를 교환할 수 있게 하는 프레임워크가 많이 나왔었기 때문이다. 그래서 애플은 이 슬라이드를 보여주었다.

특이한 점이 보이는가? 바로 위에 있는 디바이스는 블루투스만 가능하고, 아래에 있는 디바이스는 와이파이만 가능해도 중간 연결점이 존재한다면 모든 디바이스가 데이터를 주고받을 수 있다는 것이다. 이러한 부분을 개발자가 신경쓰지 않아도 프레임워크가 해결해 준다는 것은 무척 고무적인 일이라는 생각이 든다.

해당하는 자료의 영상과 PDF 는 아래에서 받을 수 있다(개발자 계정 로그인 필요)

https://developer.apple.com/wwdc/videos/index.php?id=708

참고 :

개발자사이트 레퍼런스 : https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/Reference/MultipeerConnectivityFramework/_index.html#//apple_ref/doc/uid/TP40013328

샘플코드 :  https://developer.apple.com/library/ios/samplecode/MultipeerGroupChat/Introduction/Intro.html#//apple_ref/doc/uid/DTS40013691