OPEN API 제공을 위한 SOA(Service Oriented Architecture)

[출처 : KTH, 2011년11월25일]

개요 : Open API, Library 기반의 Mash-up서비스/사업을 위한 System Architecture

요즘 OPEN API의 중요성이 대두되고 있다. 아마존, 페이스 북, 구글 등 유명 IT업체에서도 OPEN API를 발표하고 있고, 이를 통해 3rd 개발자들이 만들어 낸 신규 서비스들을 재판매(제공)함으로써 서비스의 규모를 키워가고 있다. 물론, 수익금은 3rd 개발자에게 돌려주는 에코시스템을 표방한다.

사내의 자원을 이용하는 OPEN API 자체도 중요하지만 OPEN API의 결과인 Mash Up 서비스를 재판매(제공)하여 유기적으로 서비스 규모를 키워가기 위해서는 프로세스와 데이터들이 통합되어 있고 변화에 유연하게 대처할 수 있는 서비스 중심 아키텍처(SOA) 구성도 중요하다.

  1. Time To Market 가능한 SOA(Service Oriented Architecture)의 의미
    SOA는 소유하고 있는 소스, Application, Platform, System, Infra등의 자산/자원을 재사용 가능한(독립적인) 서비스 단위로 분리하고, 다른 서비스 단위와 조합(orchestration)할 수 있는 인터페이스를 제공하도록 구성된 아키텍처이다. 또한, 서비스 단위를 실시간으로 조합하여 손쉽게 새로운 서비스를 만들어 내는 Time To Market 실현이 가능한 구조로 구축되어야 한다.SOA에서의 ‘서비스’와 ‘서비스 단위’의 의미는 아래와 같다.
    서비스 재사용하기 편리하도록 서로 독립적이어야 하고(낮은 결합도), 그것 하나로 하나의 서비스에 집중되어 있어야 하고(높은 응집도), 외부에 내부의 구성방식이 노출되지 않아야 하며(정보은닉->캡슐화) 이렇게 하려니 서비스간 결합을 통하여 확장이 용이하도록 제각각 Interface를 가지고 있는 것
    서비스 단위 독립적으로 제공될 수 있는 가장 작은 단위의 서비스. (어느 정도로 분할할지는 서비스 특성에 맞추어 결정해야 함. 기능 단위들의 조합)

    서비스 단위는 기능 단위와 동일한 개념이 아니다. 예를 들어, 사용자는 A라는 서비스를 인터페이스(API)를 이용하여 호출한 후 사용(다른 서비스와 조합하던지 아니면 그냥 하나만 사용하던지)만 하는 것이지, A서비스를 사용하기 위해 이런저런 판단(로직)이 필요해서는 안 된다.

2. 서비스 단위의 재사용이 가능한 SOA의 일반적인 구성
<전통적인 구현 방식과 SOA 구현 방식>

전통적인 구현 방식 시스템 구조 기반으로 설계 및 구현. 서비스 환경 변화 및 정책 변화에 대한 대응이 시스템 구조부터 고려되어야 하기 때문에 시간이 소요
SOA 구현 방식 서비스 단위로 분리. 서비스 환경 변화 및 정책 변화 시 서비스 단위들을 조합하거나 또는 신규 서비스를 유연하게 추가하여 신속한 대응이 가능 서비스 단위가 Interface로만 소통이 가능한 Black Box. 수정 시 영향도 적음

물론, SOA의 서비스 단위가 이렇게 유연해 지기 위해서는 아래와 같은 내부 구조가 필요하며, 아래의 관리, 통합, BI야 말로 SOA가 지향하는 바이다.

<SOA 구성도> 비즈니스 프로세스 관리 – 서비스 조합의 결과로 생긴 비즈니스 프로세스 모니터링. 위험감지 및 대응 – 시장 내외부 변화에 대응하는 정책 추가 시 서비스 단위의 재조합을 통한 비즈니스 로직 자동반영
데이터 및 Legacy System 통합 – 서비스 별로 독립된 이기종 DB의 DATA통합 및 활용 위한 Big Data관리. – Legacy System간 호환을 위한 미들웨어 제공
통계/위험관리/미래예측 Business Intelligence – 통합 된 프로세스와 DATA를 이용하여 통계 추출(DATA Warehouse), 환경변화에 따른 위험감지, 미래 예측(Data Mining) 가능하도록 구축

기존 시스템과 데이터 구조를 변경해야 하는 SOA는 더 많은 시너지를 내기 위해 전사적으로 수행해야 하면 그렇기 때문에 단계적으로 진행되어야 한다. 서비스 단위의 구축은 Buttom-Up이어야 하지만 SOA 기반 플랫폼으로의 변화 의지는 Top-Down 으로 진행되어야 한다.

3. 전사적으로 수행해야 하는 SOA 적용 단계

단계 목표 내용 성숙도
No SOA SOA 이해 SOA 필요성 정리 및 사례 연구 단일 비즈니스 프로세스,데이터 통합
SOA 정의 핵심 기능 서비스 단위로 표준화 단일 프로젝트,시스템 통합. 레거시 시스템 주요기능 서비스로 표준화
SOA 전개 이 기종 Legacy System 통합 동일 업무영역 통합. Composite Service 전사 프로세스, 데이터 통합
SOA 성숙 비즈니스와 IT환경 통합 전사 업무영역 및 시스템 통합 Service Orchestration프로세스 자동화 비즈니스 프로세스 자동관리
SOA 완성 변화에 실시간 대응 기업외부 업무영역 및 외부 시스템 통합 서비스 모니터링 및 실시간 반영Package Services Business Intelligence

요즘 우리 회사에서도 OPEN API의 필요성에 대해 많은 사람들이 얘기하고 있으며, 자연스럽게 데이터 및 중복된 시스템들과 업무들에 대한 통합 및 유연한 관리 그리고 데이터에 대한 활용까지 논의되고 있다. 따라서 우리 회사의 단계는 2단계인 SOA 정의 단계라 하겠다.

4. SOA 정의: 단일 비즈니스의 데이터와 프로세스 통합 예시
현재 내가 맡고 있는 비즈니스는 PHP기반의 웹 서비스(ollehmap.paran.com)이며 RDB와 연동되어 있다. 또한 다수의 외부 시스템 및 Legacy System 들과도 연동이 일어나야 한다. 난 향후에 진행 될 타 비즈니스와의 프로세스 및 데이터 통합에 손쉽게 대응하기 위해, 그리고 지속적인 서비스 개편 요청에 유연하게 대응할 수 있는 구조로 현재의 비즈니스 프로세스와 데이터를 통합할 계획이며 일부는 진행되고 있는 상황이다.간단하게 정리하면 개발자라면 누구나 알고 있을 흔하디 흔한 MVC모델을 비즈니스에 적용하는 것으로 SOA의 2단계인 SOA의 정의를 실천하고 있는 것이다. 좀 다른 점이 있다면 controller를 API형식으로 구현한 것이지만 자체적으로 판단해 볼 때 서비스 지향적인 API는 아닌 듯 싶어 개선이 필요하다.올해까지 계획되어 있는 단일 비즈니스의 2단계를 마무리 하면 전사 프로세스와 데이터를 통합해야 하는 3단계 SOA의 전개를 실시해야 한다. 이를 진행하기 위해 해야 할 일은 아래와 같다- 전사 단위 비즈니스의 SOA 정의 단계 완료
– 단위 비즈니스가 관리하는 데이터와 SOA정의 단계의 결과인 API, 프로세스 공유
– 중복되는 데이터, 프로세스, API 식별 및 정리
– 동일 시스템(Legacy System등)에 접근하는 Interface 표준화
– 단일 비즈니스의 서비스를 조합하여 가능한 비즈니스에 대해 Composite Service 구성

5. 맺음말
SOA 진행은 비즈니스(서비스) 외부를 개편하는 것이 아니라 내부인 플랫폼을 개편하는 것이기 때문에 “지금도 잘 돌아가는 걸 왜?” 라는 의문들이 항상 생길 수 있다. 따라서 전사적으로 SOA 필요성에 대해 홍보하고 함께 이해해 나가는 단계가 필요하다. OPEN API가 필요하다고 많이 얘기되고 있지만 제대로 된 OPEN API를 만들기 위해서는 기반이 되는 플랫폼이 잘 통합되고 변화에 유연하게 대처할 수 있도록 관리되고 있어야 한다. 우선은 본인이 담당하는 단일 비즈니스의 플랫폼 부터라도 SOA를 적용하여 개선해 보겠다는 의지가 필요하다.

페이스북 스파르탄 프로젝트의 비밀병기 Bolt.JS

[출처 : kth 웹어플리케이션팀, 2011년11월10일]

웹 서비스와 어플리케이션 개발을 위해 대부분의 경우 jQuery를 사용한다. 가볍고 훌륭한 이 프레임웍은 전 세계 개발자의 열기에 힘입어 거의 웹개발을 위한 표준 프레임웍이 되었다. jQuery 외에도 jQueryMobile과 Sencha Touch, jQTouch 등 몇가지 프레임웍이 더 있고 계속해서 새로운 종류가 등장하고 있다. 그만큼 프론트엔드 개발분야가 다양하다는 것을 시사하지만 프레임워크마다 좋은 점을 내세우고 개발의 편의성과 효율성을 자랑하는 가운데 정작 프레임워크 간에는 어떤 상호 연결성도 없으며 각각의 프레임워크를 위해 제작된 플러그인이나 라이브러리를 목적에 맞게 조절하지 않고는 그냥 가져다 쓸 수 없다. 이런 점 때문에 개발자는 프로젝트에 프레임워크별로 의존성이 생기는 것을 꺼리게 되고 프로젝트마다 저마다의 고유한 라이브러리나 프레임워크를 제작하려는 경향을 보였다.

이런 문제의 근본 원인은 자바스크립트가 중/대형 규모의 어플리케이션 제작이나 재 사용성 확보에 있어 반드시 제공해야하는 ‘모듈화 프로그래밍 구조’에 무게를 두고 설계된 언어가 아니기 때문이다. YUI와 PrototypeJS 에 이어 jQuery를 활용하는 시기가 지나는동안 개발자들은 모듈화 프로그래밍 문제를 해결하기 위해 자체적으로 꾸준한 시도를 해왔으나 폭넓은 사용자 층을 얻지 못하였다. 그러던중, 2009년 1월에 Kevin Dangoor에 의해서 “ServerJS”라는 이름의 프로젝트가 시작되었다. 곧 “CommonJS”로 변경된 이 프로젝트는 웹 브라우저 밖의 환경을 위한 자바스크립트 ecosystem 을 기술하는 것을 목적으로 하고 자바스크립트의 가장 취약한 부분중에 하나였던 ‘모듈화 개발을 위한 API 표준’을 제시하여 중/대형 규모의 어플리케이션 제작에 물꼬를 트게 하였다.

바로 이 CommonJS API 규격을 바탕으로 Facebook에 의해 제작된 Bolt.JS는 공개되자마자 전 세계 개발자의 상당한 관심을 끌었으나 돌연 GitHub등에서 소스가 삭제되고 어떠한 추가 공지도 없이 제대로 작성되지 않은 홈페이지 문서만 제공될 뿐이다. 홈페이지 문서와 관련된 기사를 훝어보던 중, 단순한 UI 프레임워크가 아님을 직감하였고 여러 경로를 뒤진후에 얻은 소스를 분석하였다. 예상대로 공식문서에서 보이는 것보다 훨씬 잠재력이 있다는 것과 웹 어플리케이션 제작에 있어 상당 부분에 영향을 줄 수 있다는 것을 이 리뷰를 통해 기술하고자 한다.

개요:
BoltJS는 오직 HTML5와 자바스크립트만을 사용하여 환상적인 모바일 웹 어플리케이션을 제작하는 것을 도와주는 UI 프레임웍이다. 서버사이드 처리 과정이 필요없으며 자바스크립트로만 작성되어 브라우저에서 동작하는 BoltJS는 현재 모바일 WebKit 기반 브라우저에 맞춰져 있다. 현재 Facebook의 Spartan 프로젝트가 모바일 WebKit에 초점을 맞추고 있기 때문이다.

구조 및 내장 기능:
Bolt.JS는 공개된 베타버전에서만 13,496 라인에 이르는 코드로 작성되어 있으며 다음과 같은 주요 패키지를 CommonJS 규격에 맞추어 자체적으로 포함하고 있다.

도식 1. Bolt.JS 구조

iScroll v4는 모바일용 HTML5 어플리케이션에 스크롤 관련 필수 기능을 제공하며 tokenizerTypeahead는 유용한 입력기능을, underscore.js 는 functional programming에서 쓰이는 고차함수 (higher-order function) 라이브러리로써 모듈성과 템플릿 기능을 제공한다. 이중에 눈여겨 봐야 할 것은 Javelin.JS 인데, 이벤트 처리를 모바일 웹 어플리케이션 제작에 최적화 시킨 프레임웍이다. Javelin.JS는 또 하나의 주제가 되므로 본 리뷰에서는 제외하였다.
또한, 모바일 웹 어플리케이션 제작에 있어 핵심적인 레이아웃과 ‘View’ 라 명명되는 내장 UI가 상당수 제공된다:

도식 2. Bolt.JS UI components

특징: LDAP 처럼 CommonJS 스펙을 구현하였다는 점이다.
서버사이드 자바스크립팅 환경인 NodeJS 역시 CommonJS 스펙에 기반하여 API를 작성하였기에 안정버전이 0.6 이지만 사용가능 모듈수는 2011년 11월 8일 현재 4870개에 달하며 다양한 서버측 요구조건에 맞는 모듈을 쉽게 찾을 수 있다. 2010년 초반에 소개된 NodeJS 가 불과 2년이 되지 않은 시점에서 이렇게 발전할 수 있었던 것은 저마다 제각각의 API를 가졌던 jQuery, ExtJS, YUI는 달리 CommonJS API에 기반하여 모듈을 제작할수 밖에 없는 구조 때문이다. Bolt.JS 역시 표준화된 API 덕분에 어플리케이션 개발자는 서로의 모듈을 손쉽게 가져다 사용할 수 있으며 통합개발환경 (Facebook이 제작한다는 루머가 있지만 확인하지 못하였다) 의 도움을 받아 고수준의 어플리케이션을 손쉽게 만들 수도 있는 것이다.

예제 코드:
전통적인 ‘HelloWorld’를 표시하는 예제를 통해 Bolt.JS의 활용을 살펴보자. 우선, 기존 웹 어플리케이션과는 달리 ‘패키지’ 개념이 있다는 점이 틀리다. 패키지는 .html 파일과 .js, .css 등으로 구성되며 package.json 파일에 JSON 포맷으로 기술되야 한다. 이 역시 CommonJS 요구사항이다.

package.json:

{
“bolt_build_manifest” : [{ “sources”: [ “css”, [“”, “js”]],
“package_target”: “pkg”, // 이름이 ‘pkg’인 폴더를 가리킨다
“package_name”: “helloworld”}] }

– View를 정의하는 helloworld.js:

require.define({‘helloworld’: function(require, exports, module) {

var core = require(‘javelin/core’);
var View = require(‘view’).View;

var HelloView = core.createClass({
extend: View,

declare: function(options) {
return{
content: “Hello World!”
}}
})

exports.init = function() {
require(‘builder’).build({
view: HelloView
}).placeIn(document.body);
}

}});

– Control 을 담당하는 helloworld.js (위의 것과 이름이 같지만 다른 폴더에 있다):

var core = require(‘javelin/core’);
var View = require(‘view’).View;

var HelloView = core.createClass({
extend: View,
declare: function(options) { return{ content: “Hello World!” }}
});

exports.init = function() {
require(‘builder’).build({ view: HelloView }).placeIn(document.body);
}

– 마지막으로, helloworld.html이다 (helloworld.css 파일은 생략):

<html>
<head>
<title>Hello World Application</title>
<meta name=”apple-mobile-web-app-capable” content=”yes”>
<meta http-equiv=”content-type” content=”text/html; charset=utf-8″>
<meta name = “viewport” content=”initial-scale=1,maximum-scale=1,user-scalable=no,width=device-width,target-densityDpi=device-dpi” />
<link rel=”stylesheet” href=”lib/bolt.css” type=”text/css” media=”screen” charset=”utf-8″>
<link rel=”stylesheet” href=”pkg/helloworld.css” type=”text/css” media=”screen” charset=”utf-8″>
<script src=”lib/bolt.js”></script>
<!– HelloWorld JS –>
<script type=”text/javascript” charset=”utf-8″ src=”pkg/helloworld.js”></script>
</head>
<body>
<script type=”text/javascript” charset=”utf-8″>
var helloworld = require(‘helloworld’);
helloworld.init();
</script>
</body>
</html>

단순한 예제여서 Bolt.JS의 특징을 한번에 파악할 수는 없지만, 모듈 기반의 개발방식을 한눈에 알 수 있다. CommonJS 규약을 지키는 Node.JS 모듈을 Bolt.JS의 모듈로써 사용할 수도 있을 것이다. 성공적인 중/대형 규모의 어플리케이션의 특징가운데 하나는 모듈화에 있으므로 Bolt.JS의 API 표준화 정책은 많은 개발자의 참여를 불러일으킬 것이라 예측할 수 있다.

활용:
지정된 프레임워크가 없는 사내 개발환경에 CommonJS 규약에 의한 개발방식은 언뜻 생각해도 몇몇 부분에서 시너지 효과를 가져올 것이라 쉽게 예측할 수 있다:

– 각 부서별/팀별로 중복으로 제작할 필요가 없고, 부서별로 모듈을 유지보수하는 비용이 줄어들 것이다.
– 사내에서 개발하는 것 자체가 글로벌에 적용될 수 있다.

결론:
Apple AppStore에 휘말리지 않겠다는 의지를 보인 Facebook의 행보는 HTML5 어플리케이션 개발의 흐름에 한번더 큰 변화를 가져다 줄 것이며 글로벌 사업을 향하는 여러 업체의 사업방향에도 영향을 줄 것이다. 따라서, Bolt.JS 와 CommonJS 표준화 개발방식을 검토할 필요가 있다는 것을 강조한다.

미디어 플랫폼의 확장

이미 1년전에 등장한 서비스로 이미 알고 계신 분도 있을 줄 압니다만…

현재 tving의 주 용도인 방송보기와 더불어 판매.홍보 마케팅 툴로 확대하여 좀 더 다양한 경험을 제공하고 tving을 활성화 할 수 있는 사례가 있어 공유드리고자 합니다.

 

영국 브랜드인 프렌치커넥션이 영상 기반인 유튜브 채널에 온라인 상점을 열어 판매를 유도하고 있습니다.

모델의 핏팅모습과 각종 정보는 물론 바로 구매도 가능합니다.

영상내에서 이뤄지는 다양한 인터랙션과 유니크한 영상들은 독특한 감성을 전달하고 sns에 유통되기에도 좋은 퀄리티과 스토리를 갖고 있습니다.

http://www.youtube.com/frenchconnection#p/c/FABF1C5ECB9D9616/8/C05IiZNFynU

 

방송 콘텐츠를 시청할 수 있는 서비스 뿐만아니라 다른 채널에선 볼 수 없는 유니크한 영상, 정보를 담은 미디어 플랫폼으로 브랜드 및 기업 마케팅에 활용해 본다면 비록 제품의 구매와 직접적인 영향은 작더라도 tving의 가치를 발굴하고 확장하는 가능성의 시도차원에서 의미가 있을 것이라고 생각합니다.

 

그리고 현재 tving에 영화 카테고리가 신설되었는데

좋은 서비스와 훌륭한 콘텐츠임에도 불구하고 그 활용성에서 조금 아쉬운데요

itunes처럼 임팩트있는 화면 구성을 통하여 몰입도를 높이고 템플릿화하여 운영이슈도 줄이는 노력이 필요해 보입니다.

 

http://www.tving.com/sm/ms/SMMS100Q.do

 

http://trailers.apple.com/trailers/wb/harrypotterandthedeathlyhallowspart2/

 

TV 이탈 현상, 10대 평균 시청시간 5년만에 30% 감소

ここから本文です

若い世代のTV離れが一目瞭然 視聴時間が5年で3割以上も減少

NEWS ポストセブン 11月4日(金)7時6分配信

テレビの危機を指摘するのに、もはや言葉は要らない。客観的なデータがそれを如実に示している。

テレビの視聴率低下がいよいよ深刻である。

10月3~9日の視聴率トップは、日本テレビ系『笑点』で18.1%。これは週間1位としては史上最低の数字だった。さらにその前週(9月26日~10月2日)には、かつてなら低視聴率に入る12%台の番組がトップ30以内に入るといった具合である。

フジテレビ系列の産経新聞は、紙面でこう嘆いた。

〈ついにその日がきた、という感じだ。「12%台」でもトップ30入りしてしまった。前代未聞の事態だ。(中略)ことここに至っては、よほどフンドシを締めてかからないと「回復」どころか「歯止め」すらおぼつかなくなるのではないか、と危惧する〉(10月4日付)

だが、こうした事態にもテレビ関係者は、「録画視聴が多くなったから」だの、「若い世代は携帯やワンセグで見ている」だのと言い訳する。つまり、実際の視聴率はもっと高いはずだと強弁するのだ。

だが、それがウソであることは、種々のデータを見れば明らかである。

今年8月に総務省が発表した「情報通信白書」には、世代別の「テレビを見る」時間を過去と比較したデータがある。若い世代のテレビ離れは一目瞭然。10代では、2005年に1日平均106分だった視聴時間が、2010年には70分と、わずか5年で3割以上も減少している。同様に20代では、2005年に104分だったのが2010年には76分に激減。かつて「テレビの見過ぎだ」と大人たちから叱られていた日本の若者は、この5年で、自然と1日30分もテレビ視聴時間を減らすことに成功したわけだ。

ほかの世代を見ると、50代・60代ではテレビ視聴時間が微増しているが、全世代を通しても1日で4分の減少となっているから、若者の減少分をカバーできなくなっているのが現状である。

さらにNTTコミュニケーションズが2010年3月に発表したテレビ視聴の実態に関するアンケート調査では、20代以下で「ほとんどテレビを見ない」層が14.7%もいるという驚愕のデータが明らかになっている。

しかも同調査によれば、録画して時間のあるときに見る層も17.3%に過ぎず、携帯やワンセグで見る層にいたってはわずか0.5%しかいなかった。

つまり、録画やワンセグという言い訳は完全にウソで、若者たちは、テレビ番組そのものを見なくなっているのである。

※週刊ポスト2011年11月11日号

 

[ Google TV , Apple TV 그리고 TV의 미래 ]

Where Netflix wants to go next: India, Korea, Japan?

Where Netflix wants to go next: India, Korea, Japan?

By Nov. 2, 2011, 3:50pm PT 1 Comment
  • Netflix recently announced that it has put its international expansion on hold until global profitability returns, but that doesn’t mean the company isn’t already making plans for additional markets.

A recent job ad searched for language specialists fluent in a dozen additional languages to localize the Netflix service. The ad, which has since been taken down, read in part:

“We are looking for experienced linguists with the ability to translate and customize marketing, UI and content materials for the target market. We are looking for highly motivated individuals with the right mix of technical, organizational and communication skills to provide localization for the Netflix experience in the following languages: Turkish, Dutch, Russian, French, Hindi, German, Italian, Danish, Korean, Finnish, Japanese, and Spanish.”

Netflix first crossed the U.S. border when it expanded to Canada in September of 2010, and then surprised everyone with a massive expansion to 43 countries across Latin America and the Carribean in July. Most recently, the company announced that it will open shop in the U.K. and Ireland in early 2012, and a Variety report hinted at an expansion to Spain in 2012as well.

This kind of aggressive international expansion doesn’t come cheap: Netflix announced in conjunction with its most recent quarterly earnings that it expects to lose between $60 million and $70 million in foreign markets during the current quarter, and CEO Reed Hastings said during the Q3 earnings call that any further expansion is put on hold until the company returns to global profitability, which could take “some number of quarters.”

So Netflix won’t come to Korea, or any of the other countries mentioned, in the next few months. However, one shouldn’t assume that the company stands by idle, watching revenue numbers without preparing any further international roll-out. Of course, Netflix also wouldn’t want to tell the world where exactly it is gonna go next, which is why we should assume that some of those languages mentioned were simply thrown in the mix to confuse competitors.

Still, it’s worth looking at the list, if only to evaluate what would make the most sense for Netflix. I have to say I see three likely scenarios:

  • Russia and India: Netflix could further expand to emerging markets, which would be a similar long term bet as their launch in Latin America.
  • France, the Netherlands, Germany, Italy, Finland, Denmark, Spain and Turkey: Targeting continental Europe could be harder and more costly for Netflix, but also possibly bring some short-term rewards as the Internet infrastructure in most of those countries is en par, if not better than in the U.S., and household income isn’t far behind. This would essentially be a logical follow-up to its U.K. and Ireland plans.
  • Japan and Korea: Asia might be even more interesting to Netflix; Hulu of course recently launched in Japan, but I have a hunch that Korea would be an even better fit. The country has some of the home fastest Internet connections in the world, and people are already used to cloud media, thanks to countless Webhard-style offerings. Also, Netflix has seen a huge influx of Korean content in recent months, which would be essential to target the local market.

In the end, we’ll have to wait and see until Netflix makes some money again to figure out which of those countries it has had on the top of its list. A Netflix spokesperson told me that the company doesn’t discuss recruitment issues when asked about the job offer.

 

방송에도 손 뻗치는 구글

방송에도 손 뻗치는 구글
유튜브서 서비스… 온라인 채널 100개 열기로
인터넷 공룡 구글이 방송영역으로까지 손을 뻗치고 있다. 자회사 유튜브를 통해 방송서비스를 시작한다는 계획인데, 장기적으론 방송시장에 대지각 변동이 올 수도 있다는 평가다.

31일 월스트리트저널에 따르면 유튜브는 가수 마돈나, 농구스타 샤킬 오닐 등 유명인사와 손잡고 온라인 채널 100여 개를 개설, 프로그램을 내보 낼 예정이다. 할리우드 제작사, 미디어 회사 등 76개 회사가 유튜브에 채널을 개설하고 하루 25시간 분량의 프로그램을 제공하는 방식이다. 구글은 제작사와 유튜브광고수익을 나누고, 제작비를 일부 지원하는 방안을 제안한 것으로 알려졌다.

이에 따라 시청자들은 통상 케이블방송 채널에서 보던 패션, 뷰티, 요리, 스포츠, 음악, 건강 등 19개 분야의 프로그램을 유튜브 채널을 아무 때나 접할 수 있게 된다. 프로그램은 각 분야 전문가가 직접 프로그램을 진행하게 되는데 예컨대 댄스 채널은 마돈나가, 스포츠 채널은 스케이트보드 선수 토니 호크가 맡는 식이다. 이 밖에 배우 애쉬튼 커처, 가수 제이지, 할리우드 배우들의 트레이너 질리언 마이클스, 대체의학 권위자 디팍초프라 등도 대거 구글 방송에 참여한다.

구글은 유튜브를 종래의 동영상공유 사이트에서 사실상 방송프로그램 채널로 바꿔나간다는 구상. 구글 관계자는 “처음에는 네티즌들이 제작한 영상이 주요 콘텐츠였지만 방송 채널로서도 영향력을 충분히 가질 수 있을 것으로 보고 동영상 제공이라는 특성을 더욱 강화했다”고 설명했다.

구글은 유튜브상의 채널들이 양질의 콘텐츠를 제공하는지 관리 감독하는 역할을 하게 된다. 유튜브에 새롭게 생기는 100여개의 채널은 올 가을부터 내년 중순까지 순차적으로 출범될 예정이다.

케이블 방송사를 비롯 텔레비전 네트워크 업계에서는 구글의 행보 탓에 바짝 긴장하고 있다. 인터넷에서 모바일까지 사업 영역을 무한대로 확장하고 있는 구글이 방송시장 판도를 완전히 바꿔놓을 수도 있다는 것. 업계 관계자는 “기존 아마추어 동영상을 제공할 때도 네티즌의 관심을 모았는데 전문 콘텐츠를 실시간으로 내보낸다면 방송시장의 지각변동은 불가피 할 것”이라면서 “구글의 견고한 방문자수는 방송 흥행의 보증수표나 다름없다”고 설명했다.

더구나 구글은 콘텐츠 제작사들에게 광고수익 55%를 지급하기로 한 상태. 또 막강한 자금력을 바탕으로 이미 약 1억 달러에 달하는 비용을 제작자들에게 콘텐츠 제작비용으로 사전 지급한 것으로 알려졌다. 이렇게 되면 콘텐츠 제작자들도 케이블을 떠나 구글 쪽으로 쏠려, 결국 구글은 양질의 콘텐츠까지 확보하게 될 것이란 전망이다.

 

[IAP] AVFoundation을 사용한 플레이어에서 Volume조정하기

MPMoviePlayer를 사용하는 경우엔 MPVolumeView를 사용하면 된다고 쳐도,
AVPlayer를 사용하는 경우는 이게 안될수 있습니다. AVPlayer에 volume속성이 있으나 사용하기엔 좋지않고..
그래서 다음과 같은 방법으로 일단 해결은 했습니다.

NSTimer객체를 생성한후, updateVolume함수를 정의해줍니다.
MPVolumeView는 AVFoundation의 AVPlayer에서는 작동하지않을수 있습니다. 그렇기 때문에 AVAsset을 사용해서, AudioMix를 제어해서
player의 playerItem의 AudioMix에 대입해주는 방식으로 해결했습니다.

iOS개발시 탈옥(JailBreak)여부 확인하는 방법

여러 방법들이 나와있지만, iOS 4.2이상부터는 public API가 사라지는 바람에
꽁수를 사용해서 체크하는 수밖에 없습니다.

일단 StackOverFlow에서 찾아낸 1번째 방법!

결론… 안됩니다..
탈옥을 해도.. Normal이 찍히더군요..

그래서 2번째 방법!!

요건 되네요~
탈옥을 하면서 원래는 접슥할수 없는 /Applications 폴더에 접근이 가능해지기 때문인것 같습니다.
Cydia가 설치되어있지 않으면.. 확인이 안되겠죠?? 하지만 탈옥하면 시디아앱은 모.. 필수니까요

일단 이렇게 탈옥여부를 확인해서 이를 토대로 로직을 태우려고 합니다.
뭔가 정상적이지 않은 방법같아서 찝찝하네요..;;
다른 방법 찾으면 또 포스팅하겠습니다.

[AIP-dev] QueryString으로 SNS 공유하기

안녕하세요 마린즈입니다.

오랜만에 포스팅하네요. ^^

이번에는 아주 간단하게 URL호출만으로 SNS(트위터,미투데이,요즘),카카오톡에 공유하는 방법에 대해 적어볼까합니다.
Webview를 이용해서 NSURL에 값을 넘겨서 공유하는 방법입니다. 실제로 Auth부분부터 전부다 구현하기에는 시간적으로나, 기술적으로나 문제가 될경우가 많이 있죠.

1. Twitter

작은따옴표를 쓸수 없는 문제로 ” 문자를 URLEncoding해서 %22 로 Appending해줍니다.
트위터의 경우는 “http://twitter.com/intent/tweet?” 뒤에 공유하고픈 String을 적어주면 간단하게 됩니다.
링크걸 URL도 자동으로 ShotenLink로 대체해줍니다.

2. Me2day

미투데이의 경우도 트위터와 유사(http://me2day.net/plugins/mobile_post/new? 뒤에 스트링전달)합니다만, 미투데이 고유의 링크거는 방법이 있습니다.
텍스트:”링크주소” 와 같이 입력해주면 해당 텍스트에 하이퍼링크가 걸립니다. 그래서 같이 넘겨줘야할 String형태도 저 방식으로 변경을 해야되며,
트위터처럼 링크주소를 별도로 줄수는 있겠지만, 미투데이의 문화가 그렇지 않기때문에 지양해야할 방법이긴하죠.
문제는 텍스트에 링크를 주고나면 그 뒤로는 추가로 텍스트를 입력할수 없다는 것입니다.

3. Yozm

요즘도 “http://m.yozm.daum.net/user/message/post?” 뒤에 String값을 전달하는 방식입니다.
prefix=”본문텍스트”&link=”URL주소” 이렇게 값을 넘기면 되죠. 간단합니다.

4. KakaoTalk

카카오톡의 경우, http://www.kakao.com/link/api 이곳에서 카카오에서 제공하는 SDK를 다운로드 받으실수 있습니다.
사용방법은 위에 적은것처럼 아주 간단합니다.