조영규의 블로그

Android Support Library란?

youngkyu.cho — Thu, 2 Jun 2016 02:28:31 +0900

~~Edit~~

티스토리 android 안드로이드 support library 서포트 라이브러리

Android Support Library란?

안드로이드 Support 라이브러리는 프레임워크가 제공하지 않는 기능들을 제공한다. 본 라이브러리는 새 기능의 하휘 호환을 제공하며, 유용한 UI 엘리먼트들과 앱을 위한 다양한 유틸리티를 제공한다.

개괄

한 기능은 많은 경우 다른 많은 앱 개발자들에게도 중요한 경우가 많은데, 안드로이드 프레임워크는 이런 것들을 제대로 포함하고 있지 않다. 예를들어 자연스러운 안드로이드 버전별 대응 같은 것들이 바로 그것이다.

이를 위해 안드로이드 SDK는 다양한 라이브러리들을 포함하고 있다. 그것이 바로 Android Support Library다. 앱 개발자들은 해당 기능들이 필요할 때 이런 라이브러리를 추가할 수 있다.

Support 라이브러리가 제공하는 특징적인 기능이다.

하위호환성
UI 엘리먼트의 구현에서 안드로이드가 추천하는 레이아웃 패턴 사용
다른 form factor들에 대한 지원
다양한 유틸리티 함수

하위 호환성이란?

Support 라이브러리는 옛날 버전의 안드로이드 플랫폼을 최신 버전처럼 잘 지원할 수 있게 한다. 예를들어 앱이 5.0 버전(API level 21)보다 낮은 API 레벨에서 돌 때, 원래는 material 디자인이 아니지만 만약 앱이 support 라이브러리의 appcompat library를 쓴다면, 앱은 API 레벨 21이 제공하는 많은 기능들을 쓸 수 있을 뿐만 아니라, material 디자인으로 표현될 수 있다. 그 결과 앱은 좀 더 일관적인 경험을 플랫폼 버전을 뛰어넘으며 제공할 수 있다.

support라이브러리는 최대한 프레임워크에 의존해 동작하려 노력한다. 그러나 상황이 여의치않은 낮은 API 레벨에서는 스스로 동작하여 해당 동작을 수행한다. 일반적으로 ...Compat으로 끝나는 친구들이 이런 역할을 하는 친구들이다. 예를들어 ActivityCompat같은.

어떤 경우에는 support라이브러리가 어떠한 프레임워크 API 도움 없이 스스로 동작하는 경우도 있다. 이런 메소드는 모든 지원하는 플렛폼에서 일관되게 작동한다.

어떤 경우든, 앱은 런타임 때 시스템의 버전을 체크할 필요가 없다. 앱은 support라이브러리에 의존하면 되며, 알아서 시스템 상태를 체크해 동작해 줄 것이다.

아래 그림을 보면, 안드로이드 4.4에서 동작하는 화면이다. 원래 안드로이드 4.4는 material 디자인을 지원하지 않지만, support library UI 엘리먼트가 만들어 준다.

일반적인 레이아웃 패턴의 지원

support 라이브러리는 안드로이드 프레임워크가 지원하지 않는 사용자 인터페이스를 지원한다. 예를들면 DrawerLayout같은 것이 그것이다. 이러한 클레스들은 안드로이드 디자인 practice들에서 권장되는 것을 따른다.

이러한 support라이브러리가 지원하는 것들의 사용으로 인해 바퀴를 또 발명하는 일 따위를 안해도 된다! 까다로운 UI가 필요하다면, 당신은 이미 있는, 사용자가 친숙한 UI 인터페이스를 제공하는 support 라이브러리의 코드를 사용해 제작하면 된다. 예를 들어 많은 앱들이 엄청난 리스트를 빠르고 효과적으로 엘리먼트를 재사용하며 보여주길 원하는데, 이를 위해 support라이브러리는 RecyclerView를 제공한다!

다른 Form Factor들에 대한 지원

안드로이드 SDK는 TV나 웨어러블 같은 다른 form factor도 지원한다. 앱은 컨텐츠를 외부 스크린에 제공한다거나, 혹은 스피커에 제공한다거나, 혹은 다른 디바이스에 전송하는 등의 기능등을 적절한 support 라이브러리를 이용해 넓은 범위의 안드로이드 시스템을 커버할 수 있다.

유용한 유틸리티의 제공

안드로이드 support라이브러리는 하위 호환성을 가진 유틸리티들을 제공한다. 앱들은 적절한 사용자 경험을 제공하는 이러한 유틸리티를 모든 안드로이드 시스템에서 사용할 수 있다. 예를들어 support 라이브러리는 퍼미션 메소드들은 어떤 플랫폼 버전인지에 맞춰 적절하게 동작한다. 만약 플랫폼이 Runtime Permission Model을 지원한다면, 이러한 메소드들은 적절한 퍼미션을 유저에게 요청할 것이며, 그게 아닌 경우, 메소드는 적절한 퍼미션을 install time에 체크해 grant할 것이다.

[번역] FLUX 페이스북 클라이언트 사이드 웹 애플리케이션 아키텍처

youngkyu.cho — Wed, 1 Jun 2016 02:28:48 +0900

~~Edit~~

티스토리 FLUX javascript js facebook

Flux

Flux는 페이스북의 클라이언트 사이드 웹 애플리케이션 구축을 위한 아키텍쳐다. 이것은 한 방향으로의 데이터 흐름을 이용하여 React의 composable view 컴포넌트를 보완한다. 이것은 좀 더 큰 컨셉의 패턴이지, 공식적은 프레임워크는 아니다. 그리고 당신은 Flux를 새로운 코드 없이 바로 시작할 수 있다.

개괄

Flux 애플리케이션들은 3가지 주요한 파트로 구성된다. Dispatcher, Store, 그리고 View들(React 컴포넌트)이 그것이다. 이것들과 Model-View-Controller를 헷갈리지 말아야 한다. Controller는 Flux애플리케이션에도 존재하지만, Controller-View의 형태로만 존재한다. View들은 데이터를 Store에서 받거나, 그들의 자식 Store에게 데이터를 패스하기 위해 최상위 계급에 자주 위치한다. 게다가 Action Creator - Dispatcher의 헬퍼 메소드들 - 는 애플리케이션에서 가능한 모든 변화들을 묘사하기 위해 시멘틱한 API를 지원한다. Flux의 업데이트 사이클의 4가지 파트로서 이것들을 이해하면 상당히 편하다.

Flux는 MVC에서 양방햔 바인딩을 피한다. 유저가 React뷰와 인터렉션할 때, 뷰는 중심의 디스패처를 통하여 애플리케이션의 데이터와 비즈니스 로직 - 영향을 받은 모든 뷰들을 업데이트 하는 - 을 수행하는 다양한 스토어들에 로 Action을 전파한다.

이러한 작업들은 State 사이에서 어떻게 뷰들이 변할지 구체적으로 특정하지 않아도 스토어에게 업데이트들을 보낼 수 있도록 하는 특히 React의 Declarative 프로그래밍 스타일에서 유용하다.

우리는 파생된 데이터를 정확히 다루기 위해서 원래 시작했다. 예를들어 우리는 톡방들에서 아직 읽지 않은 것들의 숫자들을 읽지 않은 톡방이 하이라이트 되면서 톡방의 리스트와 함께 보여주길 바랐다. 한 톡방을 읽었다고 업데이트하면서, 동시에 읽지 않았다는 숫자를 동시에 업데이트 하는 것같은, 이런 일들은 MVC모델로는 다루기가 매우 힘들다. 의존적이고 폭포수처럼 전파되는 업데이트들은 MVC 아키텍쳐를 이용하는 큰 애플리케이션에서 자주 발생한다. 그리고 복잡한 데이터 흐름으로 예상치 못한 결과들을 초래한다.

제어권은 Store에게 역전된다. 스토어들은 업데이트를 받아들이고, 그들의 일관적인 방법으로 데이터를 업데이트 하게되는 외부적인 무언가에 의존하기보다, 그들을 적절하게 조정한다. 어떠한 외부 스토어들도 그 도메인을 위한 데이터들이 어떻게 관리되는지에 대해 전혀 이해하고 있지 않다. 이는 쓸데없는 걱정거리를 만들지 않는다. 스토어들은 어떤 다이렉트 Setter 메소드도 들고있지 않다. 예를 들어 setAsRead()같은. 그러나 대신 새로운 데이터를 그들 속의 세계로 가져오는 한가지 방법만이 존재한다. - 바로 callback이다. Dispatcher로 그들이 등록한.

스트럭쳐와 데이터 흐름

Flux의 데이터들은 한 방향으로만 흐른다.

단방향 데이터 흐름은 Flux 패턴의 중심이다. 그리고 위 다이어그램은 Flux 프로그래머에게 주요 맨탈 모델이어야 한다. 디스패처, 스토어, 뷰들은 명확한 인풋과 아웃풋이 있는 서로 독립적인 노드들이다. Action들은 간단한 오브젝트로, 새로운 데이터를 가지고 있고 어떤 타입의 프로퍼티인지에 대한 정보를 제공한다.

뷰들은 유저의 인터렉션들에 대한 반응과 관련된 새로운 Action을 생성할 것이다. 그리고 이러한 액션들은 시스템에 의해 전파된다.

모든 데이터는 중심 허브로서 Dispatcher를 통해 흐른다. Action은 Action creator 메소드 안에서 디스패처에게 제공된다. 그리고 더 자주는 뷰에서의 유저 인터렉션을 통해 대부분 생성될 것이다.

디스패처는 스토어들이 이미 dispatcher에게 등록했던, 모든 스토어들의 액션들을 스토어들에 전달하고 callback을 호출한다. 스토어 그들이 유지하는 스테이트들과 관련된 어떤 액션이든 등록된 컬벡 내에서 스토어들은 응답하게 된다. 스토어들은 그 후, 데이터 레이어의 변화를 Controller-Views들에게 알리기 위해 change 이벤트를 방출(emit)한다. Controller-View는 이러한 이벤트들을 리스닝하고 있다가 방출이 되면 이벤트 핸들러를 통해 스토어에서 데이터를 가져온다. 컨트롤 뷰는 그들 자신의 setState() 메소드를 스스로를 리렌더하고, 또 컴포넌트 트리의 후손들을 리렌더 하기위해 호출한다.

이 구조는 우리에게 한가지 방법으로 쉽게 애플리케이션을 추론할 수 있도록 한다. functional reactive programming, 혹은 더 구체적으로 data-flow programming 혹은 flow-based programming을 을 연상시키는 방법을 이용해서. 이 방법들에서는 애플리케이션의 데이터 플로우들은 한 뱡향으로 흐른다. 두 방향 바인딩은 없다.
애플리케이션 내의 특정 파트는 하나의 스토어에 의해 매우 decoupled된 채로 상태(state)가 유지된다. 동기적으로 업데이트가 디스패처에 의해 관리되면서, 스토어들의 의존성이 있는 곳에서는 엄격한 계급 체계을 유지한다.

우리는 두 방향의 데이터 바인딩이 한가지 오브젝트의 변화가 다른 오브젝트의 변화를 일으키는 캐스케이딩 업데이트를 발생시킨다는 것을 알았다. 그 뿐만 아니라 그 변화 또한 더 많은 업데이트들을 트리거 할 수 있다. 애플리케이션이 커지면서 이런 케스케이딩 업데이트들은 유저 인터렉션의 결과로서 무엇이 바뀌어 져야 하는지에 대한 결과물에 대한 예측하기 힘들게 한다. 업데이트가 하나의 라운드안에서 데이터를 변경할 때, 시스템은 전체로서 예측가능해진다.

다양한 Flux의 파트를 자세히 보자. 디스패처는 시작으로서 가장 적절한 선택이다.

하나의 Dispatcher

Flux 애플리케이션에서 모든 데이터 플로우를 관리하는 디스패처는 중앙 허브다. 기본적으로 디스패처는 스토어들의 안속의 callback들의 저장소(레지스트리)로 그 스스로는 어떠한 실질적 지능도 없다. 그것은 액션을 스토어로 분배하는 간단한 기계장치다. 각 스토어들은 dispatcher에 그들 스스로 뿐만 아니라 callback도 등록한다. Action creator가 디스패처에게 새로운 액션을 제공할 때, 애플리케이션 내 모든 스토어들은 저장소(레지스트리)안에있는 callbakc들을 통해 액션을 받는다.

애플리케이션의 성장에 따라, 디스패처는 좀 더 활성화된다. 이때 스토어들 사이에서 특정한 순서대로 등록된 callback을 호출해 주어 의존성을 관리하는데 사용될 수도 있다. 스토어는 선언적으로 기다릴 수 있다. 다른 스토어들이 업데이트를 완료하기까지. 그리고 나서 그들 스스로를 그에맞춰 업데이트한다.

페이스북이 프로덕션에서 사용하는 디스패처는 npm, Bower, or GitHub에서 이용할 수 있다.

스토어(Stores)

스토어는 애플리케이션의 스테이트와 로직을 가지고 있다. 그들의 역활은 뭔가 비슷한데, MVC에서의 모델이 그것이다. 그러나 그들은 다양한 오브젝트의 상태(state)를 관리한다. 그들은 ORM 모델이 하듯 하나의 단순한 레코드로 표현될 수 없다. Backbone의 콜렉션과도 마찬가지로 다르다. 간단히 ORM 스타일의 오브젝트를 관리하는 것 그 이상이다. 스토어는 특별한 도메인(책임영역)을 위한 애플리케이션의 상태(state)를 관리한다.

예를 들어보자. 페이스북의 Lookback Video Editor는 계속 재생시간의 위치와 재생 상태를 트래킹하는 TimeStore를 사용한다. 한편, 같은 애플리케이션의 ImageStore는 계속 이미지들의 컬렉션을 트래킹한다. 우리 TodoMVC Example에 있는 TodoStore도 비슷한데 todo 아이템의 컬렉션을 다룬다. 스토어는 2가지 특성을 보인다. 하나는 모델들의 컬렉션이고 또 다른 하나는 논리적인 도메인의 싱글톤 모델이다.

위에도 이야기했듯, 스토어는 그들 스스로를 디스패처에게 callback과 함께 직접 등록한다. 이 callback은 액션을 파래머터로 받는다. 스토어가 등록한 콜벡 안에서, 액션타입에 기반한 switch문은 액션을 번역하는데 사용될 뿐만 아니라 스토어 내부의 메소드들에게 적절한 훅(hook)을 제공하는데 사용된다. 이것은 액션이 디스패처를 통해 스토어의 상태 업데이트를 가능하도록 한다. 스토어가 업데이트 된 후, 그들은 스테이트가 바뀌었다는 이벤트를 내뿜는데, 이를 통해 뷰들은 새로운 상태를 질의할 수 있고, 그들 스스로를 업데이트 한다.

뷰(Views)와 Controller-Views

우리가 뷰레이어에서 필요로 하는 구성 가능한 종류의, 그리고 자유롭게 미리 랜더할 수 있는 뷰들을 React는 제공한다. 얽혀있는 뷰 계급의 최상단을 가까이에서 보면, 어떤 뷰가 의존하는 스토어가 브로드캐스트하는 이벤트들을 리스닝하는 특별한 뷰들이 존재한다. 우리는 이걸 컨트롤 뷰라고 부른다. 그들은 데이터를 스토어에서 가져오거나 혹은 그들의 후손들에게 데이터를 내려주는일을 위한 접착 코드를 제공한다. 우리는 이런 컨트롤 뷰들에게 중요한 섹션 하나를 할당해 주어야 할 것 같다.

이벤트를 스토어에서 받았을 때, 스토어의 public getter 메소드들로 필요한 새 데이터를 먼저 요청한다. 이후 자신의 setState()혹은 forceUpdate()메소드(그것의 render()메소드와 하부 자손들의 render() 메소드들을 실행하는)들을 호출한다.
우리는 자주 스토어의 전체 상태(state)를 뷰들의 체인이 있는 하부로 전달한다. 이것은 다른 후손들이 그들이 필요로 하는 것을 사용할 수 있도록 허락한다. 게다가 가장 최상위에서도 컨트롤러 비슷한 행동을 유지하기, 또 이렇게 우리의 자손 뷰들을 유지하기 위해, 가능한한 기능적으로 퓨어하게 모든 스토어의 상태를 싱글 오브젝트로 하부에 전달하는 것은 우리가 관리해야할 프로퍼티들의 수를 줄여주는 효과가 있다.

가끔, 우리는 안쪽(최상위가 아닌) 컨트롤 뷰를 컴포넌트를 간단히 유지하기 위해 가끔 추가할 필요를 느낀다. 이것은 특정 도메인의 섹션의 계층을 더 낫게 캡슐화 할 수 있게 해주기도 한다. 그러나 안쪽의 컨트롤러뷰는 하나의 데이터 흐름을 깰 수도 있다는 점을 알아야한다. 이런 컨트롤 뷰는 새로운 데이터 흐름을 위한 엔트리 포인트를 만들 수 있으며, 이는 잠재적인 충돌 가능성을 가지고 있다. 안쪽의 컨트롤 뷰를 만들 때는 간단한 컴포넌트의 이점과 복잡한 다수의 업데이트 사이에서 조율을 해야한다. 이러한 다수의 데이터 업데이트는 의도치 않은 영향을 만들 수 있는데, 다른 컨트롤뷰에 의해 계속적으로 호출되는 React의 렌더링 메소드의 getting에서 그렇다. 그리고 이건 잠재적으로 디버깅의 어려움을 증가시킬 수 있다.

액션(Actions)

우리가 스토어에게 분배(dispatch)를 트리거할 수 있도록, 그리고 데이터 페이로드 - 이것이 우리가 부르는 액션 - 를 포함 할 수 있게 디스패처는 한 메소드를 노출시킨다. 시멘틱한 헬퍼 메소드 안에, 엑션의 생성은 아마 래핑되어있을 것이다. 그것은 액션을 디스패처에게 보낸다. 예를들어, 우리는 To-do 아이템의 글자를 To-do List 애플리케이션에서 바꾸길 원할 수 있다. 우리는 TodoActions 모듈 안에 updateText(todoId, newText)같은 함수로 액션을 생성한다. 이 메소드들은 아마 우리의 뷰 이벤트 핸들러에 의해 호출될 것이다. 우리는 이것을 유저 인터렉션의 결과라 부를 수 있다. 이 액션 생성 메소드는 또한 액션에게 타입을 추가한다. 그래서 액션이 스토어에서 해셕될 때, 적절하게 응답할 수 있도록 한다. 우리의 예시에서는 이런 타입은 아마 TODO_UPDATE_TEXT같이 이름 붙여질 것이다.

액션은 아마 다른 장소들에서 올때도 있다, 서버같은 곳에서. 예를들어, 데이터를 초기화하는 동안 이런일이 일어난다. 또 마찬가지로 서버가 에러코드를 반환할때나 혹은 애플리케이션을 업데이트할때 같을때도 일어난다.

디스패처를 좀 더 보면,

아까 얘기했지만, 디스패처는 스토어들 사이의 디펜던시도 관리가 가능하다. 이런 기능은 디스패처 클래스의 waitFor() 메소드를 통해 가능하다. 우리는 지금 이런 메소드를 쓸 필요가 없다. 왜냐면 TodoMVC 애플리케이션이 굉장히 단순하니까. 그러나 이것은 크고 복잡한 애플리케이션에선 활성화될 것이다.

TodoStore의 등록된 콜벡 안에서 우리는 명시적으로 진행전에 다른 디펜던시들이 먼저 업데이트 되도록 기다릴 수 있다.

case 'TODO_CREATE':
  Dispatcher.waitFor([
    PrependedTextStore.dispatchToken,
    YetAnotherStore.dispatchToken
  ]);

  TodoStore.create(PrependedTextStore.getText() + ' ' + action.text);
  break;

waitFor()은 한가지 argument만 받는다. 그 argument는 디스패처의 콜백 저장소(레지스트리) 인덱스다. 이것을 우리는 dispatch tokens이라 부른다. 이와같이 waitFor()를 호출하는 스토어는 그것이 그 자신의 스테이트를 어떻게 업데이트 해야하는지 알려주기 위한 다른 스토어의 상태에 의존할 수 있다.

디스패처 토큰은 디스패처에 콜벡을 등록할 때 register()의 반환값이다.

PrependedTextStore.dispatchToken = Dispatcher.register(function (payload) {
  // ...
});

waitFor()이나 actions, action creators 그리고 디스패처에 대해 더 자세한걸 원하면 Flux: Actions and the Dispatcher 를 보자.

안드로이드 엑티비티란?

youngkyu.cho — Wed, 1 Jun 2016 02:25:03 +0900

~~Edit~~

티스토리 안드로이드 android

안드로이드 엑티비티란?

들어가기 전에.

모든 내용은 개인적인 안드로이드 학습을 위해 정리 것이다. 공식 홈페이지인 이곳 안드로이드 디벨로퍼 페이지를 참고했으며, 개인적으로 약간의 번역과 의역을 붙여 이해한 내용을 풀어적었다. 혹시 처음 시작하는 누군가에게 도움이 될지 몰라 올린다. 잘못된 것이 있다면 알려주기 바란다.

액티비티란?

Activities
An activity is one of the distinguishing features of the Android framework. Activities provide the user with access to your app, and there may be many activities. An application will usually have a main activity for when the user launches the application, another activity for when she selects some content to view, for example, and other activities for when she performs other tasks within the app. See Activities for more information.

안드로이드 프레임워크가 제공하는 엑티비티는 사용자가 앱에 접근할 수 있도록 하며, 다양한 활동(작업)을 할 수 있도록 하는 일종의 페이지입니다.

액티비티 시작하기

main()으로 시작하는 다른 프로그래밍 패러다임과는 다르게 안드로이드는 안드로이드 프레임워크를가Avtivity 인스턴스들(안드로이드의 )의 라이프사이클을 관리합니다. 각 라이프사이클 stage가 바뀌는 매 순간마다, 해당 시점에 대응되는 Callback 메소드를 실행합니다.

엑티비티는 라이프 타임 동안에 각 스테이지가 순차적으로 진행됩니다. 즉 각 메소드(콜백)을 순차적으로 실행하게 됩니다. 각각의 콜백 메소드가 끝난 후 액티비티의 상태는 한단계 올라갑니다. 마치 피라미드처럼. 피라미드의 최상층은 엑티비티가 전면에서 실행중이며 사용자가 상호작용할 수 있는 상태를 뜻합니다.

액티비티를 사용자가 종료하게 되면 액티비티는 하향이동하는 다른 메소드를 호출합니다. 사용자가 앱을 전환하는 경우 완전히 하향하지않고 기다리기도 합니다. 이런 경우 다시 최상층으로 올라갈 수도 있습니다.

엑티비티의 복잡한 정도에 따라 모든 라이프사이클 메소드를 구현할 필요가 없을 수도 있습니다. 각각의 라이프사이클을 이해하는 것은 사용자가 예상한대로 앱이 동작함을 보장하기 위해 중요합니다.

onCreate()가 호출된 후 바로 onStart()가, 그리고 즉시 onResume()이 호출됩니다.

onCreate()메소드에서 finish()를 호출하는 경우를 제외하고 onPause(), onStop()을 먼저 호출한 후에 onDestroy()를 호출합니다. 경우에 따라 onCreate()에서 finish()를 호출해야하는 경우가 있는데, 에깉비티가 다른 엑티비티를 실행하기 위한 용도일 경우가 바로 그것입니다. 이 경우 시스템은 onDestory()만을 호출합니다.

엑티비티의 일시정지와 재개

엑티비티가 일시 중지되는 경우가 있습니다. 엑티비티가 부분적으로 보이지만, 현재 포커스 되어있지 않다면 일시정지 상태입니다. 그러나 엑티비티가 완전히 사려지면, 정지상태가 됩니다.

엑티비티가 일시정지 상태가 되면 onPause()가 호출됩니다. 이런 엑티비티는 언제나 다시 포커스가 돌아올 수 있습니다. 그러나 이는 엑티비티를 떠날 것임을 이야기하는 첫번째 신호입니다. 만약 사용자가 다시 돌아온다면 onResume()이 호출되겠지요.

엑티비티는 onPause()뒤 곧 정지 상태로 전환될 확률이 높습니다. 따라서 CPU 소비를 하는 작업, 저장되지 않은 변경 내용의 커밋, 브로드 캐스트 리시버와 같은 시스템 리소스, 각종 센서, 배터리 수명에 영향을 미치는 혹은 사용자가 필요로 하지 않는 리소스에 대한 해지를 여기서 해주어야 합니다. 카메라를 사용하는 엑티비티라면, onPause()는 이를 해제할 수 있는 좋은 위치죠.

onPause()작업은 다음 엑티비티로 자연스럽게 넘어가기 위해 가볍게 유지합니다. 나머지 로드가 많은 셧다운 작업은 onStop()에서 수행합니다.

onResume()은 사용자가 일시정지된 엑티비티를 재개할 때 호출됩니다. 엑티비티가 전면에 표시될 때 마다 이 메소드는 호출됩니다. 따라서 onResume()때는 onPause() 타이밍에 릴리즈한 모든 리소스를 초기화하는 작업이 포함되어야 합니다.

참고로, onResume()과 onPause()는 보통 서로 짝을 이뤄 작동시킵니다. 한쪽은 리소스 얻기, 한쪽은 놓아주기.

엑티비티 정지 및 재시작

엑티비티를 제대로 정지하고 재시작하는 것은 중요한 프로세스입니다. 이런 프로세스가 완벽히 동작해야 앱이 항상 작동 상태를 유지하고 진행 상태를 잃지 않는다는 신뢰를 사용자에게 줄 수 있습니다. 다음과 같은 시나리오는 엑티비티가 정지되었다가 재시작되는 상황입니다.

사용자가 최근 앱 창을 열고 다른 엑티비티로 전환하면, 현재 전면에 있는 엑티비티는 정지됩니다. 사용자가 다시 앱창으로 돌아오면, 엑티비티는 재시작됩니다.
사용자가 앱에서 새 엑티비티를 시작합니다. 두번째 엑티비티가 생성되면, 현 엑티비티는 정지되고, 뒤로가기를 누르면 다시 재시작됩니다.
사용자가 앱을 이용하는 도중 전화가 걸려 옵니다.

onStop()과 onRestrat()는 정지와 재시작의 처리를 명확히 할 수 있는 메소드입니다. 부분적인 UI 차단은 onPause()가 호출되고, UI가 화면에 보이지 않으면 onStop()이 호출됨으로서 onStop()때 사용자의 포커스가 별도의 엑티비티(혹은 다른 앱)에 있음을 보장합니다. 이때 사용자가 사용하지 않는 거의 모든 리소스를 해제해야합니다.

엑티비티가 정지되고 나면, 시스템이 메모리를 회수 해야하는 경우, 해당 인스턴스를 소멸시킵니다. (원래는 소멸시키지 않습니다. 메모리에 보관해 둡니다.) 급한 경우 onDestroy()를 호출하지 않고 프로세스를 Kill할 수 있습니다. 따라서 onStop()타이밍에 메모리 누수를 야기할 수 있는 리소스는 반드시 해제해야합니다.

onPause()때 다 하지 못한 데이터베이스에 기록하는 작업, CPU 많이 사용하는 작업등은 onStop()타이밍에 합니다.

엑티비티가 정지되면, Activity 객체는 메모리에 계속 유지되고 있다가 재개때 다시 호출됩니다. 따라서 onResume()타이밍에 생성한 구성요소는 다시 초기화 할 필요가 없습니다. 뿐만 아니라 레이아웃에 있는 모든 View의 상태도 함께 메모리에 유지됩니다. 따라서 저장, 복원을 따로 해줄 필요가 없습니다.

엑티비티가 정지된 상태에서 다시 시작될 때 onRestart()가 호출됩니다. 이때 onStart()도 연달아 호출됩니다. 따라서 onRestart()때는 특수한 복원 작업을 수행하면 좋습니다.

onStop()때 리소스가 릴리즈 되었으나, 앱을 처음 킬 때 onStart()가 호출되며 초기화 했듯, onRestart()호출 때도 onStart()가 호출되며 다시 리소스를 가져 올 것입니다.따라서 따로 onRestart()때 따로 코드를 넣어주지 않아도 정상 작동합니다. 여기서 중요한 것은 onStop()과 onStart()가 서로 짝을 이뤄 사용되어야 한다는 것입니다. onStart()는 필요한 시스템 리소스, 기능이 제대로 구비되었는지 확인하는 가장 좋은 장소입니다.

엑티비티 재생성

정상적인 앱 동작으로도 엑티비티가 소멸되는 시나리오가 있습니다. 사용자가 뒤로를 누르거나, 엑티비티가 finish()를 호출하여 자체적으로 소멸 신호를 보내는 경우입니다. 이 경우, Activity는 완벽히 사라집니다.

엑티비티가 정지된 상태로 장시간 사용되지 않거나, 전면에 있는 엑티비티가 리소스가 더 필요해 시스템이 백그라운드 프로세스를 종료해 메모리를 회수하려는 경우에도 시스템이 엑티비티를 소멸시킬 수 있습니다. 이렇게 정상적인 앱 동작이 아닌, 시스템이 소멸시키는 경우 시스템은 Avtivity 인스턴스는 없애지만, 그것이 존재했었음은 기억합니다. 시스템이 이전 상태를 복원하기 위해 사용하는, 저장된 데이터를 인스턴스 상태(instance state)라 하며, 이는 Bundle객체에 저장된 키-값 쌍의 컬렉션 입니다.

참고로, 사용자가 화면을 회전할 때 마다 엑티비티는 소멸 후 재생성됩니다.

기본적으로 자동으로 시스템은 Bundle 인스턴스에 레이아웃 view들의 상태를 저장합니다. 따라서 별도 코드 없이도 자동으로 복원이 됩니다. ()단 이때 android:id 애트리뷰트 값은 반드시 있어야 합니다.) 그러나 추가적으로 코드로 데이터를 직접 저장하고 핸들링 하고 싶다면 아래의 두개의 메소드를 이용합니다.


static final String STATE_SCORE = "playerScore";
static final String STATE_LEVEL = "playerLevel";
...

@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
    // Save the user's current game state
    savedInstanceState.putInt(STATE_SCORE, mCurrentScore);
    savedInstanceState.putInt(STATE_LEVEL, mCurrentLevel);

    // Always call the superclass so it can save the view hierarchy state
    super.onSaveInstanceState(savedInstanceState);
}

onSaveInstanceState()를 이용해 엑티비티의 상태를 저장해 둘 수 있습니다. 이는 이후 onCreate() 타이밍, 혹은 그 바로 다음인 onRestoreInstanceState() 타이밍에 핸들링 할 수 있습니다. 단 onRestoreInstanceState()는 Bundle 객체가 있을 경우(복원할 저장 데이터가 있을 경우)에 만 실행됩니다.


@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState); // Always call the superclass first

    // Check whether we're recreating a previously destroyed instance
    if (savedInstanceState != null) {
        // Restore value of members from saved state
        mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
        mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
    } else {
        // Probably initialize members with default values for a new instance
    }
    ...
}

onCreate()때 핸들링 하기 위해서는 반드시 Bundle객체가 null인지 확인하여야 합니다. 그러나 이후 실행되는 onRestoreInstanceState()는 Bundle객체가 없으면 실행되지 않기에 null값에 대한 처리를 해주지 않아도 됩니다.

public void onRestoreInstanceState(Bundle savedInstanceState) {
    // Always call the superclass so it can restore the view hierarchy
    super.onRestoreInstanceState(savedInstanceState);

    // Restore state members from saved instance
    mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
    mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
}

안드로이드 Context 개념 익히기

youngkyu.cho — Wed, 1 Jun 2016 02:23:53 +0900

~~Edit~~

티스토리 android 안드로이드

안드로이드 Context 개념 익히기

Context is the Interface to global information about an application environment.
컨텍스트는 애플리케이션의 environment에 대한 전역 정보를 위한 인터페이스다.

안드로이드 개발이 꽤나 쉽지 않다는 걸 알았다. 그래서 해보고 싶었다. 아니 해야한다 생각했다. 온갖 버그가 안드로이드 SDK안부터 서드파티 라이브러리까지 존재할 뿐만 아니라 파편화 또한 아이폰과 비교도 안될만큼 심하다는 게 시제품을 만드는 안드로이드 개발자 옆을 지키며 내가 안드로이드 공부를 시작하게 된 이유다. 내가 조금이라도 일을 더 도와준다면, 조금 더 빨리 완성되지 않을까 해서. 조금이라도 도움이 되지 않을까 하는 마음에 공부하기로 했다. 예전 Servlet/JSP, Spring등을 다룰 때 JAVA를 했던 기억을 더듬어 가며(놀랍게도 벌써 그개 3년이나 됐다는 걸 알았다), 안드로이드 공부를 시작하려 한다.

안드로이드 개발자 뒤에서 항상 보던 getApplicationContext()라는 함수가 기억났다. 왜 안드로이드는 맨날 저걸 던져줘야 하는건가 라는 생각이 항상 들었지만 한번도 그 이유가 제대로 궁금한 적은 없었다. 그냥 귀찮은 처리가 많은 개발 플랫폼이구만 이라고 생각했을 뿐.

안드로이드의 Context 개념은 안드로이드 디벨로퍼에 따르면, 위와 같다. 현재 사용되고있는 앱에 대한 전역 환경 정보를 가진 친구라고 한다. 이게 무슨 뜬구름 잡는 소린가.

여기 스텍오버플로우 글에서 많은 인사이트를 얻었다.

getApplication(), getApplicationContext(), getBaseContext(), getContext(), 그리고 SomeClass.this 까지 이게 뭐가 다른지에 대한 질문이었다.

즉,

Toast.makeText(LoginActivity.this, "LogIn successful", Toast.LENGTH_SHORT).show();
Toast.makeText(getApplication(), "LogIn successful", Toast.LENGTH_SHORT).show();
Toast.makeText(getApplicationContext(), "LogIn successful", Toast.LENGTH_SHORT).show();
Toast.makeText(getBaseContext(), "LogIn successful", Toast.LENGTH_SHORT).show();

이 친구들과

Intent intent = new Intent(getApplicationContext(), LoginActivity.class);
Intent intent = new Intent(MenuPagina., LoginActivity.class);
Intent intent = new Intent(getBaseContext(), LoginActivity.class);
Intent intent = new Intent(getApplication(), LoginActivity.class);

이 친구들 각각이 뭐가 다른지에 대한 것을 궁금해 하는 듯 했다. 나 또한 안드로이드 생초보지만, 어깨 넘어로 본 게 있어서 뭐가 다른지 궁금했다.

안드로이드 프레임워크에서 Context는 2가지 종류로 나뉜다.

애플리케이션 Context
액티비티 Context

애플리케이션 Context는 애플리케이션 자체의 생명주기(라이프사이클)에 영향을 받는다. 따라서 항상 애플리케이션의 생명 주기와 함께 한다.
그러나 엑티비티 Context는 액티비티의 라이프사이클과 함께 작동해, onDestory()와 함께 사라진다. 즉 액티비티에 대한 환경 정보들이 Context에 있고, 이 Context(엑티비티의)에 Intent를 통해 다른 액티비티를 띄우면, 엑티비티 스택이 쌓이게 되는 것이다.

LoginActivity.this though its referring to your own class which extends Activity class but the base class (Activity) also extends Context class, so it can be used to offer activity context.
getApplication() though its referring to Application object but the Application class extends Context class, so it can be used to offer application context.
getApplicationContext() offers application context.
getBaseContext() offers activity context.

세부적인 설명인데, 여기서 중요한 것은 안드로이드의 Avtivity와 Apllication class들이 모두 Context클래스를 상속받아 만들어졌다는 것이다. 그래서 LoginActivity.this라고 하는 순간, this에 해당하는 LoginActivity인스턴스가 파라매터로 전달되고, 이것은 Context를 상속받았기에 Context이며, 따라서 아무런 문제 없이 작동하게 되는 것이다.

Tips: 뷰를 수정하거나 할때는 Activity Context를 나머지 경우에는 Application Context를 사용하라.

다음은 액티비티의 생명주기에 대해서 공부를 해보아야 겠다.

Redis(레디스)의 구현과 내부 구조, 작동 원리 - 1

youngkyu.cho — Sun, 23 Aug 2015 05:05:47 +0900

~~Edit~~

Redis(레디스)의 구현과 내부 구조, 작동 원리 - 1

새로운 프로젝트인 Haffle에서 레디스를 메인 데이터베이스로 사용하기로 결정했다. 꽤 도전적인 선택이고 내 기준에서는 약간의 기술적 도전이기도 하다. 어떻게 해야 레디스로 인스타그램처럼 잘 만들 수 있을까 고민하다가 코드를 한번 씹어먹어보기로 했다. 레디스의 여러 명령어를 사용하면서도 레디스의 구현에 대해서는 무지했는데, 이제부터 레디스에 대한 내부 구조와 세부 구현에 대해 소스 코드를 분석해 보고자 한다. 잘못된 내용이 있을시 알려주길 바란다!

레디스 3.XX 기준 소스코드이다.

레디스 객체

// redis.h

#define REDIS_LRU_BITS 24
#define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
#define REDIS_LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;

redis.h 에서 레디스가 저장된 데이터를 관리하기위해 사용하는 redisObject의 구조체 형식을 확인할 수 있다. 아니 사실 모든 레디스 운영을 위한 모든 변수도 이걸로 관리된다. redis.h에서 처음으로 나오는 구조체기도 하다. 레디스는 비트필드를 사용하여, type 구별(4비트)과 인코딩 타입 구별(4비트)을 위해, 그리고 LRU를 위한 시간 저장공간(24비트)을 사용하는데, 정말 아끼고 아껴 고작 저걸 다 합쳐서 32비트밖에 안사용한다. 레디스는 메모리에서 동작하고 메모리는 시스템 자원 중 매우 비싼편에 속한다. 이를 알고 최소한으로 사용하려는 노력이 돋보인다. (반성해야한다 나는.) 과거(2.6대)에는 2비트를 notUsed 필드로 남겨뒀는데 3.XX 버전대로 오면서 lru를 위해 할당한 듯 하다. refcount는 해당 객체가 참조당하는 횟수로 파악되고, ptr이 실제 데이터를 가리키는 용도로 사용되는 포인터로 보인다.

여기서 encoding은 무엇인가? type은 또 무엇인가?

레디스의 자료 구조(타입)과 인코딩

// redis.h

/* Object types */
#define REDIS_STRING 0 //스트링
#define REDIS_LIST 1 //리스트
#define REDIS_SET 2 //집합(셋)
#define REDIS_ZSET 3 //정렬된 리스트
#define REDIS_HASH 4 //해시테이블

#define REDIS_ENCODING_RAW 0     /* Raw representation */
#define REDIS_ENCODING_INT 1     /* Encoded as integer */
#define REDIS_ENCODING_HT 2      /* Encoded as hash table */
#define REDIS_ENCODING_ZIPMAP 3  /* Encoded as zipmap */
#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
#define REDIS_ENCODING_INTSET 6  /* Encoded as intset */
#define REDIS_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
#define REDIS_ENCODING_EMBSTR 8  /* Embedded sds string encoding */

redis.h의 179번째 줄 부터 시작하는 상수를 보자. redis는 4개의 비트로 아마 최대 16개의 자료구조 타입을 표현할 수 있을 것이다. 그리고 현재는 위의 5가지를 지원하는 듯 하다. 곧 위치 관련 구조도 지원한다는데, 이곳에 5번으로 추가되지 않을까.

레디스는 인코딩타입으로 현재 9가지를 지원한다.

RAW
INT
해시테이블
집맵(압축된 해시테이블)
연결리스트
집리스트(압축된 리스트)
INT형 변수만 있는 집합(셋)일 경우 사용되는 INTSET
SKIPLIST
EMBSTR

각각의 인코딩이 무엇인지는 정확히 모르겠지만, 어쨋든 이런 인코딩 타입을 지원하나보다. 데이터를 군더더기 없이 최소한의 공간만 사용해 저장하려는 노력의 일환인 듯 하다.

문자열 데이터 인코딩 따라가기

레디스는 문자열을 저장하기 위해 아래 2가지의 인코딩을 지원한다.

어떻게 동작하는지 살펴보자.

// redis.c

struct redisCommand redisCommandTable[] = {
    {"get",getCommand,2,"rF",0,NULL,1,1,1,0,0},
    {"set",setCommand,-3,"wm",0,NULL,1,1,1,0,0},
    // ... 중략 ... 
    {"pfselftest",pfselftestCommand,1,"r",0,NULL,0,0,0,0,0},
    {"pfadd",pfaddCommand,-2,"wmF",0,NULL,1,1,1,0,0},
    {"pfcount",pfcountCommand,-2,"r",0,NULL,1,-1,1,0,0},
    {"pfmerge",pfmergeCommand,-2,"wm",0,NULL,1,-1,1,0,0},
    {"pfdebug",pfdebugCommand,-3,"w",0,NULL,0,0,0,0,0},
    {"latency",latencyCommand,-2,"arslt",0,NULL,0,0,0,0,0}
};

redis.c에서 문자열 데이터를 저장하는 명령어인 get과 set이 호출됐을때 실행되는 함수를 확인할 수 있다. getCommand과 setCommand이 그것인데, 이 소스를 찾아보자. 먼저 setCommand가 궁금하다.

// t_string.c

static int checkStringLength(redisClient *c, long long size) {
    if (size > 512*1024*1024) {
        addReplyError(c,"string exceeds maximum allowed size (512MB)");
        return REDIS_ERR;
    }
    return REDIS_OK;
}

setCommand를 찾아 뜯어보니, 첫줄에 checkStringLength함수가 보인다. 512메가를 넘는 스트링인가를 검사하는데, redisClient포인터 까지 인자로 받는다. 레디스의 Command와 관련된 모든 함수는 redisClient를 참조한다. 이게 뭘까?

// redis.h

/* With multiplexing we need to take per-client state.
 * Clients are taken in a linked list. */
typedef struct redisClient {
    uint64_t id;            /* Client incremental unique ID. */
    int fd;
    redisDb *db;
    int dictid;
    robj *name;             /* As set by CLIENT SETNAME */
    sds querybuf;
    size_t querybuf_peak;   /* Recent (100ms or more) peak of querybuf size */
    int argc;
    robj **argv;
    struct redisCommand *cmd, *lastcmd;
    int reqtype;
    int multibulklen;       /* number of multi bulk arguments left to read */
    long bulklen;           /* length of bulk argument in multi bulk request */
    list *reply;
    unsigned long reply_bytes; /* Tot bytes of objects in reply list */
    int sentlen;            /* Amount of bytes already sent in the current
                               buffer or object being sent. */
    time_t ctime;           /* Client creation time */
    time_t lastinteraction; /* time of the last interaction, used for timeout */
    time_t obuf_soft_limit_reached_time;
    int flags;              /* REDIS_SLAVE | REDIS_MONITOR | REDIS_MULTI ... */
    int authenticated;      /* when requirepass is non-NULL */
    int replstate;          /* replication state if this is a slave */
    int repl_put_online_on_ack; /* Install slave write handler on ACK. */
    int repldbfd;           /* replication DB file descriptor */
    off_t repldboff;        /* replication DB file offset */
    off_t repldbsize;       /* replication DB file size */
    sds replpreamble;       /* replication DB preamble. */
    long long reploff;      /* replication offset if this is our master */
    long long repl_ack_off; /* replication ack offset, if this is a slave */
    long long repl_ack_time;/* replication ack time, if this is a slave */
    char replrunid[REDIS_RUN_ID_SIZE+1]; /* master run id if this is a master */
    int slave_listening_port; /* As configured with: SLAVECONF listening-port */
    multiState mstate;      /* MULTI/EXEC state */
    int btype;              /* Type of blocking op if REDIS_BLOCKED. */
    blockingState bpop;     /* blocking state */
    long long woff;         /* Last write global replication offset. */
    list *watched_keys;     /* Keys WATCHED for MULTI/EXEC CAS */
    dict *pubsub_channels;  /* channels a client is interested in (SUBSCRIBE) */
    list *pubsub_patterns;  /* patterns a client is interested in (SUBSCRIBE) */
    sds peerid;             /* Cached peer ID. */

    /* Response buffer */
    int bufpos;
    char buf[REDIS_REPLY_CHUNK_BYTES];
} redisClient;

레디스 클라이언트는 각각의 접속한 클라이언트의 상태를 저장하기 위해 사용하는 구조체였다. 이를 이용하여 명령들이나 블록상태, 혹은 pub/sub까지 관리하는 것으로 보인다. 주석을 보니 클라이언트들은 링크드리스트로 관리된다고 한다.

다시 본론으로 돌아와서, setCommand를 찾아보자.

// t_string.c

#define REDIS_SET_NO_FLAGS 0
#define REDIS_SET_NX (1<<0)     /* Set if key not exists. */    // 비트 : 01
#define REDIS_SET_XX (1<<1)     /* Set if key exists. */        // 비트 : 10

void setGenericCommand(redisClient *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    // ... 중략 ...
}

/* SET key value [NX] [XX] [EX <seconds>] [PX <milliseconds>] */
void setCommand(redisClient *c) {
    int j;
    robj *expire = NULL;
    int unit = UNIT_SECONDS;
    int flags = REDIS_SET_NO_FLAGS;

    for (j = 3; j < c->argc; j++) {
        char *a = c->argv[j]->ptr;
        robj *next = (j == c->argc-1) ? NULL : c->argv[j+1];

        if ((a[0] == 'n' || a[0] == 'N') &&
            (a[1] == 'x' || a[1] == 'X') && a[2] == '\0') {
            flags |= REDIS_SET_NX;
        } else if ((a[0] == 'x' || a[0] == 'X') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0') {
            flags |= REDIS_SET_XX;
        } else if ((a[0] == 'e' || a[0] == 'E') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' && next) {
            unit = UNIT_SECONDS;
            expire = next;
            j++;
        } else if ((a[0] == 'p' || a[0] == 'P') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' && next) {
            unit = UNIT_MILLISECONDS;
            expire = next;
            j++;
        } else {
            addReply(c,shared.syntaxerr);
            return;
        }
    }

    c->argv[2] = tryObjectEncoding(c->argv[2]); // 얘는 뭔가?
    setGenericCommand(c,flags,c->argv[1],c->argv[2],expire,unit,NULL,NULL);
}

setCommand를 알기 위해서는 setGenericCommand함수도 알아야 한다. 왜냐하면, 아래와 같은 이유다!

setGenericCommand() 함수는 SET 연산을 구현합니다. 이때, 각기다른 옵션과 약간의 변형된 형태도 처리합니다. 이 함수는 SET, SETEX, PSETEX, SETNX를 처리하기 위해 call됩니다.

쟤가 진짜 처리하는 애니까! 그래도 setCommand를 보기로 했으니 먼저 보자. 조금 있다가 setGenericCommand도 함께 보자.

char *a는 명령어 문자열이라 생각하자. NX인지 XX인지, EX인지, PX인지 확인하는 제어문인거 같다. 그냥 넘어가자. 그리고 나면 나오는 tryObjectEncoding이 함수가 무엇을 하는지 찾아야하는데, 찾아가보자.

tryObjectEncoding 함수에 대하여

// obejct.c

robj *tryObjectEncoding(robj *o) {
    long value;
    sds s = o->ptr;
    size_t len;

    redisAssertWithInfo(NULL,o,o->type == REDIS_STRING); // string 맞는지 확인.

    if (!sdsEncodedObject(o)) return o; // RAW나 EMBSTR 인코딩 된 애들이 아니면, 그냥 반환.

    if (o->refcount > 1) return o; // 혹시 이 string을 참조하는 애가 있는지 확인. 있으면 그냥 반환.

    /* 21자리가 넘는지 확인. 넘으면 INT일 수 없으니까.
     * 그리고 long으로 처리될 수 있는지, string2l 유틸 함수로 시도해봄.
     * 그리고 long으로 처리된 값을 value에 집어넣음. 처리 실패시 0(false)반환. */
    len = sdslen(s);
    if (len <= 21 && string2l(s,len,&value)) {
        if ((server.maxmemory == 0 ||
             (server.maxmemory_policy != REDIS_MAXMEMORY_VOLATILE_LRU &&
              server.maxmemory_policy != REDIS_MAXMEMORY_ALLKEYS_LRU)) &&
            value >= 0 &&
            value < REDIS_SHARED_INTEGERS) // 공유된 INTEGER 값으로 처리 가능한지 확인.
        { // 공유된 INTEGER값으로 처리 가능!
            decrRefCount(o); // 참조를 지우고, 메모리 할당 해제.
            incrRefCount(shared.integers[value]); // 공유된 INTEGER 값 ref count 증가.
            return shared.integers[value]; // 공유된 INTEGER 반환.
        } else { // 공유된 INTEGER론 불가능하지만 long으로 가능하다면,
            if (o->encoding == REDIS_ENCODING_RAW) sdsfree(o->ptr); // 메모리 해제
            o->encoding = REDIS_ENCODING_INT; // INT로 인코딩 타입 변경
            o->ptr = (void*) value; // 위에서 string2l로 만든 value 할당.
            return o;
        }
    }

    if (len <= REDIS_ENCODING_EMBSTR_SIZE_LIMIT) { // 위에꺼 실패하고 EMBSTR 제한 사이즈의 최댓값보다 작으면,
        robj *emb;

        if (o->encoding == REDIS_ENCODING_EMBSTR) return o; // 이미 EMBSTR이면 그냥 반환.
        emb = createEmbeddedStringObject(s,sdslen(s)); // 아니면, EMBSTR로 다시 인코딩 해 생성.
        decrRefCount(o); // 원래 애 메모리 해제
        return emb; // EMBSTR 반환.
    }

    /* 어떤 인코딩도 해낼 수 없었다면, 마지막으로 최대한 공간을 적게 쓰기위해 SDS string을 컴팩션한다. */
    if (o->encoding == REDIS_ENCODING_RAW &&
        sdsavail(s) > len/10)
    {
        o->ptr = sdsRemoveFreeSpace(o->ptr);
    }

    return o;
}

공간을 최대한 절약하기 위해 인코딩을 시도하는 함수다. 뭔저 저 SDS혹은 sds란 단어(함수앞에 엄청 많지 않은가.)에 대해 알아야겠는데, SDS가 뭔지 궁금해서 찾아보니, simple danamic string이라는 라이브러리였다. 이 라이브러리는 C언어를 위한 스트링 라이브러린데, 바이너리 세이프하고, 더 쉽게 C언어에서 스트링을 사용할 수 있게 해준다고 한다. Redis는 이 라이브러릴 사용해 스트링을 표현한다.

+--------+-------------------------------+-----------+
| Header | Binary safe C alike string... | Null term |
+--------+-------------------------------+-----------+
         |
         `-> Pointer returned to the user.

sds는 이런 개념을 사용하여, 헤더에 메타 데이터를 저장할 수 있게 한다. 기존 C언어의 스트링이 사용하다보면 불편한게 한두가지가 아니다보니 쓰는 듯 하다. 아무튼 얘는 이렇게 생겨먹어서, 사용하다보면 공간이 남는 경우가 있는데, redis는 최대한의 메모리 활용을 위해 이 여유분이 10%를 넘으면, Shrinking string(메모리를 컴팩션 하는.) 작업을 통해 최대한 메모리를 아낀다. 이때 호출하는 sds라이브러리의 함수가 바로 sds sdsRemoveFreeSpace(sds s);다. 과거(2.6버전)에는 이 작업이 없었던 것 같은데, 생겼다.

과거에는 EMBSTR 인코딩 타입이 없었으나 새로 생겼다. 이 새로생긴 이상한 이름의 인코딩 타입은, 정말 신박한 아이디어인데, redisObject와 연속적으로 이 sds string을 위치 시키는 방법의 인코딩이다. 즉 연속적인 메모리에 함께 위치한다. 그리고 이 sds string는 수정이 불가능하다. 아래 그림으로 어떤 말인지 살펴보자.

+--------------+-----------+------------+--------+----+
| robj data... | robj->ptr | sds header | string | \0 |
+--------------+-----+-----+------------+--------+----+
                     |                       ^
                     +-----------------------+

이런식이다. 이 경우, 원래 스트링 처리 기법은 그대로 사용할 수 있으면서도, cache locality를 극대화 할 수 있어 유리하다고 한다. 이게 무슨말이냐면, 메모리 주소에 접근할 때, 보통 해당 주소 뿐만 아니라 주변까지 포함한 블록 전부를 캐시에 가져오게 되는데, 이렇게 redisObject와 붙여놓으면 당연히 함께 캐시되니 퍼포먼스상 이득일 수 밖에 없다는 것이다. 또 시스템 콜(매우 느린)에서도 이득인데, 원래 할당을 을 robj위해 한번, robj->ptr을 위해 한번 더, 총2번했어야하는데 이제 한방에 할 수 있다는 퍼포먼스상 이점이 있다. 당연히 초기화나 조회, 메모리 카피시도 매번 유리해진다. 이런 세심함! 레디스의 성능은 여기서 나오나보다.

뿐만 아니라, 코드에서도 이런 세심함은 느껴진다. (물론 다들 이렇게 하긴 할건데… 내가 안하던거라..)

// redis.h

#define redisAssertWithInfo(_c,_o,_e) ((_e)?(void)0 : (_redisAssertWithInfo(_c,_o,#_e,__FILE__,__LINE__),_exit(1)))

#define sdsEncodedObject(objptr) (objptr->encoding == REDIS_ENCODING_RAW || objptr->encoding == REDIS_ENCODING_EMBSTR)

redisAssertWithInfo나 sdsEncodedObject같은 애들을 보면 레디스는 왠만한 애들은 함수를 안쓰고 #define을 이용해 정의했다. 나라면 함수로 만들었을 것 같은데, 어떻게해서든 운영 자원을 아끼려는 노력의 일환으로 보였다.

다시 돌아오자. setCommand로.

// t_string.c

void setCommand(redisClient *c) {

    // ... 중략 ...

    c->argv[2] = tryObjectEncoding(c->argv[2]); // 얘는 뭔가?
    setGenericCommand(c,flags,c->argv[1],c->argv[2],expire,unit,NULL,NULL);
}

이제 그 인코딩 된 내용을 c->argv[2]에 집어넣는다는 것을 알게 됐다. 저기에는 robj의 포인터가 저장된다. 아마, 그게 set명령어의 인자로 쓰이는 것 같다. 이제 실제 일을 처리하는 setGenericCommand을 살펴볼 차례다.

// t_string.c

void setGenericCommand(redisClient *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    long long milliseconds = 0; /* initialized to avoid any harmness warning */

    if (expire) {
        if (getLongLongFromObjectOrReply(c, expire, &milliseconds, NULL) != REDIS_OK)
            return;
        if (milliseconds <= 0) {
            addReplyErrorFormat(c,"invalid expire time in %s",c->cmd->name);
            return;
        }
        if (unit == UNIT_SECONDS) milliseconds *= 1000;
    }

    if ((flags & REDIS_SET_NX && lookupKeyWrite(c->db,key) != NULL) ||
        (flags & REDIS_SET_XX && lookupKeyWrite(c->db,key) == NULL))
    {
        addReply(c, abort_reply ? abort_reply : shared.nullbulk);
        return;
    }
    setKey(c->db,key,val);
    server.dirty++;
    if (expire) setExpire(c->db,key,mstime()+milliseconds);
    notifyKeyspaceEvent(REDIS_NOTIFY_STRING,"set",key,c->db->id);
    if (expire) notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,
        "expire",key,c->db->id);
    addReply(c, ok_reply ? ok_reply : shared.ok);
}

expire와 관련된 구현은 다음에 살펴보기로하자. 지금 중요한 것은 setKey함수다. addReply함수는 OK응답을 하는 함수다. 저기를 보면, default가 shared.ok다. 그렇다. SET 커맨드는 실패하지 않는다.

// db.c

void setKey(redisDb *db, robj *key, robj *val) {
    if (lookupKeyWrite(db,key) == NULL) {
        dbAdd(db,key,val);
    } else {
        dbOverwrite(db,key,val);
    }
    incrRefCount(val);
    removeExpire(db,key);
    signalModifiedKey(db,key); // client들에게 변경 이벤트를 알린다.
}

setKey 함수는 고수준의 Set operation을 표현하는 함수다. 이 함수는 현재 해당 키를 가진 object가 있는지 없는지 검사하고, 있다면 overwrite를, 없다면 새 object를 할당하는 역할을 한다. incrRefCount는 해당 값이 1회 참조됨을 의미하며, 저장되면서 key에 참조됐음을 표현한다. 기존에 key에 할당되어있던 expire은 없앤다. (키에 새로운 값이 할당되었으므로 기존에 있던건 제거해야.)

signalModifiedKey는 다음에 알아보도록 하자.

getCommand도 알아보자.

int getGenericCommand(redisClient *c) {
    robj *o;

    if ((o = lookupKeyReadOrReply(c,c->argv[1],shared.nullbulk)) == NULL)
        return REDIS_OK;

    if (o->type != REDIS_STRING) {
        addReply(c,shared.wrongtypeerr);
        return REDIS_ERR;
    } else {
        addReplyBulk(c,o);
        return REDIS_OK;
    }
}

void getCommand(redisClient *c) {
    getGenericCommand(c);
}

비교적 매우 간단하다. c->argv[1](redis command의 GET다음 인자)가 key다. lookupKeyReadOrReply로 DB를 확인해 해당 키를 조회한 후, 반환한다.

끝

기본적인 구현에 대한 내용은 알아보았다.
천천히 좀 더 자세히 들어가보자. 초반부터 오바하다 지치지 않도록 천천히.

태그 티스토리 redis 레디스 아키텍쳐 내부구조 소스

nodejs로 Azure(애저) 클라우드 알림 허브 푸시알림 보내기

youngkyu.cho — Wed, 20 May 2015 03:18:09 +0900

~~Edit~~

알림 허브

애저가 한국에서 많은 사람들이 사용하는 인기있는 서비스가 아니라, 뭔가 하나 하려면 생각보다 많은 공을 들여야 했다. 일단 내가 삽질을 헀으니, 다음 사람은 삽질하질 않길 바라는 마음으로 자주 Azure(애저)와 관련된 글을 올리려 한다. MS를 좋아하지 않았지만, 최근 행보와 서비스가 참 마음에 들었다. 특히 아마존 그 언저리되는 수준의 애저 서비스는 상당히 인상 깊었다. 그래서 최근 내가 운영하는 스타트업 Haffle은 슈퍼레디라는 서비스를 만들며 이 애저를 이용하기로 했다. 슈퍼레디 특성상 꼭 필요했던 서비스가 바로 푸시 알림이다. 이것을 구현하기는 어렵지 않겠지만, 다수의 사용자가 어떻게 알림을 구독하는지를 제어하고 이를 한 사용자의 다수의 각기 다른 디바이스에 알림을 골고루 뿌리는 일이 꽤 번거롭게 생각됐다. 아니, 본질인 서비스를 만드는 것 보다 오히려 여기에 상당한 시간을 들여야 한다 생각이 들었다.

그러다 알게된 서비스가 바로 애저의 알림허브다. 알림 허브는 다양한 플랫폼에서 지원되는 푸시 알림 인프라 서비스로, tag를 이용해 마치 검색하듯 알림을 손쉽게 보낼 수 있다. 빠르고 저렴하며, 우리가 제작하는 것 보다 안정적이라는 점이 상당히 마음에 들었다. 애저를 이용해 알림 인프라를 구축하는 비용보다 저렴하면서도 필요한 모든 기능이 제공됐다.

어찌됐든 쓰기로하고 나서 막상 개발하려니 막막했는데, 문서화가 잘 되어있지 않은 점 때문이었다. 당연하게도 C#쪽 문서는 완벽했지만 nodejs쪽은 불친절한 API 문서 외에는 거의 뭐 설명서가 제대로 없었다. 공식 사이트에선 찾을 수 없어서 이리저리 뒤져봤는데 원하는 만큼의 딱 들어맞는 예시는 찾을 수 없었다. 생각보다 구글에서 영어로 찾아도 잘 안찾아지는? 그래서 내가 쓴다.

뭔가 멋지게 설명하고 싶은데, 어차피 예제 코드만 볼 것 같아, 코드만 쫙 보여주는 식으로 쓰겠다. 안드로이드와 아이폰만 우리가 필요해서 두개의 코드만 있는데, 원래는 엄청 다양한 플랫폼을 지원한다.

먼저,

당연히 애저에 가입하고, 관리 포털을 접속하여 알림허브 서비스를 구성해야한다. 서비스 버스 메뉴에서 알림허브를 만들 수 있다.

그리고 나면 npm으로 azure 패키지를 설치한다.

sudo npm install azure

이후, 서브라임 텍스트 같은 편집기를 켜서 작업을 시작한다. 첫 줄에 먼저 모듈을 로드한다.

var azure = require('azure');

그리고 알림 허브와 연결을 하고, 명령을 처리해줄 객체를 만들어야한다.

var notificationHubService = azure.createNotificationHubService('hubname','connectionstring');

저기서 파라매터로 들어가는 hubname과 connectionstring은 Azure 관리 포털에서 알 수 있다.
hubname은 서비스 허브에서 구성할 때 입력한 이름이고, connectionstring은 알림 허브 대시보드 어딘가에 보이는 연결 문자열 보기를 클릭하면 알 수 있다. 그 긴 연결 문자열을 복붙하면 된다.

태그란?

잠깐 알아야할 게 있다. 애저는 태그를 사용해 푸시 알림의 스코프를 관리한다. 모든 사용자에게 브로드캐스트 할 수도 있지만, 어떨 때는 딱 한 명한태만 하고 싶을 때도 있다. 예를들어 나는 아이폰과 아이패드, 그리고 안드로이드 폰 세개를 쓰는데, 내게 와야할 알림이 아이패드만 오거나 아이폰에만 오면 안되고 3개의 디바이스 모두에 와야하지 않겠는가. 이럴때 tag를 youngkyu라고 쓰고, youngkyu란 태그에 푸시를 쏘면 모든 youngkyu의 디바이스에 푸시 알림이 도착한다.

서비스 버스 알림 허브에 시그니처와 API 키 등록

알림 허브에 구성을 클릭하면 APNS와 GCM의 시그니처와 키를 등록하는 곳이 있다. 여기에 해당 파일과 키를 올려줘야 애저에서 처리할 수 있는 환경이 조성된다.

디바이스 등록하기

먼저 디바이스를 등록해야한다. 이때 youngkyu로 예시를 들었던 tag도 설정한다. 잘 추상화되어있어서, 푸시알림의 과정을 정확히 이해하지 못해도 원활히 사용할 수 있다. 이 과정에 대한 얘기는 다음에 포스팅하겠다.

아이폰

먼저 아이폰의 deviceToken이 필요하다. 이건 애저와 관련이 없으므로 여기서 설명하지 않는다.

notificationHubService.apns
    .createNativeRegistration(deviceToken,tags,null,function(error){
    // To do
});

여기서 파라매터에 deviceToken은 받아온 토큰을 집어넣고, tags에는 배열에 담은 태그들을 집어넣는다. 세번째 null은 option으로 중요하지 않다. 제대로 설명도 안되있어서 아직 기능이 크게는 없는 듯 하다. 마지막 callback에 이후 할 작업 함수를 넣는다.

아래는 내가 쓴 코드 일부다.

notificationHubService.gcm
    .createNativeRegistration(deviceToken,["user","user."+userId],null,function(error){
    if(!error) {

    }
});

태그에 ["user","user."+userId]가 보이는가. 이렇게 적게되면 이후 "user"라는 태그에 푸시를 때리면 모든 "user"태그를 가진 디바이스가 받게 된다. 그리고 "user.12"라고 하면 12번 유저 아이디의 사용자만 받게 되는 식이다.

안드로이드

마찬가지로 deviceToken인 gcmRegistrationId가 먼저 필요하다.

notificationHubService.gcm
    .createNativeRegistration(gcmRegistrationId,tags,null,function(error){
    // To do
});

위와 똑같다. gcm만 빼고.

푸시 보내기

등록이 끝나고 나면, 아래 코드를 실행해본다.

var payload = {
    alert : "hello noti!",
    sound : "default"
}
notificationHubService.apns.send(null,payload,function(error){});

띵똥. 푸시가 왔는가? payload에 sound가 소리를 내는 역할을 하고, alert이 글을 표현한다. 그리고 send()의 첫번째 인자는 tag인데, null이면 브로드캐스트다. 모든 등록된 아이폰/IOS 디바이스에 전송한다. 따라서 받게 되는 것이다.

var payload = {
    alert : "hello users!",
    sound : "default"
}
notificationHubService.apns.send("user",payload,function(error){});

위와 같이 보내면 user태그를 가진 디바이스만 받게 된다. 만약 태그를 여러개 지정하고 싶다면, 아래와 같은 규칙을 쓰면 된다.

여러 태그들에 : “user.12||user.23||user.24”
두 태그 다 가지고 있는 : “user||post.15”

간단하다.

끝!

아주 간단하지만 많이 당황스러웠다. 섬세히 알려주는 튜토리얼 하나 없이 고작 API문서 딸랑 하나보고 시작했으니. 어쨌든 쉽다. 그리고 매우 강력하다. 푸시 시스템을 직접 만들면 더 저렴했을지 모르지만 (실은 그렇지도 않을 거다) 기회 비용이 상당히 높게된다. 서비스를 만드는 회사니 서비스에 집중해야하는데 말이다. API 문서는 아래 주소를 눌러 볼 수 있다. 다음 포스트에서는 초기에 설정한 tag이외의 tag들을 추가해보자.

http://dl.windowsazure.com/nodedocs/NotificationHubService.html

우분투 시작시 자동으로 특정 명령 실행하기.

youngkyu.cho — Tue, 17 Mar 2015 16:02:30 +0900

~~Edit~~

부제 : 맥 트랙패드처럼 우분투 트랙패드 스크롤 방향 바꾸기.

우분투를 썼었는데 최근 맥북 프로 레티나를 사며 너무 좋아서 계속 맥만 썼다.
그런데 15인치를 샀더니 들고다니기가 너무 무거워서 맥북 에어를 살까 고민하던 와중에 맥북이 나온다는 소문을 듣고 조금 참고 기다리다가 맥북을 사야지라고 마음을 먹었다.

그리고 집에 있던 가벼운 LG울트라북 Z330을 꺼내 일단 잠시 쓰기로 하였다. 윈도우는 조금 느린감이 있어서 답답했고, 또 터미널도 없고해서 우분투를 기반으로한 배포판 Elemantary OS를 깔기로 결정했다!

그래, 한글 문제는 어찌저찌 해결해야지.. 리눅스가 그렇지머.. 라고 열심히 세팅을 다하고 막 쓰려는데!!!

예전엔 없던 문제가 생겼다.

내가 맥의 트랙패드 스크롤에 익숙해져 버린 것이다. 맥의 스크롤 방향은 위로 올리면 스크롤이 아래로 내려간다. 내리면 올라가고. 이거 어쩐담…

아래의 스크립트를 실행하면 된다!

 synclient VertScrollDelta=-100

굿굿!

아… 그런데 또 문제 발생… 껏다키니 다시 원래대로 돌아오네?

시작시 바로 명령어로 입력되게 하자!

/etc/rc.local

쟤를 찾아라. 얘를 고치면 된다! 여기다 적어라 쟤를!

 synclient VertScrollDelta=-100

이때, 거기 밑에 원래 있던

exit 0

는 반드시 지워주어야 실행된다.로그아웃 후 다시 들어오면 정상적으로 작동됨을 확인할 수있다.

도커란 무엇인가 / Docker 컨테이너 / Docker 이미지 / LXC / 가상화

youngkyu.cho — Mon, 9 Mar 2015 20:13:42 +0900

본 포스트는 개인적으로 가장 빨리 만나는 Docker(길벗 출판사 , 이재홍저)책을 공부하며 정리하는 포스트라는 것을 미리 밝힌다.

Docker란 무엇인가?

도커는 2013년 3월에 출시한 오픈소스 컨테이너 프로젝트다. 현재 2년정도 지난 시점에 세계적으로 엄청난 인기를 구사중인 대단한 프로젝트기도 하다.

서버시장이 클라우드 환경으로 옮겨가게 되면서 우리는 가상서버를 손쉽게 수백대를 구매하여 바로 사용할 수 있게 되었다. 그런데, 서버 갯수가 많아지면서 각각의 서버에 소프트웨어 설치와 설정이 큰 귀찮음으로 다가오게 됐다. 몇개 안됐다면 직접 할텐데 갯수가 엄청나니 이것을 처리할 무언가가 필요했다.

초기에 쉘 스크립트를 통해 해결하려는 시도도 있었다. 이 방법으로 필자도 오랜기간 서버 관리를 해왔다. 그러나 쉘 스크립트는 복잡한 기능 구현은 거의 불가능 할 뿐더러(사실은 잘 못해서 그런거겠지만… ㅋㅋ) 자동화의 한계가 있다. 이를 어떻게 해결 할 것인가.

이를 해결하기 위해 나온 아이디어가 바로 Immutable Infrastructure다. 그 서버에 깔린 OS(호스트 OS)와 서비스 운영을 위한 환경(서버 운영을 위해 필요한 프로그램들; node js, mysql, java등)을 분리해 이 서비스 운영환경을 패키징 해 배포한다는 아이디어이다. 이때 이/ 패키지를 데몬툴즈같은 가상 이미지 파일과 비슷하다해서 이미지라 부른다. 어쨋든 이런 생각을 구현한 것이 Docker다.

이것은 엄청난 확장성을 가져다 준다. 클라우드 플랫폼에 이것을 적용하면 자동 확장이 가능해지고 마치 공장에서 틀에 물건을 찍어내듯 마구마구 서비스를 확장할 수 있다!

가상머신과는 뭐가 다른거야?

언뜻 들으면 가상머신과 똑같다. 가상 머신에 리눅스를 설치하고 그 가상 머신을 이미지화 해 여러 서버에 복사하면 똑같은 것 같지 않은가. 그런데 좀 다르다.

가상머신

가상 머신은 편했다. 그러나 느렸다. 가상 머신 자체는 거의 완전한 컴퓨터다. 이게 무슨말이냐하면, 가상머신은 기본적으로 원래 컴퓨터 OS(호스트OS)위에서 돌아간다. 그리고 그 가상머신은 하이퍼바이저를 통해 그 위에서 수십개의 게스트 OS를 돌린다. 즉 게스트 OS가 독자적으로 돌아가는 가상 컴퓨터 인 것이다. 올리고 올라가고 올라가서 실행되니 느린건 당연지사.

OS를 자체적으로 가지고 있다는 것은 OS를 가상 머신 이미지에 포함해야 했고, 이렇게 되다보니 이미지 용량이 상당히 컷다. 그리고 이것은 상당히 배포와 관리를 힘들게 했다. 인터넷이 빨라도 엄청난 용량은 부담인건 똑같으니까.

Docker는 뭐가 달라.

도커는 이를 더 가볍게 만들었다. 게스트 OS를 없애버렸다. Docker는 호스트 OS를 사용해서 동작한다. 즉 호스트 OS의 시스템 콜을 직접 호출한다. 이것은 매우 빠른 속도로 작동할 수 있음을 의미한다(실제 빠른가는 별개의 문제기에).

도커는 도커 이미지에 서버 운영을 위한 프로그램과 라이브러리를 포함하고 있다. 이런 이미지들은 도커로 각각 격리되어 설치된다. 즉 도커 엔진이 도커 이미지를 설치할 때, 마치 가상 머신처럼 분리 시켜준다는 것이다. 그러나 호스트 OS는 공유한다. 그게 다다.

도커를 사용하면 호스트OS위에서 바로 돌리는 것과 비슷한 성능 수준을 얻을 수 있다. 99%정도까지 유사하다고 한다.

도커가 제공하는 Docker Hub

도커는 이미지 생성과 배포에 특화된 기능을 제공한다. 마치 깃처럼 이것을 이용하면 이미지를 push/pull할 수 있다. 뿐만 아니라 이것들을 공유할 수 있는 깃헙과 같은 도커허브를 제공한다.

리눅스 컨테이너 이야기부터 해보자.

chroot라는 명령어가 있다. 이것은 파일 시스템에서 루티 디렉토리(/)를 바꾸는 것이다. chroot로 특정 디렉토리를 루트 디렉토리로 설정하면 chroot jail이라 불리는 격리된 감옥이 생성된다. 이것을 활용하면 안에서 밖으로는 절대 나갈 수 없는 환경을 만들 수 있다. 이것으로 하이퍼바이저의 오버헤드를 피하면서 가벼운 가상화 비스므리한 환경을 조성할 수 있었다. 그러나 이것은 온갖 귀찮은 일을 해야 하게 만든다.

일단 실행 파일과 라이브러리등을 직접 준비해 넣어줘야한다. 바꿔야 하는 설정이 있다면 해당 설정또한 바꿔야 한다. 해당 공간이 사용하는 정보들을 제대로 제공받지도 못할 뿐더러 호스트의 다른 프로세스의 어떤 문제가 직접적으로 영향을 끼친다. 아무튼! 사용자가 해야할 일이 엄청나다. 이것을 해결하기 위해 이것을 시스템 레벨에서 좀 더 잘 제공하자는 리눅스계의 움직임이 있었고, LXC(LinuX Container)라는 기능이 탄생한다.

LXC는 기존 가상화와 달랐다. 이 공간에는 OS가 없기에 가상 머신이라 부르기도 좀 그랬다. 그래서 바구니/그릇(컨테이너)정도로 부르기로 결정했다. 한국인이면 바구니라 불렀을지도 모르겠는데, 외국인이라 컨테이너라 부른듯하다.

이 LXC기능에 완전히 격리된 가상 공간을 제공하고자 했다. 이를 위해 커널의 Control Group(cgroups) 기능을 통해 CPU도 메모리도, 디스크와 네트웍자원까지 할당할 수 있도록 했고, 커널의 Namespace isolation(혹은 namespaces)이란 기능으로 프로세스트리와 사용자계정, fs까지도 격리되도록 했다.

그러나 이렇게 생성된 LXC기능은 공간 외에 서버 운영에 필요한 기능을 필요한 수준으로 제공치 못했다. 이에 따라 Docker가 등장한다.

LXC와 도커

기존에 LXC에 기능을 얹기 위해 구현된 도커는 0.9버전부터 libcontainer를 사용해 LXC를 대체하기 시작한다. 직접 LXC의 기능을 하기 시작한 것이다. 그리고 이를 exec driver라 부른다.

실행옵션에 따라 LXC 또한 사용할 수 있다.

Docker 이미지 VS 컨테이너

도커에는 이미지와 컨테이너라는 2가지의 헷갈리는 단어가 존재한다. 또 이미지는 베이스 이미지와 도커 이미지로 구분된다.

베이스 이미지

베이스 이미지란, 리눅스 배포판의 커널 영역을 제외한 사용자 공간/영역(유저랜드)만을 이미지에 포함한 파일을 의미한다. 이때 사용자공간/영역(유저랜드)란, 커널 공간/영역과 관련된 것들을 제외한 부팅시 필요한 몇몇 실행파일과 라이브러리, 그리고 패키징 시스템(우분투의 apt같은)것들을 포괄해서 부르는 명칭이다. 이 유저랜드 혹은 사용자공간/영역에 Redis나 Nginx등을 설치해서 베이스 이미지로 배포하기도 한다.

유저랜드에는 각 리눅스 배포판의 특징이 고스란히 있어서 각 배포판 고유의 패키징 툴도 그대로 활용 할 수 있다. 이 베이스 이미지는 변형되거나 뭔가가 추가 설치될 수 있는데 이렇게 해서 변형된 이미지를 도커 이미지라 부른다.

도커 이미지

도커 이미지는 베이스 이미지에서 몇가지를 라이브러리, 프로그램, 소스 파일등을 추가/설치/저장한 이미지다. 도커 이미지는 베이스이미지부터 상속받듯이 만들어진다. 즉, 베이스이미지에서 추가되거나 변형되는 부분만 도커 이미지에 저장된다. 이렇게 만들어진 도커 이미지는 또 수정될 수 있는데, 이렇게 수정되면 또 그 변형된 부분만 다시 도커 이미지에 저장된다.

첫번째 변화후 저장된 도커 이미지를 A라 하고, 두번째 변화후 저장된 도커 이미지를 B라 하면,

베이스 이미지 + A + B

를 하여 도커 이미지 실행이 시작된다. 이 때 도커는 필요한 파일을 부모이미지부터 자식이미지까지 싹 받아서 합친다. 이렇게하여 실행된 이미지를 우리는 컨테이너라 부른다.

컨테이너

도커 컨테이너는 이미지가 실행된 상태를 뜻한다. 이미지 하나로는 수백개의 컨테이너를 생성할 수 있다. 마치 이 관계는 실행파일과 프로세스의 관계 같은 것이다.

“ 다음 시간에는 도커를 설치해보자! ”

브라우저 위치 정보 받아오기 / HTML5 Geolocation API

youngkyu.cho — Sat, 3 Jan 2015 03:48:16 +0900

~~Edit~~

브라우저 위치 정보 받아오기 / HTML5 Geolocation API

스마트폰이 보급되면서 브라우저에서도 위치 기반 서비스들이 다수 생겨났다. 이러한 서비스를 필자도 만들 필요가 있었는데, 이를 위해서 필요한 API가 바로 이 Geolocation API다.

해당 디바이스의 GPS, IP address 정보, Wi-Fi, GSM, CDMA망의 ID를 통해 위치를 대략적으로 예측하여 브라우저가 반환해주는 API로 어떤 디바이스건 관계없이 사용할 수 있다. 그러나 이렇다보니 정확한 위치정보 라는 것을 보장하지 않고, 또 어떤 방식으로 해당 위치가 얻어졌는지도 알 수 없다. 그러나 일반 사용자용 웹앱을 만들기 위해서는 이 정도면 충분하다.

Geolocation API

Geoloaction API는 window.navigator에 정의되어 있다. IE 9이후, 파이어폭스, 크롬등에서도 지원하고 있다. 사생활 침해의 가능성으로 인해 위치정보를 제공받기 위해서는 사용자가 허가를 해야 한다.

1. 빠르게 현재 위치정보 가져오기

이때 중요한게 우리가 사용할 Geolocation 객체가 존재하는지를 체킹하는 것인데 아래와 같은 방식으로 할 수 있다.

if("geolocation" in navigator) { 
    // Geolocation API가 있는 브라우저라면,
} else { 
    // 없는 브라우저라면,
}

일반적인 위치정보를 가져오기 위해서는 window.navigator객체의 getCurrentPosition()함수를 사용하면 된다. 이때 사용하는 getCurrentPosition()함수는 정확도보다는 빠른 응답에 초점을 둔다. GPS정보는 받아오는데 시간이 소요되기에 보통 이 함수는 IP address 또는 WI-FI에 기대어 위치를 추정한다.

먼저 이 함수 호출시 사용자의 위치 탐지를 시작하라는 명령을 비동기적으로 하드웨어에 요청한다. 위치가 확인이되면 콜백 함수가 실행이 되는 형태로 작동한다. 따라서 우리는 성공시 할 작업을 정의한 함수를 파라매터 콜백 함수(아래 예시 코드의 do_something)로 넣어준다.

navigator.geolocation.getCurrentPosition(function(position) {
    do_something(position.coords.latitude, position.coords.longitude);
});

Position객체가 콜백 함수의 파라매터로 넘어오면, 여기서 위치 정보를 꺼낼 수 있다.

2. 현재 위치 보정/갱신

더 정확한 위치 정보가 추가적으로 도착해서 그 정보를 반영해 보정한다거나, 디바이스의 움직임에 따라 갱신된 위치 정보를 반영해 주고 싶다면 watchPostion()함수를 활용하면 된다. 이것은 getCurrentPosition()과 동일한 사용방법을 가지고 있다. 디바이스가 움직여서 위치 정보가 변화된다거나, 혹은 더욱 정확도가 높은 위치정보를 계산해냈을 경우 갱신되어 여러번 콜백함수가 호출된다.

watchPostion()는 getCurrentPosition()호출과 관계없이 사용할 수 있다.

navigator.geolocation.watchPosition(function(position) {
    do_something(position.coords.latitude, position.coords.longitude);
});

그런데 이때 문제가 생긴다. 더 이상 디바이스 정보를 받아오는 것을 그만 두고 싶은 경우가 생기는 상황이 바로 그것인데, 이를 해결하기 위해 watchPosition() 함수는 watcher ID를 반환한다.

var watcherID = navigator.geolocation.watchPosition(function(position) {
    do_something(position.coords.latitude, position.coords.longitude);
});

navigator.geolocation.clearWatch(watchID); // 위치 갱신 그만 두기

이 watcherID를 통해 우리는 사용자 위치 갱신을 그만 둘 수 있다. 아래 코드가 그 방법이다.

3. 위치 정보의 세부 옵션

getCurrentPosition()과 watchPosition()은 둘다 성공시의 콜백, 실패시의 콜백(이 실패시의 콜백의 경우, watchPosition()에서 실패시 여러번 호출되지 않고 한번만 호출된다.), 그리고 PositionOptions 객체를 파라매터로 받는다.

function geo_success(position) {
    do_something(position.coords.latitude, position.coords.longitude);
}

function geo_error() {
    alert("위치 정보를 사용할 수 없습니다.");
}

var geo_options = {
    enableHighAccuracy: true, // 불리언
    maximumAge        : 30000, // 천분의 1초 단위
    timeout           : 27000 // 천분의 1초 단위
};

var wpid = navigator.geolocation.watchPosition(geo_success, geo_error, geo_options);

위 코드는 예시다. geo_options라는 변수명으로 표현된 PositionOptions 객체에 대해 세부적 프로퍼티의 의미를 알아보자.

enableHighAccuracy : 정확도를 높게 받을지에 관한 값이다. true로 설정시 응답이 느려지거나 전력 소비가 증가되는 등의 부작용이 발생할 수 있다. false라면 디바이스 스스로 자원을 분배해 사용한다.

timeout : 위치를 받아올 때까지의 대기 시간을 의미한다. 기본값은 Infinity다.

maximumAge : 캐시된 위치 값의 유효시간을 의미한다. 0을 지정하면 캐시된 위치를 사용치 말라는 것이고, Infinity를 지정하면 캐시된 위치가 언제 수집된 건지 개의치 않고 반환한다.

4. Position 객체와 PositionError 객체.

Position는 coords 객체와 timestamp(수집된 시간)를 프로퍼티로 가진다.

그리고 coords 객체는 아래와 같은 프로퍼티들을 가진다.

latitude : 경도
longitude : 위도
altitude : 고도
accuracy : 미터로 표현한 위,경도의 정확도
altitudeAccuracy : 미터로 표현한 고도의 정확도
heading : 장치가 움직이는 방향을 나타내는 숫자. 이 값은 정북에서 시계방향으로 벗어난 각의 크기를 나타낸다. (정북향 0도, 동쪽 90도, 서쪽 270도)
speed : 장치의 속도

PositionError 객체는 에러 콜백 함수에 첫번째 파라매터로 전달 되는 객체다.

function errorCallback(error) {
    alert('ERROR(' + error.code + '): ' + error.message);
};

code(1 : permission denied, 2 : unavailable, 3 : timeout)와 message(문자열로 표현된 에러 메세지)를 프로퍼티로 가진다.

워드프레스 설치 준비하기 - 우분투와 MariaDB, Apache, PHP와 함께.

youngkyu.cho — Wed, 31 Dec 2014 04:02:50 +0900

~~Edit~~

워드프레스 설치 준비하기 - 우분투와 MariaDB, Apache, PHP와 함께.

최근 한 프로젝트를 진행하면서 빠르게 기본적인 웹 기능을 구현해 컨텐츠에 집중하기위해 워드프레스를 쓰기로 결정했다. 매력적인 녀석인 것 같다 정말. 놀라울 정도다. 단순한 블로그엔진이고 그게 끝인줄 알았는데, 확장성이 엄청난다.

쨋든 워드프레스를 써보기 위해 과거 php를 공부하며 APM으로 초고속으로 윈도우에서 대충 구축했던 개발환경을 클라우드 원격 서버 개발 환경인 우분투에서 다시 해야했다. 이 과정을 쓰려고 한다.

하는 MariaDB를 사용해봐야지 하며 아파치+php+MariaDB를 붙여 세팅했다. MySQL보다 속도가 좀 잘 나오는 것 같아서필자는 MariaDB를 항상 쓰고 있다. 특별하게 MySQL을 고집하는 누군가가 없는 이상.

누군가에겐 이 글이 도움이 되겠지?
시작해보자.

1. Apache 설치

Apache를 설치하자. 유명하니 설명이 필요없는 웹서버다. 아마 아직도 점유율 1등 웹서버일게다.

$ sudo apt-get install apache2

우분투의 놀라운 패키지 툴 덕분에 우리는 이것만 치면 된다. 뭐라고 뜨면 Y를 치고 엔터.

2. MariaDB 설치

필자는 MariaDB를 설치하려 한다. MySQL과 완벽히 연동되면서도 더 나은 성능을 지니고 있다. 최근 오라클의 행보를 보면서 그나마 남아있던 MySQL에 대한 애정이 식어버렸다.

얘는 근데 설치가 조금 복잡하다. 그래도 그냥 따라오면 금방한다.

MariaDB 설치에 관한 원문은 여기로 가면 볼 수 있다.

근데 이건 뭐 그냥 자세한 설치에 관한 설명이고, 우리가 필요한건 이거다.

자신의 우분투 버전과 필요한 MariaDB버전을 보고 그 아래 명령을 줄줄이 치면된다.

Ubuntu14.04에 버전 5.5를, 그리고 카이스트 서버에서 받아서 설치하고자 한다면 아래를 그대로 입력하면 된다.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
$ sudo add-apt-repository 'deb http://ftp.kaist.ac.kr/mariadb/repo/5.5/ubuntu trusty main'
$ sudo apt-get update
$ sudo apt-get install mariadb-server

굿. 끝이다.

3. PHP 설치

PHP 설치는 이 명령 한줄이면 끝이다.

$ apt-get install php5-common php5 libapache2-mod-php5

이제 가장 기초적인 준비가 끝났다.

4. MariaDB와 PHP의 연동.

둘을 연동 시키기 위해서는 php5-mysql 란 모듈이 필요하다. 설치하자. 설치만 하면된다.

apt-get install php5-mysql

5. 재시작

모든 것이 준비됐다. 설치되면 자동으로 각각이 실행된다. 따라서 추가적으로 설치해준 것들을 반영시켜주기위해 Apache와 MariaDB를 재시작 시켜주어야 한다.

먼저 Apache를 재시작 시키자.

$ service apache2 restart

그리고 MariaDB를 재시작 시키자.
이때 사용하는 명령어에 mysql이 보이는 이유는, MariaDB가 호환성을 100%로 만들기 위해 모든 명령을 mysql과 똑같이 했기 때문이다.

$ service mysql restart

6. 작동 확인

이제 모든 것이 설치됐고 다 끝났다. 정말 잘 연동되고 실행되고 설치됐는지 확인해볼 차례다.

아파치의 루트로 가자.

$ cd /var/www

그리고 거기에 html폴더로 들어간다.

$ cd html

그리고 거기에 test.php를 만들자. 이걸 요청해 보면 전체가 제대로 설치됐는지 알 수 있다. 아래는 test.php코드다. 복붙하라.

<?php
    phpinfo();
?>

그리고 우리는 브라우저에서 확인해보면된다.

이 작업을 한 서버 IP주소가 1.2.3.4 라고 가정하면, 브라우저 주소창에

http://1.2.3.4/test.php

라고 요청하면 된다. 도메인이라면,

http://example.com/test.php

이런식으로 하면 된다.

제대로 뭔가 보라색 테이블이 나오면 쭉 내려서 mysql이라는 제목을 찾아라.

거기에 MariaDB라는 단어가 보인다면 연동도 잘 된 것이다.

린 스타트업으로 스타트업 시작하기. - 2 / 3가지의 원칙을 만들자. / 린 캔버스

youngkyu.cho — Sat, 20 Dec 2014 01:07:26 +0900

~~Edit~~

린 스타트업으로 스타트업 시작하기. - 2

3가지의 원칙을 만들자.

포스팅 전에.

먼저 포스팅 전에 확실히 해 둘 것이 있다. 필자는 스타트업을 진행하며 린 스타트업 프로세스를 따르려한다. 이에 교과서가 필요했고, 한빛 미디어의 오라일리 번역서인 RUNNING LEAN:린 스타트업를 선택해 공부하고 있다. 이 포스팅은 개인적 공부의 흔적이며, 해당 책의 순서를 따르지만, 필자가 이해한대로 재 기술해 내용은 동일하지 않다.

린 경영의 중요한 개념들을 짚어봤다. 이제 린 경영을 실천할 수 있는 핵심 문장으로 만나보자.

린 경영의 핵심.

1. 플랜 A의 문서화

불행히도 당신의 첫 플랜이었던 플랜 A는 생각보다 훨씬 적절치 못하다. 혼자 믿는 신념따위가 아닌 명확한 사실에 기반해 확실한 목표와 분명한 취지를 세워야한다. 이것만이 충분히 강한 비전이 될 수 있다. 문서화는 그를 위한 시작이다.

사업 모델이 바탕으로 하는 가설은?

대부분의 플랜 A는 형편이 없다. 아마 엄청나게 많은 허무맹랑한 가설이 뒷받침 된 상태에서 생각된 사업 모델일 것이기 때문이다.

우리는 현실을 왜곡 시켜 생각하는 경우가 많다. 우리가 생각한 아이디어를 보호하기 위한 무의식적인 반응이다. 따라서 이것들을 걷어내기 위해 우리는 타인과 이야기해야한다. 많이 부딧혀서 왜곡을 걷어내야한다. 그러기 위해서 문서화는 필수다.

융통성있게 린 캔버스 활용하기.

고작 타인과 이야기 한번 나누기위해 60장의 사업계획서는 낭비다. 상대는 읽어줄 생각도 없을 것이고, 나는 힘들 것이 분명하니까. 따라서 린 캔버스로 간단히 나타내는 것은 매우 효율적이다. 모든 것이 표현되면서 한눈에 들어오니 말이다.

만들어야 할 것은 사업모델.

만들어야 할 것은 제품이 아니다. 저 캔버스의 모든 요소들, 즉 사업 모델이다. 고객은 여러분의 솔루션엔 관심이 없다. 오직 자신의 문제에만 관심이 있다. 따라서 솔루션에 지나치게 시간을 소모해서는 안된다. 모든 요소 전체가 충분한 검토를 만나야한다.

이 모든 사업모델을 하나하나 정복해 나가는 것이 바로 우리의 일인 것이다.

2. 사업 계획의 위험부분을 찾아라.

가장 위험한 부분을 찾아내라. 그리고 먼저 다뤄라. 그러나 아마 대부분의 스타트업에서 가장 큰 위험을 안고 있는 부분은 아마

아무도 원하지 않는 것을 만드는 것

일 것이다.

스타트업의 3단계 프로세스

문제와 솔루션에 대한 적합성 검증을 거치고 제품을 개발해
제품과 시장에 대한 적합성 검증을 거치고,
규모를 확장해 나가야 한다.

1. 문제/솔루션의 적합성

어떤 문제가 해결할 가치가 있는지를 판단해야한다. 그것을 판단하려면 다음과 같은 세가지 질문에 명확히 답변을 해보면 된다.

고객이 원하는 것인가? (필수성)
고객이 돈을 내고 구입할 것인가? 그렇지 않다면 누가 구입할 것인가? (실효성)
문제를 해결 할 수 있을 것인가? (실현가능성)

이것으로 부터 문제를 해결하기 위한 최소 기능 집합을 도출해 낼 수 있을 것이다. 그것을 모아 product를 만든 것을 MVP(Minimum Viable Product)라 한다.

2. 제품/시장의 적합성

이것에 대한 질문은 하나다.

사람들이 원하는 솔루션을 개발하는가?

개발한 MVP가 얼마나 잘 문제를 해결하는가, 즉 그것이 사람들이 원하는 것인가에 대한 물음이다. 이 단계까지 도달하면 아마 스타트업은 고객을 유치하고 유지하며 매출을 확보해 낼 것이다. 그리고 나면 마지막 확장이다.

3. 규모의 확장

이것은 성장에 관한 것이다.

어떻게 성장을 가속화 할 것인가?

일정 수준의 성공은 보장되었다. 이제 성장해야한다. 사업 모델의 초첨은 지금부터는 규모의 확장인 것이다.

제품/시장 적합성 확보 전엔 PIVOT

제품과 시장의 적합성을 명확히 하지 못했다면 고객의 피드백, 즉 고객 학습을 바탕으로 방향을 전환 해 나간다. 이것을 PIVOT(피벗)이라 한다. 방향 전환이란 효과적인 계획을 찾아나가는 일이다. 더 나은 방향으로 경로를 수정하는 일이다. 그리고 검증을 해 나가는 일이다.

모든 적합성 확보 후엔 최적화를.

최적화란 계획을 더욱 가속화 시키는 것이다. 즉, 규모의 확장 단계에 하는 일이다. 사업 모델을 개선하고, 더욱 확장하며, 효율성을 증대시키는 것을 의미한다.

학습을 극대화하려면 과감하게.

결과를 예측하기 어려워질수록 학습은 더욱 극대화된다. 더 많은 것을 학습 할 수 있다. 두려워하지말고 질러라.

다양한 고객군을 대상으로 다양한 MVP들을 실험해보라. 다양한 UVP(Unique Value Proposition;고유가치제안)을 설정하고 학습을 위해 다양한 고객군에 실험해보라.

이상적 외부 투자 유치 시점은 적합성 확보 이후.

파워포인트 몇 장으로 일정 수준의 검증도 이루어지지않은 사업 모델을 투자자에게 설득해 내는 것은 시간낭비일 뿐.

문제와 솔루션에 대한 적합성이 확보되고, 제품이 개발되고 그것에 대한 제품/시장 적합성이 확보되었다면 그때가 가장 적합한 외부 투자 유치 시점이다.

기존 자원을 최대한 활용해서 스타트업은 적합성을 확보해 내야한다. 즉 스타트업 초기엔 투자가 아니라, 사업 모델을 고객에게 테스트하고 검증을 시작할 수 있을 만큼의 자금을 마련해 내는 것을 목표로 삼아야한다.

3. 계획을 체계적으로 테스트하라.

유효 학습 고리

실험이란 유효한 학습고리의 사이클로 구성된다.

아이디어를 내고,
개발을 하며,
제품을 만들어내고,
사용자 반응을 측정해,
측정 데이터를 분석하고,
학습한다.
그리고 다시 아이디어를 낸다.
반복한다.

어떤 가설 혹은 아이디어를 테스트하려면 실물 모형, 코드, 랜딩 페이지등을 만드는데 상용할 아이디어, 가설이 필요하다. 어쨌든, 이것들을 만들고 정성적이고 정량적인 방법으로 가설 혹은 아이디어의 고객 반응을 측정해 내고, 이 데이터를 분석하고 학습한다. 이를 근거로 가설 혹은 아이디어의 유효성을 검증하거나 반박해내는 과정을 되풀이한다.

이게 바로 유효 학습 고리다.

반복 메타 패턴

 문제 이해 -> 솔루션 정의

 그후

 정성적 검증 -> 정량적 확인

위의 유효 학습 고리의 연장선상이다. 문제를 이해하고 솔루션을 정의하며, 정성적인 방법(미시적 범위에서의 접근)과 정량적인 방법(거시적 범위에서의 접근)을 통해 검증을 해 나가는 것이다. 이것을 반복 메타 패턴이라고 한다.

문제 이해와 솔루션 정의를 적합성 확보하기과정,

그 다음 사람들이 원하는지를 정성적(미시적)으로 검증, 정량적(거시적)으로 확인하는 것을 테스트의 과정이라 생각하면 된다.

린 스타트업으로 스타트업 시작하기. - 1 / 워밍업하기. / 고객개발 / 부트스트래핑

youngkyu.cho — Sat, 20 Dec 2014 01:05:04 +0900

~~Edit~~

린 스타트업으로 스타트업 시작하기. - 1

워밍업하기.

포스팅 전에.

오늘 날 우리는 허무맹랑한 것이 아니라면 상상할 수 있는 그 어떤 것이든 만들어 낼 수 있다. 우리는 제품을 만들 때 더 이상 만들 수 있을 지 고민하지 않아도 된다. 이제 우리가 고민할 것은

"이것이 세상에 태어날 필요가 있는가?"

다.

우리는 성공하는 스타트업에 대해 잘못 이해하고 있다. 처음부터 완벽한 플랜 A를 설계하고 시작해서 성공했다고 생각하거나, 그들이 플랜 A를 시도하는 과정에서 우연히, 혹은 직감적으로 다른 플랜 B를 발견했다는 등의 생각이 바로 그것이다. 물론 그런 회사가 있다는 것은 부정하지 않지만 성공은 운 뿐만이 아니다. 플랜 A의 엄격한 검증과 체계적 과정을 통해 다른 플랜으로의 방향 전환, 혹은 완벽한 계획에 가까이 가는 것이 가능한 것이다.

스타트업이 성공하려면.

점진적 혁신, 실패와 학습.

미래를 내다보고 완벽한 과정을 설계해 내는 천재적인 사람 따위는 없다. 점진적인 혁신과 실패를 통해서 배워가야 한다.

고객의 피드백을 자주 받아라.

초기 요구 사항 수집단계 이후, 고객 검증은 제품 완성 후 단계로 미뤄지는 경우가 많다. 스타트업이 제품을 만들고 테스트 할 동안(이를 중간단계라 한다.) 고객과 격리된다. 이는 매우 좋지않은데, 이 사이에 고객이 원하지 않는 제품으로 바뀔 확률이 매우 높기 때문이다. 이를 막기위해 최대한 고객과 자주 만나야한다.

단지 묻기만 해서는 안된다.

고객이 원하는 것은 고객도 알지 못한다. 그것을 정확히 캐치해 내는 것은 우리의 일이다. 헨리포드는 이런 말을 했다.

만약 사람들에게 무엇을 원하는지 물었다면, 사람들은 더 빠른 말이 필요하다고 답했을 것이다.

이 말을 고객이 원하는 것은 고객도 모르니 물어볼 필요가 없다고 해석해선 안된다. 더 빠른 말이 대안적인 더 빠른 무엇인가라는걸 캐치하고 그것이 니즈라는 걸 파악해야 한다. 고객은 답을 알고 있지만 그냥 주지 않으며, 그 답을 정리해서 내놓는 것은 고객의 일이 아니다.

린 경영의 중요한 세가지 개념.

린 경영이란 아이디어를 검토해 더 빠르게 성공적인 제품을 만들어가는 방법이다. 즉 플랜 A를 좀 더 완벽히 만들어가거나, 성공적인 플랜 B로 바꿔나가거나 하는 것을 가능하게 해주는 것이다.

1. 고객개발

간단히 말해

사무실 밖으로 나가라

다. 고객을 만나란 뜻이다. 고객과 계속해서 피드백을 하는 피드백의 고리를 구축해라. 그것이 가장 중요한 첫 번째 린 경영의 핵심 개념이다.

2. 린 스타트업

시간의 사용을 최적화 하는데 주력하는 것을 의미한다. 목표는 단위 시간당 고객에 대한 학습의 극대화를 추구하는 것이며, 빠른 반복 개선 작업으로 빠르게 가설 혹은 아이디어를 검증해 나가는 과정을 일컫는다.

3. 부트스트래핑

외부 투자, 혹은 자금 규모를 최소화 하는 것을 위해서는 매출을 통해 자금울 충당하여야 한다. 이를 위한 기법들의 집합을 의미한다.

참고로 사전적인 부트스트래핑의 의미는 단순한 것을 기반으로 점점 복잡한 것으로 나아가는 것을 의미한다.

비밀리에 제품을 구축하지마라.

멍청한 생각이다. 아이디어를 훔칠지도 모른다고 걱정하는데, 상대방은 당신의 이야기를 듣고 그 아이디어에 대해 정확한 잠재력을 가늠치도 못하며, 사실은 상대는 당신 아이디어 따위에 관심도 없다. 이야기를 듣고 개선해 나가는 것이 더욱 중요하다.

Introducing. Stack. / 스택 자료구조

youngkyu.cho — Fri, 7 Nov 2014 22:49:13 +0900

~~Edit~~

Introducing. Stack.

본 스터디는 열혈강의 자료구조 - 프리렉이란 교재로 진행된다. 더욱 자세한 내용은 해당 책을 참고하기 바란다. 정말 괜찮은 책이다.

스택을 소개합니다.

영어 단어로 더미(Stack).
가장 대표적 성질은 나중에 들어간게 먼저 나온다. (Last-In-First-Out;LIFO;리포)
같은 성질인데 말을 조금 바꾸면 ‘먼저 들어간게 나중에 나온다’ (First-In-Last-Out;FILO)
선형 자료구조 : 앞뒤 자료가 1:1
꺼내는 것(반환)과 삭제, 추가는 스택의 제일 위에서만 가능하다.

스택의 개념

위키피디아에서 설명하는 스택.

스택은 한방향으로 쌓는 자료 구조이다. 새로운 자료를 스택에 추가하는 것을 push라고 한다. 그리고 스택에서 자료를 꺼내는 것을 pop이라고 한다. 이때 꺼내지는 자료는 최상단(가장 마지막에 들어간)의 자료다. 이때 말하는 가장 마지막에 삽입된 자료를 top이라 한다. 그리고 그 마지막 자료를 꺼내지 않고 보기만 하는 것을 peek라 한다.

푸시(push)연산.

| |
| |
|B| <- top
|A|

이렇게 생긴 스택 공간이 있다고 하자. 자료 C를 추가하게 되면,

| |
|C| <- top
|B|
|A|

로 바뀌게 된다. 아래서 부터 인덱스를 붙이면 2번자리에 C가 저장됨을 알 수 있다.

스택의 크기란 스택에 저장할 수 있는 최대의 자료 개수를 말한다. 최대 갯수가 제한이 있기 때문에 이 한도를 초과해서 추가하려고하면 추가될 수 없는 경우가 발생한다. 이 경우를 overflow현상이라 이야기한다.

팝(pop)연산.

다음으로 팝 연산에 대해 살펴보도록 하자. 팝은 스택에서 자료를 꺼내는 것을 말한다. 이러한 팝 연산은 스택의 제일 위에서만 발생한다.

| |
|C| -> pop
|B| <- top
|A|

| |
| |
|B| <- top
|A|

위는 저장된 자료가 팝 연산에 의해 반환 되는 과정이다.

만약 아무 자료가 저장되지 않은 상태(empty 상태)에서 팝 연산을 호출하면 어떻게 되야할까? 아마도 아무자료가 없으니 제거할 자료가 없는 상황이 될 것이다. 이런 상황을 underflow현상이라고 말한다.

피크(peek)연산.

팝과 유사한 연산이다. 그러나 자료를 제거하지않고 단지 반환만 받을 수 있다는 점에서 차이가 있다.

| |
|C| <- top / -> peek
|B|
|A|

| |
|C| <- top
|B|
|A|

탑을 이용하여 스택의 최상위에 있는 가장 최근에 삽입된 자료를 반환한다. 오직 반환만 한다는 점에 주목하라.

스택의 추상 자료형

스택을 실제 사용하기 위해서는 다음 표에 있는 기능들이 필요하다.

이름	Operation	Input	Output
스택 생성	createStack()	스택의 크기 n	스택 s
스택 삭제	deleteStack()	스택 s	N/A
원소 추가 가능 여부	isFull()	스택 s	T/F
공백 스택인지 여부	isEmpty()	스택 s	T/F
푸스	push()	스택 s, 원소 e	성공/실패 여부
팝	pop()	스택 s	원소 e
피크	peek()	스택 s	원소 e

Introducing. List. / 리스트 자료구조

youngkyu.cho — Fri, 7 Nov 2014 22:48:03 +0900

~~Edit~~

Introducing. List.

본 스터디는 열혈강의 자료구조 - 프리렉이란 교재로 진행된다. 더욱 자세한 내용은 해당 책을 참고하기 바란다. 정말 괜찮은 책이다.

Introducing. List.

리스트 자료구조.

리스트 : 가장 단순한 자료구조지만 가장 널리 사용되고 기초적인 자료구조. 스택, 큐, 트리, 그래프 등 다른 여러 자료구조 구현에도 사용됨.

리스트는 자료가 Sequential하게 연결된 선형구조를 의미.

배열은 가장 쉬운 리스트 자료구조이다.

자료의 제거.

예를 들어 배열(Array)에 자료가 순서대로 정리되어 있다 생각해 보자.

|A|B|C|D|E|

여기에서 내가 C를 제거하게되면, 그 자리가 비게되고, 그걸 매꾸기위해 뒤에서부터 차례대로 한칸씩 앞으로 밀어줘야한다.

|A|B| |D|E| => |A|B|D|E| |

3번째 C자리게 계속 그냥 비어있어도 되지 않을까?
그런데 그렇게 되면 문제가 생긴다. 배열상에 공간이 있지만 그 공간이 비어있는지를 확인할 수 없어 그 자리에 자료를 추가하기가 힘들어진다.

자료의 추가.

마찬가지 예시를 보며 확인해 보자.

|A|B|C|D|E|

여기에 X를 추가하고 싶다고 하자. 하필 추가하고 싶은 곳이 C와 D 사이라면 어떨까?

|A|B|C|D|E| |
|A|B|C| |D|E|
|A|B|C|X|D|E|

먼저 한칸씩 D와 E를 밀어서 자리를 확보한다. 물론 이때 배열에 여유 공간이 있어야 한다. 없다면 추가가 불가능하다. 그리고 삽입하면 끝.

리스트 자료구조의 포인터를 이용한 구현.

리스트 자료구조는 아래 모식도와 같이 포인터를 이용하여 구현도 가능하다. 포인터로 구현시 배열과 달리 고정된 사이즈가 아니므로, 동적으로 할당하여 제한 없이 자료를 저장할 수 있다. 뿐만 아니라 중간에 있는 자료를 제거하거나 추가할 때, 포인터만 재설정하면 되므로 배열 리스트에서 처럼 중간 공백을 없애기 위한 자료의 이동도 불필요하다.

리스트의 추상 자료형.

	Operation	입력(input)	출력(Output)
리스트 생성	createList()	최대 원소 개수 n	리스트 l
리스트 삭제	deleteList()	리스트 l	N/A
원소 추가 가능 여부	isFull()	리스트 l	T/F
원소 추가	addElement()	리스트 l, 원소 위치 p, 원소 e	성공 or 실패 여부(T/F)
원소 제거	removeElement()	리스트 l, 원소 위치 p	성공 or 실패 여부(T/F)
리스트 초기화	clearList()	리스트 l	N/A
원소 갯수	getListLength()	리스트 l	원소의 개수
원소 반환	getElement()	리스트 l, 원소 위치 p	원소 e

책 저자가 객체 지향 프로그래머라 그 스타일을 쓰려고 하는지, 굳이 동적으로 배열을 할당하고 해제한다. 깊이 담긴 이유는 모르겠다. 그냥 미리 선언된 배열로 해도 되는데.

인덱스는 0번부터 시작(0-based-index)하는게 원칙이다. 따라서 원소 위치 p는 0번부터 시작해야한다.
그리고 디버깅 용도로 사용할 전체 원소를 보여주는 displayList()등이 필요할 수도 있다.

TF-IDF(Term Frequency - Inverse Document Frequency) / 단어 빈도와 역문서 빈도.

youngkyu.cho — Fri, 7 Nov 2014 22:45:00 +0900

~~Edit~~

TF-IDF(Term Frequency - Inverse Document Frequency) / 단어 빈도와 역문서 빈도.

뉴스 추천 알고리즘을 설계하면서 초기에는 크게 고려하지 않았지만 차차 고려하게된 부분이 바로 이 TF-IDF이다. 뉴스 추천을 하기위해 각 기사에 들어있는 단어들(키워드 혹은 엔티티들)을 은전한닢이라는 형태소 분석기를 사용하여 분리했는데, 이 형태소 분석기의 단어 분류가 정확하지 못해 은전한닢이 자체 제공하는 단어 분류 tag만으로는 제대로 분리할 수 없었다. 이를 보완하기 위해 모든 명사단어들을 뽑아내려고 했는데, 이때 의미없는 엔티티가 포함될 확률이 매우 높았다. 이것을 해결하기 위해 고민하던 중 정보검색 분야에서 사용되는 TF-IDF를 알게 되었다.

TF-IDF(Term Frequency - Inverse Document Frequency)

보통 정보 검색이나 텍스트 마이닝에서 주로 사용한다. 이것을 이용하면 해당 엔티티(단어)가 가지는 중요도를 알아낼 수 있다. 어떤 단어가 특정 문서 내에서 얼마나 중요한 것인지를 표현해 주기 때문이다.

TF는 단어빈도로, 특정 단어가 문서내에 얼만큼의 빈도로 등장하는지를 나타낸다. 당연하게도 문서에 자주 등장하는 엔티티라면 엔티티로서의 값어치가 높다고 예상할 수 있다. 매우 직관적으로 이해할 수 있는 관계다.

IDF는 문서 빈도의 역수다. 전체 문서 갯수를 해당 엔티티가 포함된 문서의 갯수로 나누는 것이다. 이것은 해당 문서군의 특징을 보여주는 척도가 될 수 있다. 어떤 문서 내에 클라라라는 단어가 자주 등장했다고 생각해보자. 아마 이 문서군은 연애 기사들의 모음일 가능성이 충분히 있을 것이다. 따라서 이 값을 통하여 해당 문서군에서 가치 있는 엔티티를 찾아낼 수 있는데, 만약 해당 문서군에서 드물게 등장하는 단어가 무엇인지 알수 있다면, 아마 그 단어가 어떤 그 문서군에서 특정 한 문서를 유니크 할 수 있도록 해주고, 눈에 띄게해주는 단어일 확률이 높기 때문이다.

구하는 법.

TF-IDF는 단어빈도와 역문서 빈도의 곱이다. 처음 접할 때는 -가 있어서 둘이 빼는 건가 했는데 그게 아니었다.

Term Frequency

두 값을 산출하는 방법에는 여러가지가 있는데, 단어를 나타내는 id값을 t라고 하고, 문서(도큐먼트)에 특정히 할당된 id값을 d라고 해보자. 말이 어려운데 간단하게 말하면 그 문서 일련번호고, 단어 일련번호다.

그리고 d와 t를 입력 받아 단어 빈도를 계산하는 함수 tf()를 생각해보자. tf(t,d)라 쓸 수 있을 것이다. tf(t,d)를 내부적으로 구현하는 방법은 여러가지다.

그중 가장 간단한 아이디어를 보자. 당연하게도 단어 빈도이므로, d문서 내의 단어 t의 총빈도를 구해주는 함수를 f(t,d)라 하면, 이는 tf(t,d)와 같은 함수라 생각할 수 있다. 그러나 이 값은 너무 커질 수도 있고 정규화가 전혀 되지 못한 값이라 다루기 불편하다. 예를들면 그 문서에 애플이 10번 나오면 10을 tf()값으로 쓰는 것이다. 더 커지면 어쩌나.. 따라서 조금 더 발전된 방법이 필요할 수 있다. 사실 필자는 이 아이디어 그대로를 유사 기사를 묶는 기능의 코드에서 사용하였는데, 간단한 아이디어임에도 매우 높은 정확도를 보여주었다.

다른 방법으로는 불린 빈도라는 방식이 있다. 단어 t가 도큐먼트 d에 한번이라도 나타나면 1, 나타나지 않으면 0으로 표기하는 방법이다. 이 방법의 단점은 아무래도 한번 나타난 애나, 3번 나타난 애나 똑같은 무게를 가진다는 점일 것이다.

숫자가 너무 커질 수 있으므로 작게 만드는 매우 기본적인 아이디어는 로그다. log를 씌우게 되면 매우 작은 수로 숫자를 바꿀 수 있다. 이를 로그 스케일 빈도라 한다.

증가 빈도라는 것도 있는데, 이것은 문서의 길이에 따른 단어의 상대적 빈도를 표현해주는 방식이다. 이 방식을 이용하면 스케일이 최대 1로 고정되는 효과를 얻을 수 있다. 실제로 필자가 뉴스 추천를 위해 엔티티의 TF-IDF를 구현하면서 사용한 방식이기도 하다. 수학 식은 따로 있지만 이해하기 좋도록 한국말(?)로 적었다.

tf(t,d) = 0.5 + 0.5 x f(t,d) / (문서 내 단어들의 f(t,d) 값 중 최댓값)

Inversed Document Frequency

역문서 빈도는 단어가 문서 집합 내에서 얼마나 자주 등장하는지를 나타낸다. 전체 문서 중 발생하는 빈도를 역수 취한 값으로, 역수를 취하다 보니 값이 무한히 커질 수 있기에 이를 방지하려고 log를 씌워 값을 줄인다.

D는 전체 문서들의 집합을 의미한다.

idf(t,D) = log ( 전체 문서의 갯수 / 단어 t가 포함된 문서의 수 )

TF-IDF

tfidf(t,d,D) = tf(t,d) x idf(t,D)

간단히 구한 두개의 함수를 곱하면 된다. 특정 문서 내에서 단어 빈도가 높고, 전체 문서에서 그 단어가 포함된 문서가 적다면 이 값은 높아진다. 따라서 이 값을 이용하면 흔한 단어를 걸러 낼 수 있다. 특정 단어를 포함하는 문서가 많을수록 로그안의 값(idf()에서)이 1에 가까워지게 되고, 이 경우 TF-IDF 값은 0에 가까워지게 된다.

실제로 구현하고 사용하며.

파이썬으로 구현시 생각보다 매우 간단하게 구현이 가능하다. 그 값은 무한정 커질 수 있을 것 같았는데 5를 넘는 경우가 없었다. 이것은 문서 집합의 특성에 따라 달라 질 수 있다. 또 로그를 사용할 때 밑이 무슨 로그인지에 따라 다를 수 있다. 필자는 밑이 10인 상용로그를 취해주었다. 사실 이것은 상대적인 비교이므로 밑이 몇인 로그를 취하는가는 그렇게 중요한 문제는 아니라 생각된다. 아래는 필자의 코드다. 현재는 이것보다 훨씬 리팩토링 되어 본래의 구조를 조금 잃었지만, 이게 처음 짰을 때 코드다.

def f(t,d):
    return float(article_entity_count_dict[d][t])

def tf(t,d):
    return 0.5 + ((0.5) * f(t, d) / max([f(w, d) for w, c in article_entity_count_dict[d].iteritems()]))

def idf(t):
    return math.log10(category_number_of_documents[entity_category_count_dict[t]] / len(entity_article_count_dict[t].keys()))

자료구조란? / 알고리즘이란? / 시간복잡도(Time complexity) / 빅오 표기법

youngkyu.cho — Wed, 29 Oct 2014 02:47:57 +0900

~~Edit~~

Introducing. Data Structure

Data structure(자료구조)란?

컴퓨터 프로그램의 특징은 2가지로 크게 구별됨.

컴퓨터에 의해서 실행되는 명령들의 집합이란 점.
명령을 수행하기 위해 내부적으로 여러 자료를 저장한다는 점.

즉 프로그램이란 자료(데이터) 집합과 명령(알고리즘) 집합의 집합

효율적 자료구조라는 것.

실행 시간 (Time complexity) 최소화.
저장 공간 (Space complexity) 절약.

여기서 저장 공간의 절약이란 프로그램 실행에 필요한 메모리가 적다는 의미.
실행 시간이란 특정 기능을 하는데 걸리는 시간을 의미.

알고리즘이란?

컴퓨터 명령 자체의 효율성을 증가시키기 위한 절차나 방법.
효율적 알고리즘을 위해서는 좋은 자료구조가 선행되어 바탕이되어야.

자료의 종류. (형태에 따라)

단순 구조. (Primitive Data Structure & Base Data Structure)
정수, 문자열, 실수 등
선형 구조. (Linear Data Structure)
리스트, 스택, 큐, 덱
각각의 자료구조가 선형적으로 연결되있는 것.
앞자료와 뒷자료가 1:1 관계.
비 선형 구조. (Non-linear Data Structure)
계층 구조(Hierarchical Structure) 혹은 망 구조(Network Structure)을 가지는 경우.
트리와 그래프가 포함. 앞뒤자료의 선후관계가 1:1이 아님.
파일 구조. (File Organization)
보조 기억장치에 저장되는 파일에 대한 자료구조.
메모리에 한번에 올릴(Loading) 수 없는 대용량의 자료를 대상으로 함.
순차적 파일 구조(Sequential), 상대적 파일 구조(Relative), 색인 파일 구조(Indexed Sequential) 및 다중키 파일 구조(Multi - key)등이 있다.

추상 자료형. (Abstract Data Type.)

정보은닉(Information Hiding)을 위해 사용. 중요한 정보만 나타내고 중요하지 않은 정보는 숨기는 방법.

자료와 자료형

자료와 자료형은 다르다! 뭔가 별거아닌데 충격적.

자료 + 연산 = 자료형
data + operation = data type
예) 정수 자료형 = 자료 (1,2,3,-1,-2등등) + 연산 (더하기, 빼기, 곱하기, 나누기, 나머지연산)

추상자료형

추상적으로 정의된 자료형. 미술에서 추상화는 사물을 사실적으로 그리지 않고 사물의 본질 혹은 두드러진 특성을 관념적으로 그리는 것 의미. 이와 유사하게 세부적이고 복잡한 것을 생략하고 중요한 것만 나타낸는 것.

예) 추상 자료형 콕 찌름 메세지(페이스북 콕 찌르기).

자료 3개.
콕 찌른 시간.
보내는 이.
받는 이.
명령 :

이름	입력	출력	설명
변경()	찌름 메세지 p, 변경 보내는 이 s, 변경 받는 이 r, 변경 시간 t	T/F	보내는 이와 받는 이 변경. 존재하지 않는 회원일 경우 실패
비교()	찌름 메세지 p	T/F	두 메세지가 같은지 비교.

알고리즘

문제를 해결하기위한 절차.
5가지 특성을 필수로 가지게 됨.

입력(Input) : 입력되는 자료가 0개 이상.
출력(Output) : 1개 이상의 출력값 가져야.
명백성(Definitenness) : 각 명령어는 모호하지 않아야.
유한성(Finiteness) : 한정된 수 단계이후 종료되어야.
유효성(Effectiveness) : 모든 명령은 실행 가능해야.

알고리즘의 표현 방법.

자연어(Natural Language) : 사람이 사용하는 일반적 언어.
순서도(Flow Chart) : 알고리즘의 도식화
의사 코드(Psudo Code) : 가상의 프로그램 언어로 표현
프로그래밍 언어

알고리즘의 분석 기준

== 시간 복잡도와 공간 복잡도
현대의 컴퓨터 과학에서는 시간 복잡도를 공간 복잡도보다 대부분 우선시.

시간 복잡도 : 알고리즘 실행에 걸리는 시간.
실제 시간 측정 or 실행되는 명령문의 개수를 계산.
실제 시간 측정의 경우 간단하게 측정 가능하지만 컴퓨터 성능에 종속적. -객관성 낮음
그래서 실행되는 명령문 개수를 기준으로 판단 -->> N에관한 관계식으로 표현.

사실 일반적으로 시간 복잡도는 == O(빅 오;Big-Oh notation)다.

연습문제

(in 열혈강의 자료구조 - 프리렉)

선형 구조에 속하는 자료구조와 비 선형 구조에 속하는 자료구조를 각각 적어보세요.
선형 구조 : 리스트, 스택, 큐, 덱
비 선형 구조 : 트리 (Hierartchical Structure), 그래프 (Network Structure)
다음과 같은 연산자를 포함하는 MP3 플레이어의 추상 자료형을 설계해 보세요.
```
 Play, Stop, Pause, Add_MP3, Delete_MP3, Get_MP3_Count
```
자료 : 곡 목록, 불리언 형 플래그(재생중인지), 현재 재생 중 곡 번호, 재생 시간
연산 :
play(mp3) : 0번부터 재생.
stop(mp3) : 멈춤.
pause(mp3) : 현재 재생중 곡번호, 재생시간에 데이터 넣고 플래그 off로.
Add_MP3(mp3) : 곡 목록 추가
Delete_MP3(mp3) : 현재곡 삭제
Get_MP3_Count(mp3) : 곡 목록 사이즈 반환.
알고리즘의 정의는 무엇인가요? 그리고 알고리즘이 만족시켜야 할 5가지 특징은 무엇인가요?
문제를 해결해 나가는 절차.
입력, 출력, 명백성(Definiteness), 유한성(Finiteness), 유효성(Effectiveness)
다음과 같은 소스가 있다고 할 때, 다음 질문에 답해보세요.
(1) n에 대한 시간 복잡도 함수를 구해보세요. 단, 덧셈, 곱셈, 나눗셈등 연산 횟수를 정확히 고려해야 합니다.
```
 2n *  3n + n + 1
```
= 6n^2 + n + 1
(2) 빅-오 표기법으로 시간 복잡도를 나타내 보세요.
```
 for(;i<n;i<-i+1){
     for(j<-0;j<n;j<-j+1){
         sum <- sum + j;
     }
 }
```
= O(n^2)
다음 시간 복잡도 함수들을 빅-오 표기법으로 나타내 보세요.
```
 6n^3 + n! + 5n + 4 O
```
= n!
```
 4nlogn + 5n^2 + 2 O
```
= n^2
```
 2^n + n^3 + 5 O
```
= 2^n
다음을 실행 시간이 적게 걸리는 순으로 나열하세요.
```
 O(n)  O(n^2)  O(n^3)  O(n!)  O(logn)  O(2^n)  O(nlogn)
```
= O(logn) O(n) O(nlogn) O(n^2) O(n^3) O(2^n) O(n!)

스터디에서 토론한 것.

데이터구조는 알고리즘의 일부다. 그리고 알고리즘은 데이터 구조의 일부다. 서로가 서로에게 영향을 미치는 관계라고 생각한다.
알고리즘을 통해 데이터구조를 구현. 따라서 상호 보완적. 결국 서로는 서로와 동등한 지위를 갖는다 생각.
프로그램 랭귀지로 알고리즘 구현시 명백성을 자동으로 포함시킬 수 있다. 당연히 컴퓨터에 시켜야 하니까.
무한 동작한 행위는 알고리즘이라고 하지 않는다. 이게 좀 특이한 듯.
형식이 있다고들 하는데 psudo code는 형식이 필요없다고 생각한다. 사람마다 다를 수 있지만 서로 알아볼 수 있으면 된 것 아닌가?
자연어는 설명을 쭉 쓰는 건데 한 눈에 보기 힘들기에 별로 좋지 않을 수 있지만 전체적 흐름과 그 함수의 특성을 러프히 설명할 때 유용할 듯.
- 그런데 그렇게 되면 알고리즘이 아니잖아. 명백성이 없어지니까.
프로그래밍언어는 알고리즘 표현에서 당연한 것.
- 당연하지 않아. psudo code나 순서도로 표현하고 그걸 정리해서 구현 할 수도 있어. 반드시 코딩을 해야하는 건 아닌듯.

Pymongo tutorial (파이몽고 사용하기) / pymongo 번역

youngkyu.cho — Wed, 29 Oct 2014 02:12:07 +0900

~~Edit~~

Pymongo tutorial (파이몽고 사용하기)

파이 몽고란 파이썬 몽고 디비 드라이버이다. 버전 2.7.2 기준으로 작성되었다.

소프트웨어 마에스트로 프로젝트를 하면서 사용자의 로그를 빠르게 수집해 그것을 처리하기 위해 선택한 디비가 바로 몽고디비다. 이를 컨트롤 하기 위해서는 파이썬 백엔드 언어로 사용하기에 파이썬 몽고 디비 드라이버가 필요했다. 딱 구글신께 물어보니 파이몽고를 알려주사, 튜토리얼을 따라해보기로 했다.

하는 김에 번역도 해봤다. DogFoot번역이므로 필요하면 여기서 원문을 볼 수 있다. 그래도 번역가처럼 이해하기 좋게 의역도 해놔서 보기는 좋을 듯.

Tutorial

이 튜토리얼에서 몽고디비와 파이몽고의 작동에 대해 배울 수 있을 것이다.

준비물.

먼저 시작하기전에 파이몽고를 깔아야하지 않겠습니까. 파이썬 쉘을 열고 아래의 명령어를 쳐서 Exception이 발생하지 않는지 확인하자.

import pymongo

이 튜토리얼은 몽고디비 인스턴스가 디폴트 포트와 호스트에서 돌아감을 가정하고 진행한다. 몽고디비는 당연히 준비됐겠지? 몽고디비를 실행하라.

$ mongod

MongoClient를 가지고 몽고디비에 연결해보자.

첫번째 스탭은 파이몽고의 MongoClient를 돌고있는 mongod 인스턴스를 위해 만들어주는 것이다. 아래를 따라해라.

from pymongo import MongoClient
client = MongoClient()

위 코드는 디폴트 호스트와 포트에 연결 할 것이다. 만약에 디폴트 설정이 아니거나 명시적으로 표시해주고 싶다면 아래를 참고할 것.

client = MongoClient('localhost', 27017)

혹은 몽고디비 URI 포멧을 이용하여 적을 수도 있다!

client = MongoClient('mongodb://localhost:27017/')

데이터베이스 얻어오기.

몽고디비의 한 인스턴스는 독립적인 데이터베이스를 여러개 만들 수 있도록 해준다. 따라서 그중 어떤 데이터베이스를 가져올지는 아래를 따라해라. MongoClient 인스턴스를 이용해서.

db = client.test_database

test_database에 넣고 싶은걸 넣어라. 설마 저걸 따라치면 안된다.
만약 데이터베이스 이름이 저런식으로 표현이 안된다면 아래처럼도 가능하다.

db = client["test_database"]

컬렉션 가져오기.

컬렉션은 도큐먼트의 그룹이다. RDB의 데이터베이스와 얼추 비슷하게 생각하면 된다. 파이몽고로 컬렉션을 가져오는 방법은 아래와 같다.

collection = db.test_collection

당연하다. test_collection이라 넣으면 안된다. 넣고싶은걸 넣어라.
혹은 위에 데이터베이스에서 가져왔듯이 아래처럼도 가능하다.

collection = db["test_collection"]

몽고디비의 컬렉션이나 데이터베이스에서 중요한 것은 게으르게 생성된다는 것이다. (필요할 때가 되서야 억지로 생성된다는 것!) 위의 명령중 어느것도 몽고디비와 실제로 어떤 일도 수행하지 않는다. 컬렉션과 데이터베이스들은 첫 도큐먼트가 걔네들에 insert될 때 생성된다.

도큐먼트(문서)

몽고디비 안에 데이터는 JSON스타일로 저장된다. 파이 몽고는 파이썬의 딕셔너리를 활용해서 표현한다. 아래 예시처럼 말이다. 블로그 포스트를 의미하는 예시다.

import datetime
post = {
    "author" : "Mike",
    "text" : "My first blog post!",
    "tags" : ["mongodb", "python", "pymongo"],
    "date": datetime.datetime.utcnow()
}

기억하라. 도큐먼트(문서)는 네이티브 파이썬 타입(위의 datetime.datetime 인스턴스 같은)을 가지고 있을 수 있다. 이것은 자동적으로 BSON 타입으로 컨버팅되고, 또 컨버팅해서 가져온다.

도큐먼트에 Insert를 해보자.

도큐먼트에 insert를 하기 위해서 우리는 insert()란 메소드를 쓸거다.

posts = db.posts
post_id = posts.insert(post)

매우 간단하다. 만약 도큐먼트가 _id키를 가지고 있지 않다면 몽고디비가 알아서 도큐먼트에 특별한 _id 키를 부여해서 자동으로 인서트 된다. _id는 무조건 유니크해야한다. insert 메소드는 insert시 특별히 부여된 _id를 반환한다. 더 많은 정보가 필요하다면 몽고디비 사이트의 _id를 보라.

이게 처음 넣은 것이므로 그제서야 posts컬렉션이 실제로 몽고디비서버에 생성된다. 우리는 이제서야 우리 database에 posts 컬렉션이 리스트에 있음을 확인 할 수 있다.

>>> db.collection_names()
[u'system.indexes', u'posts']

system.indexes 컬렉션은 스페셜한 내부 컬렉션으로 자동으로 생성된다.

find_one()으로 한 도큐먼트 얻어오기.

가장 기본적인 타입의 몽고디비 쿼리가 바로 find_one()이다. 이 메소드는 쿼리가 매칭되는 하나의 도큐먼트(문서)를 가져오는 애다.
(mysql-connector를 파이썬에서 써봤다면 select_one()과 비슷한 애.)
만약 매치되는게 없다면 None 을 반환한다.

이것은 매우 유용한데 네가 만약 처음 매칭되는 도큐먼트나, 그 쿼리와 딱 맞게 하나만 존재하는 도큐먼트를 들고오고 싶을 때 정말 딱이다. 여기는 find_one()으로 posts컬렉션의 첫번째 도큐먼트를 들고오는 예제다.

>>> posts.find_one()
{u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}

이 결과는 파이썬 딕셔너리로 반환된다.
리턴되는 도큐먼트에는 자동적으로 insert시 부여된 _id값이 같이 딸려온다.

find_one()은 특정 성분(앨리먼트)의 매칭 쿼리도 지원한다. 아래는 "Mike"가 author인 거 들고오는 예제다.

>>> posts.find_one({"author": "Mike"})
{u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}

만약 없는 author를 시도한다면 아무 결과물도 안나올 것이다.

>>> posts.find_one({"author": "Eliot"})
>>>

ObjectId로 쿼리하기.

우리는 _id로도 쿼리할 수 있다.

>>> post_id
ObjectId(...)
>>> posts.find_one({"_id": post_id})
{u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}

ObjectId오브젝트 아이디는 string이 아니다.
만약 아래와 같이 쿼리하면 아무것도 안나온다.

>>> post_id_as_str = str(post_id)
>>> posts.find_one({"_id": post_id_as_str}) # No result
>>>

웹 애플리케이션에서 가장 많이 하는 작업은 아마 ObjectId을 요청 URL을 가지고 받아와 매칭되는 도큐먼트를 찾는 일일 것이다. 이때는 ObjectId로 string을 바꿔서 find_one()에 줘야 한다.

from bson.objectid import ObjectId

# 웹 프레임워크로부터 post_id 받아오기. 이건 string일 것.
def get(post_id):
    # string을 ObjectId로 바꾸기.
    document = client.db.collection.find_one({'_id': ObjectId(post_id)})

참고 : When I query for a document by ObjectId in my web application I get no result

유니코드 String에서 주의할 점.

파이썬 string을 우리가 저장할 때 다른 형태로 저장된다는 걸 너는 아마 눈치 챘을 것이다. u'Mike'같이 원래'Mike'였던 애를 이상한 기호를 붙여 저장 하는 것 같이 말이다. 꺼내 올 때도 그렇게 보일 것이다. 여기서 짧게 설명 좀 하고 가야겠다.

몽고디비에 저장된 데이터는 BSON 포멧이다. 이 포멧의 string은 UTF-8로 인코딩되어 있는데, 파이몽고가 유효한 UTF-8 데이터만을 담아서 전달해 준것이다. 물론 이 과정에서 원래의 string(<type 'str'>)의 정보는 전혀 바뀌지 않는다. 유니코드(<type ‘unicode’>)는 UTF-8로 우선 인코딩된다. 우리의 예제의 string들이 u가 앞에 붙은 형태로 string이 나타나는 것은 pyMongo가 BSON string을 파이썬의 unicode로 바꿔 보여주기 때문이다. 'Mike'와 같은 일반적인 string이 아니라!

더 궁금한 사항은 여기를 참고하라.

통째로 insert하기.

몇개의 도큐먼트를 동시에 인서트해보자. 우리는 bulk insert operations를 하나의 도큐먼트를 넣는 것 처럼 할 수 있다. insert()에 첫번째 인자로 iterable을 넣기만 하면 준비 끝! 이것은 각 도큐먼트를 돌며 알아서 insert해 줄 것이다. 하나의 명령으로 말이다.

>>> new_posts = [{"author": "Mike",
...               "text": "Another post!",
...               "tags": ["bulk", "insert"],
...               "date": datetime.datetime(2009, 11, 12, 11, 14)},
...              {"author": "Eliot",
...               "title": "MongoDB is fun",
...               "text": "and pretty easy too!",
...               "date": datetime.datetime(2009, 11, 10, 10, 45)}]
>>> posts.insert(new_posts)
[ObjectId('...'), ObjectId('...')]

이 예제에 관한 흥미로운 사실 2개가 있다.

insert()를 여기서 부르면 2개의 들어간 각각의 ObjectId가 반환된다.
news_posts[1]은 모양이 조금 다른데, tag가 아닌 title을 가지고 있다. 이게 바로 몽고디비에서 맨날 말하는 그 '스키마가 없다'다!

한 도큐먼트 이상에게 쿼리 던지기

find()함수를 통하면 한개의 도큐먼트 이상을 위한 쿼리를 던질 수 있다. find()는 Cuser Instance를 반환하는데, 이것은 도큐먼트들을 순회(iterate)할 수 있도록 해준다. 예를들어 아래처럼 우리는 posts 컬렉션을 싹 순회할 수 있다. (iterate 할 수 있다.)

>>> for post in posts.find():
...   post
...
{u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}
{u'date': datetime.datetime(2009, 11, 12, 11, 14), u'text': u'Another post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'bulk', u'insert']}
{u'date': datetime.datetime(2009, 11, 10, 10, 45), u'text': u'and pretty easy too!', u'_id': ObjectId('...'), u'author': u'Eliot', u'title': u'MongoDB is fun'}

find_one()처럼 우리는 find()를 통해 결과에 필터(제한)을 걸 수 있다. 예를 들어 MIKE라는 author를 꺼내보자.

>>> for post in posts.find({"author": "Mike"}):
...   post
...
{u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}
{u'date': datetime.datetime(2009, 11, 12, 11, 14), u'text': u'Another post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'bulk', u'insert']}

갯수 세기.

만약에 쿼리에 매칭되는 도큐먼트의 갯수만 궁금하다면, 너는 count()를 사용해서 긴 쿼리를 통하지 않고도 알아 낼 수 있다.

>>> posts.count()
3

혹은 상세 쿼리를 던져서도 알아낼 수 있다.

>>> posts.find({"author": "Mike"}).count()
2

다양한 쿼리를 쓸 수 있다.

몽고디비는 다양한 향상된 쿼리를 제공한다. 해당 날짜 이후의 도큐먼트들을 날짜 순으로 정렬하고 그걸 또 author순으로도 정렬하는 예를 보라.

>>> d = datetime.datetime(2009, 11, 12, 12)
>>> for post in posts.find({"date": {"$lt": d}}).sort("author"):
...   print post
...
{u'date': datetime.datetime(2009, 11, 10, 10, 45), u'text': u'and pretty easy too!', u'_id': ObjectId('...'), u'author': u'Eliot', u'title': u'MongoDB is fun'}
{u'date': datetime.datetime(2009, 11, 12, 11, 14), u'text': u'Another post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'bulk', u'insert']}

여기서 우리가 사용한 &lt 연산자가 쿼리의 범위를 제한하고 그걸 sort()가 author에 따라 순서대로 정렬했다.

인덱싱

쿼리를 더 빠르게 실행시키기 위해 우리는 index를 date나 author에 대해 생성할 수 있다. 그러기위해 먼저 explain() 메소드를 사용해서 몇가지 정보를 얻어보자. index없이 어느정도의 퍼포먼스가 나오는지 알 수 있다.

>>> posts.find({"date": {"$lt": d}}).sort("author").explain()["cursor"]
u'BasicCursor'
>>> posts.find({"date": {"$lt": d}}).sort("author").explain()["nscanned"]
3

이걸 보면 BasicCursor가 쿼리를 처리하고 있고, 걔가 컬렉션에 있는 3개의 도큐먼트를 쿼리를 처리하기 위해 스캐닝 했다는 점을 알 수 있다.
이제 index를 걸어보자.

>>> from pymongo import ASCENDING, DESCENDING
>>> posts.create_index([("date", DESCENDING), ("author", ASCENDING)])
u'date_-1_author_1'
>>> posts.find({"date": {"$lt": d}}).sort("author").explain()["cursor"]
u'BtreeCursor date_-1_author_1'
>>> posts.find({"date": {"$lt": d}}).sort("author").explain()["nscanned"]
2

이제 쿼리를 BtreeCursor (인덱스)를 처리하고, 오직 두개의 도큐먼트만이 스캐닝 되었다는 사실을 알 수 있다.

MongoDB(몽고 디비) 특징 공부하기 / 몽고 DB란 무엇인가?

youngkyu.cho — Mon, 20 Oct 2014 21:45:15 +0900

~~Edit~~

MongoDB(몽고 디비) 특징 공부하기.

유명하다 못해 모르는 사람이 없을 만큼 많이 입에 오르내리는 디비 중 하나인 몽고디비는 예전부터, 아니 지금도 필자가 자주 사용해 오던 NoSQL이다. 해커톤같이 짧은 시간에 개발할 때에는 스키마가 없으면서 설정도 간단하고 빠른 성능을 가진 몽고디비가 강력강력강력 정말 강력한 데이터베이스로 사용될 수 있다. 두번 사용해야 한다. 그러나 안정성 문제가 거론되며 최근 뒷담하는 개발자가 많은 디비기도 하다. 이참에 특징에 대해 제대로 공부하고 싶어 책을 찾아가며, 인터넷을 뒤져가며 정리해보았다.

문서지향 데이터베이스.

몽고 디비는 강력하고 유연하며 확장성이 높은 도큐먼트 베이스(문서 지향)의 데이터베이스이다. NoSQL 중 매우 유명한 놈이기도 하다. 문서 지향 데이터베이스에서는 행 개념 대신에 보다 유연한 모델인 문서를 이용하는데, 내장 문서와 배열따위의 표현이 가능해서 복잡한 객체의 계층 관계를 하나의 레코드(열)로 표현할 수 있다. 이것은 자바나 파이썬 같은 최신 객체지향 언어들을 사용하는 개발자에 매우 편리함을 가져다 준다.

스키마가 없다.

몽고 디비의 특징 중 가장 유명한 것은 스키마가 없다는 것이다. 이것은 필요할 때 마다 필드를 추가하거나 제거하는 것이 매우 쉬워졌음을 의미한다. 사실은 필드라는게 없는거나 마찬가지니까. 따라서 개발 과정이 매우 단순해지고 빠르게 개발이 가능하게 된다.

스케일 아웃이 가능하다.

소프트웨어 마에스트로에서 뉴스 추천 서비스를 프로젝트로 하고 있다. 언론사들을 크롤러가 돌며 뉴스를 수집하여 개인의 선호에 맞게 추천하는 서비스다. 이때 엄청난 양의 사용자 선호 로그데이터가 필요할 때 마다 필드를 바꾸며 빠른 속도로 쌓여야 하는데, 이때 매우 적합하다고 판정된게 몽고디비다. 데이터베이스에 엄청난 로그가 쌓여야하는데 Scale out도 가능할 뿐더러(디비 자체적으로 지원한다. 이를 염두에 두고 설계되었다. 알아서 문서를 재분배하고 라우팅까지 완벽히 처리한다.) 스키마가 없어 필요할 때 마다 필드를 변형 시킬 수 있기 때문이다.

범용 데이터베이스.

몽고 디비는 범용 데이터베이스 목적으로 만들어 졌다. 따라서 CRUD의 작업외에도 다양한 기능을 제공한다. NoSQL이지만 쿼리가 있다. 조금 더럽긴 하지만. 아래는 몽고 디비가 제공하는 기능 중 일부이다.

인덱싱 제공.
집계 파이프라인의 지원
특수한 컬렉션 유형 제공. (TTL등과 고정크기 컬렉션 등.)
파일 저장소의 지원.

치명적이게도 조인과 트랜잭션 없음.

관계형 데이터베이스에서 당연한듯 멋지게 지원하는 트랜잭션과 조인이 없다. 이것은 정말 치명적인데 몽고 디비는 분산 시스템을 위해 포기했다. 해당 기능들을 제공하는 데에 비용이 크기 때문이다.

매우 고성능이다.

몽고디비는 쓰기와 읽기에서 기존의 RDB의 그것보다 수십배의 성능을 발휘한다. 당연하게도 여러 제약조건에 대한 처리가 없기 때문이기도 한데, 이것을 고스란히 애플리케이션 개발자 혹은 드라이버 개발자에게 맡겼다. 따라서 실제 서비스에서 사용하려면 상당히 많은 공이 필요하다. 손수 다 처리해야하므로. 트랜잭션까지........

낮은 진입장벽. 두번쓰자. 다시보자.

개발에서 가장 힘든건 코딩이 아니라 번역이다. 정말 번역은 사람을 미치게한다. 영어 회화는 모르겠는데 영어 글은 좀 읽는다 생각했는데 안그래도 단어도 잘 모르는데 어려운 단어가 잔뜩 쓰여있는 문서는 곤욕이다. 게다가 쓸데없이 더럽고 사용하기 어렵게 만들어져 있는 API는 왜그리 많은지. 그런데 몽고디비는 깔끔하다. 진입장벽이 낮다. 정말이다.

문서는 RDB의 행(row)다.

아니 사실은 그 이상이다. 엄청난 표현이 가능하다. 몽고디비의 핵심이기도 한 문서는 (키와 값)들의 집합이다. 키 + 값들이 아니라 (키+값)들이다. JSON을 생각하면 매우 간단하다. 그게 그러니까 한줄로 저장되는 거라 생각하면 된다. 어디에? RDB라면 테이블일텐데 여기서는 컬렉션이다. 그러나 몽고디비에서는 데이터 형이 있다.

3와 "3"은 다르게 취급된다.

문서의 키/값의 쌍은 정렬되어 있기에 JSON으로 나타내어 똑같더라도 다르게 취급된다.

{a:1,b:2}와 {b:2,a:1}은 다르게 취급된다.

당연하게도 원래는 저게 똑같게 취급되는 경우가 더 많지만, 얘는 그렇다.

컬렉션은 테이블이다.

문서들이 저장되는 장소가 컬렉션이다. 이름에서 느껴지듯 말이다. 컬렉션은 테이블과 달리 스키마가 없다. 아니 있긴 있다. 사실 아에 규칙없이 컬렉션에 문서를 모으면 재앙이다. 어떻게 컨트롤 할 것인가? 현대의 거의 모든 언어는 타입이 있고 담아올 VO들도 스키마가 있는데 말이다. 그러니 뭐 강제는 안하지만 몽고디비에도 스키마가 있긴 있는 거다.

컬렉션으로 구별해서 저장해 두라는 것. 데이터 지역성 측면에서도, 구분에서도 좋잖아. 그리고 그렇게 해야 인덱스도 효율적으로 만들 수 있다.

뭐야 그럼, 어차피 있구만
이라고 생각할 수도 있는데 뭐 이런거다. 강제로 지키는 것과 자율적으로 지키는 것의 차이?

컬렉션은 테이블처럼 이름을 가진다.

테이블 명 처럼 컬렉션 명이 있다. 이때 서브 컬렉션이라는게 있는데 이건 사실 말뿐인 것이다. RDB로 예를 들어보자. IMAGE가 있고 Thumbnail_IMAGE가 있는데 이걸 하나의 테이블에 넣진 않을 것이다. 그런데 둘다 이미지지 않은가? 몽고디비에서는 이를 위해 이름을 지을 때 '.'으로 둘을 구별하는 것을 권장한다.

서브 컬렉션이라는게 있다!

image가 있고, image.thumbnail 이런식으로 말이다. 근데 두 컬렉션이 관계있다는건 사람이 읽을 때 뿐이지, 몽고 디비가 저 두게를 연결 지어 관리하거나 그러지는 않는다. 전혀 무관. 그냥 이름에 점을 찍을 수 있는 거라고나 할까.

데이터베이스에 컬렉션을 그룹지어 놓는다.

컬렉션은 알겠다. 데이터베이스는 뭐냐? 몽고 디비는 단일 인스턴스를 가지고 여러 데이터베이스를 호스팅 할 수 있다. 이건 뭐 MYSQL도 그렇지 않은가? 예를 들어 우리 팀 이름이 tworoom이라 Mysql과 똑같은 친척(?)인 MariaDB에 tworoom이란 디비를 만들어 두었다 생각해 보자. (실제로 소마에서 우리팀 이름이 tworoom이고 실제로 tworoom 디비가 있다!)

친구가 근데 해커톤을 한단다. 디비가 필요한데 없어서 디비하나만 임시로 만들어달라고 부탁해서 apple이라는 디비를 만들어줬다 치자. 가능한 시나리오지 않은가? 이것과 같은 맥락이다. 몽고디비도 그렇게 쓸 수 있다는 거다. 각 데이터베이스는 독립적으로 취급되며, 자체적인 권한 설정이 가능하고 따로 파일시스템에 하나의 파일로 저장된다. 따라서 64바이트 이내의 이름이 설정 가능하고, 빈 문자열은 불가능하며 파일 시스템에서 지원하지 않는 특수기호는 사용이 불가능하다! 물론 대소문자도 구별된다. 사진파일이나 텍스트 파일등 일반적인 파일이 그렇듯이!

특별한 데이터 베이스들이 있다.

이미 몽고디비가 특수한 용도로 쓰려고 예약해둔 데이터 베이스들도 있다.

admin : 그냥 얘가 우리가 아는 root 데이터베이스다. 여기에 추가된 사용자는 전체 몽고디비 내의 모든 데이터베이스에 대하여 모든 권한을 획득한다. 서버 전역에 걸친 모든 명령어는 이곳에서만 실행 가능하다. 예를들어 디비 목록조회나 시작과 중지등등.
local : 이 디비는 특정 서버에만 보관하는 정보를 담는 곳이다. 복제가 불가능하다.
config : 몽고디비는 자체로 샤딩를 지원한다. 이 디비는 샤드 정보를 저장하는데 사용된다.

여기까지!

공부를 오랜만에 해서 머리가 아프다. 몽고 디비를 막연히 사용만 했지 제대로 이해하려 한 적이 없었는데 기본적인 것을 훑고나니 조금 더 친해진 느낌이다. 더 친근하고 좋구만. 필자 뿐만 아니라 모두가 그랬으면 좋겠다! 더 잘 쓰지 못해 아쉽다.

다음 시간에는 튜토리얼을 같이 해보도록 하자!

간단하게 만들어 본 맥용 지니 플레이어.

youngkyu.cho — Fri, 17 Oct 2014 20:23:36 +0900

~~GeniePlayer.zip~~

맥용 지니 플레이어.

KT 유저가 사용하면 데이터를 무료로 사용할 수 있도록 해줘서 지니를 사용중인데, 맥용 지니 플레이어가 없어 웹으로 사용해야 했었다. 이게 평소에는 큰 문제가 없었는데, 크롬을 사용하는 나는 가끔 모르고 cmd+q를 눌러서 모두다 꺼버리기 일 수 였고, 이게 엄청난 스트레스였다.

좋아하는 음악을 흥얼 거리다 갑자기 꺼져버리니 빡칠 수 밖에!

결국 간단하게라도 만들어서 내가 사용해야 했다.

목표는 2가지.

업무에 전혀 방해되지 않아야 한다. 알아서 꺼지고 필요할 때 열여야 하고 만들기 쉬워야 한다.
지니를 50%이상 정상적으로 이용 가능해야 한다.

서버 백엔드 개발을 해온터라 네이티브 클라이언트 개발은 처음이었고, 더욱이 Objective C는 생소하기 짝이 없었다.

그래서 내가 그나마 해왔던 자바를 가지고 어찌 만들 수 있는 방법을 찾던 중 자바FX를 알게 되었다. 웹뷰만 띄워서 지니 모바일 페이지를 보여주면 모든게 오케이리라 생각하며 자바 FX를 가지고 만들기 시작했고 첫 버전이 그렇게 완성되었다.

그런데 문제가 발생했다.

이상하게도 내가 만든 지니 플레이어를 사용하기 시작하면서 부터 맥이 자주 다운되기 시작했다. 2번째쯤 다운되서 컴퓨터를 강제종료하게되자 원인을 찾기 시작했고 가장 의심스러운 후보인 나의 지니 플레이어를 검사하던 중, 메모리 누수가 엄청나게 일어난다는 사실을 깨닳았다. 거의 노래 1곡당 5메가 이상씩 메모리를 더 점유하고 있었고, 1G를 넘게 먹는 순간도 있었다. 구글링을 해보니 이게 자바FX의 웹뷰 버그인 듯 했다. 결국 방향을 바꿨다. Objective C로 짜자.

그렇게 Objective C를 얕게 공부하기 시작.

꽤 얼마되지 않아 익숙해졌고 약간 다른 문법을 가졌을 뿐 생각보다 쉬웠다. 게다가 XCODE가 너무 좋아서 서브라임텍스트나 이클립스, 파이참등을 사용하던 나는 거의 신세계 수준이었다. (아직 얼마 안써서 그런가..) 사실 안드로이드를 조금 해봤었는데 이거 뭐 XCODE와 애플이 지원하는 거에 비하면 정말 ADT는 쓰레기임에 틀림없었다. 아무튼 왜 애플 앱들이 그렇게 안드로이드보다 좋은지 알게되는 순간이었다. XCODE가 이렇게 탄탄하니..

아무튼 2시간정도를 고군분투한 끝에 간단한 첫번째 버전이 완성되었다.

아주 간편하다. 지니가 제공하지 않는 건 제공하지 못했다.

자동으로 포커스를 잃으면 윈도우 창이 숨는다. 그리고 독바에서 클릭을 하면 다시 윈도우 창이 뜬다. 메모리도 그나마 자바로 짰을때 보다는 적게먹는 편이고(웹뷰는 원래 꽤 먹는듯하다.) 누수도 없다.

몇가지 문제(?)는 존재하긴한다. 먼저 자동로그인이 안되고(지니가 제공하지 않는다.), 쿠키유지를 하지 않아서(이건 지니가 재생목록을 쿠키로 유지해서 벌어지는 문제다.. 왜 쿠키로 하지..) 재생목록이 계속 갱신된다. 물론 맥 특성상 자주 끄지않기때문에 플레이어를 종료하지 않는다면 계속 유지될 것들이라 크게 개의치는 않는다.

필요한 사람이 있을 까봐 여기에 올린다. 가져다가 유용히 쓰길!

지니플레이어 다운로드

RSS 피드 표준의 구조 ( 채널, 아이탬등 )

youngkyu.cho — Tue, 19 Aug 2014 16:37:02 +0900

RSS 표준의 구조

RSS 피드는 크게 두가지로 구성된다. 채널과 아이템이 그것이다.
블로그나 신문사는 채널이 되며, 포스팅과 기사는 아이템이 된다.

Channel의 필수요소

description : 채널의 개략적 설명
link : 채널 사이트 URL
title : RSS 피드의 이름

Channel의 부가적 요소

category : 채널의 카테고리
cloud : cloud에 등록하면 채널의 내용이 업그레이드될 때마다 간단한 출판-구독 프로토콜에 따라 변경된 내용을 받아올 수 있다고 한다.
copyright : 저작권 정보
docs : RSS 피드 관련 문서 주소
generator : RSS 피드를 만든 프로그램의 이름
image : 채널의 상징 이미지 파일의 주소
language : 언어
lastBuildDate : 내용 변경 시각
managingEditor : RSS 관리자 이메일 주소
pubDate : RSS 피드가 만들어진 날짜
rating : 채널의 PICS 등급 http://www.w3.org/PICS
skipDays : RSS 피드를 읽는 프로그램이 며칠만에 한번씩 변경내역을 확인하면 되는지 알려줌
skipHours : RSS 피드를 읽는 프로그램이 몇시간에 한번씩 변경내역을 확인하면 되는지 알려줌
textInput : 화면에 보여줄 텍스트 입력 필드를 지정
ttl : TTL(Time to Live)은 내용을 업데이트 할때까지 얼마만큼의 시간이 남아있는지, 즉 내용을 몇 분까지 캐싱할 수 있는지를 뜻함.
webmaster : 웹마스터의 이메일 주소

Item

( 제목과 설명 둘중 하나는 반드시 존재해야한다. )

author : 아이템을 작성한 작성자의 이메일 주소
category : 아이템에 넣을 수 잇는 하나 이상의 분류
comments : 해당 아이템에 대한 덧글을 볼 수 있는 페이지의 주소
description : 아이템의 내용을 요약한 글
enclosure : 아이템에 첨부된 미디어 파일을 가리킨다.
guid : 아이템에 대한 유일한 아이디
link : 아이템의 주소
pubDate : 아이템을 작성한 날짜
source : RSS 채널의 주소
title : 아이템의 제목

Python MAC에 pypy 설치하기.

youngkyu.cho — Fri, 18 Jul 2014 16:49:50 +0900

PyPy is a fast, compliant alternative implementation of the Python language

파이파이(pypy)는 파이썬으로 만들어진 파이썬 구현이다.

기존의 파이썬 구현인 CPython보다 매우 빠른 속도를 보인다.

https://mirror.enha.kr/wiki/PyPy

자세한 내용은 위의 URL을 통하여 확인할 수 있다.

당연하게도 pypy를 사용하기 위해서는 pypy를 먼저 다운로드 해야한다.

http://pypy.org/download.html

위의 URL을 통해 다운로드 받을 수 있다. pypy는 일반적으로 언급되는 설치라는 과정을 거치지 않고 바로 실행시킬 수 있다. 그러나 약간의 손을 봐서 일반 python처럼 사용할 수 있도록 설정해줄 것들이 있다.

다운받은 압축 파일의 압축을 풀고 열면, bin이란 디렉토리 안에 pypy를 볼 수 있다.

위의 사진에는 다른 것들도 나와있지만 초기엔 pypy파일 외에 pip등등 다른 것들은 없다.

즉 pypy하나만 있을 것이다.

$ ./pypy

라고 쳐서 terminal에서 실행 시켜보라.

이후 이것을 global하게 접근하기 위해서(즉 아무곳에서나 terminal명령어로 실행시키기 위해서) 2가지 방법을 우리는 사용 할 수 있다.

첫번째 방법은,

해당 폴더의 pypy를 환경변수로 등록하여 사용하는 방법.

두번째 방법은

pypy의 바로가기(Symbolic link)를 만들어 직접 os의 명령 프로그램들이 모인 bin(/usr/local/bin)에 등록하여 해당 파일에 접근 할 수 있도록 하는 방법이 있다.

위의 디렉토리에 보이는 pypy를 바로 bin에 넣지 않는 이유는, pypy를이동할 시 pypy가 실행할 때 필요로 하는 라이브러리나 모듈을 pypy가 어디있는지 몰라 찾을 수 없게 되어버리기 때문이다.

환경변수를 등록하는 것 보다는 바로가기로 처리하는 게 더 간편하고 정리가 쉬워 필자는 두번째 방법으로 처리했다.

$ cd /usr/local/bin

$ sudo ln -s ~/pypy-2.3.1-osx64/bin/pypy pypy

먼저 /usr/local/bin로 디렉토리를 바꾼다. 그곳에서 위 명령어를 통하여 바로가기를 만든다. 이때 주의할 점은 ~/pypy-2.3.1-osx64/bin/pypy에 자신의 컴퓨터의 pypy가 있는 경로를 적어야 한다는 것! 그대로 따라치면 안된다.

이렇게 설치하고 나면,

$ pypy app.py

라는 명령어로 파이썬 코드를 실행시킬 수 있다. 엄청난 속도를 보여준다. 실제로 웹 크롤러를 pypy로 돌렸더니 체감되는 속도가 훨씬 높아졌다.

그러나 이것으로 만족하면 안된다. pip와 easy_install이 필요하다.

$ curl -O http://python-distribute.org/distribute_setup.py

$ curl -O https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py

$ pypy distribute_setup.py

$ pypy get-pip.py

라고 친다. 디렉토리는 어디라도 좋다. 다 하고 나서 실제 pypy디렉토리(바로가기가 있는 곳 말고 진짜 pypy가 있는 곳; 예를들면 ~/pypy-2.3.1-osx64/bin)으로 가면, 제일 위의 사진 처럼 pip와 easy_install이 설치되어 있을 것이다. 아까와 똑같이 /usr/local/bin으로 간다. 그리고 바로가기를 생성한다. 이때 원래(컴퓨터에 이미 설치되어있는)의 python의 pip와 easy_install과 구분하기 위해 pypy-pip, pypy-easy_install이라고 지정한다.

$ cd /usr/local/bin

$ sudo ln -s ~/pypy-2.3.1-osx64/bin/pip pypy-pip

$ sudo ln -s ~/pypy-2.3.1-osx64/bin/easy_install pypy-easy_install

마찬가지로 자신의 컴퓨터에 있는 경로를 ~/pypy-2.3.1-osx64/bin/easy_install여기에 적어야 한다!

원래의 python과 100%호환된다. 뿐만 아니라 모든 것이 동일하게 지원되고, 속도는 빠르다!

$ python app.py

$ pypy app.py

위의 명령어(python)를 아래(pypy)로만 바꾸면 된다.

이제 윈도우폰도 쓸만하다. / 윈도우폰 필수 앱, 어플 추천 모음 / 반드시 받아야 할 윈도우폰 앱

youngkyu.cho — Mon, 2 Jun 2014 14:32:20 +0900

인트로

루미아 시리즈가 너무 예쁘게 생겨서 꼭 한번 써보고 싶었다. 그래서 구매한 루미아 1020. 5~6인치의 폰을 주로 사용하다보니 매우 작은 크기로 느껴졌다. 가장 걱정이었던 것은 사실 폰 자체보다는 앱!

다행히도 윈도우폰도 이제 쓸만한 것 같다. 루미아 1020을 구매하고 스토어의 이곳 저곳을 기웃거리며 얻은 결론이다. 안드로이드나 IOS에 버금갈 정도는 아닐지라도 충분히 필요한 대부분의 앱을 보유하고 있다.

척박한(?) 윈도우폰 스토어에서 힘들게 찾은 진귀한 앱들을 소개하고자 한다.

"내 폰이지만 너무 예쁘다!"

참고로, 싹다 무료다.

나의 윈도우폰 홈화면. 정말 예쁘다.

"아래의 앱 검색시, 아이콘을 참고하면 좋을 것 같다."

버스와 지하철등 대중교통 정보 보기 - 대중 교통 허브

말이 필요없는 애플리케이션이다. 경로 검색은 물론 버스 도착시간까지 정확하게 알려준다. 버스 정류장 별로 타일을 추가할 수 있는 점도 매력포인트! 윈폰 사용자라면, 대중교통을 타고 다닌다면 일단 다운로드하라!

완전 무료 윈도우폰 음악,노래 앱 - MUSIC+ (대문자라는 것에 유의)

이 대문자 MUSIC+는 소문자 music+보다 조금 더 나은 UI와 UX를 제공한다. 모든 음악이 무료고, 한국음악도 왠만한 것은 다 있다. 음질도 좋고 다운로드 받아놓고 들을 수도 있어 데이터 또한 절약할 수 있다.

사실 윈도우폰에서 가장 빈약한 점을 꼽으라면 나는 멜론, 벅스등 국내 음악 서비스 업체들의 앱이 없다는 점이다. 벅스는 있는 줄 알고 구매했는데 후에 보니 벅스 앱이 없었다.. (으아!)

Mnet은 있긴 하지만 오류가 엄청나 쓸 수 없을 정도였고 그 속에서 찾은 보석같은 앱이다. 이걸 쓰고부터는 벅스를 해지해버렸다. 배신감이 장난이 아니었기 때문..

유투브 앱, 단언컨대 이것보다 좋은 앱은 없다. - YouTube HD

인터페이스가 정말 편하고 다운로드기능을 포함하고 있어 매우 유용하다. 뿐만 아니라 화질도 GOOD!! 다른 앱 좋다는 걸 다 써봤지만 이것보다 좋은 걸 찾지 못했다. 반드시 다운로드 받을 것! 구글 공식은 아닌 것 같지만 진짜 더 좋다.

구글 드라이브를 사용하는 분이라면, - Google Drive on WP

구글 드라이브 공식앱이 윈도우폰에서는 지원되지 않는다. 그래서 다양한 앱을 다운받아 봤는데, 전부 브라우저 즐겨찾기와 다름없는 쓰레기들이었다. 그러던 중 진짜를 발견했는데 바로 이앱!

약간의 오류가 있긴 하지만 윈폰에서 이정도는 애교다. 사용이 편하고 여러 계정을 등록할 수 있어 매우 유용하다. 반드시 사용해 보시라!

할말을 잃게 만드는 퀄리티의 날씨 앱 - 다원 날씨

정말 자세한 날씨 정보를 알려준다. 안드로이드의 어떤 앱 보다 높은 퀄리티를 자랑한다.일기예보는 물론 주간날씨까지 알려주는 똑똑한 날씨앱 다원날씨. 반드시 다운 받을 것! 시작화면에 라이브 타일을 추가 할수 있는 점도 정말 마음에 든다.

마이크로소프트 제공 기본 뉴스앱 - 뉴스

정말 단순하지만 최고의 앱이다. 뉴스 볼 때 사용하는데 광고도 안봐도 되고 정말 만족스럽다. 반드시 다운받아 사용해 볼 것. 라이브타일을 지정할 수 있어 폰 꾸미기도 좋다.(라이브타일이 중요한 이슈기사를 보여주는 게 아니라서 딱히 유용치는 않기에 꾸미는 용도로만 사용중이다..)

윈도우 폰에서도 웹툰앱이 된다는 것 - naver 웹툰

나는 웹툰을 즐기지 않지만, 윈도우폰을 사려는분이나 혹시 모르는 분을 위해 올린다. 일반 안드로이드에서의 앱보다 더 높은 퀄리티를 자랑한다. UI 조작이 매우 부드럽고 빠르다. 웹툰을 즐긴다면 반드시 다운!

SSH 클라이언트가 필요한 개발자라면 - The SSH Client

라즈베리파이 한마리를 집에서 키우고(?) 있는데 개인 파일 서버로 활용중인 이녀석이 가끔씩 죽거나 문제를 일으킨다. 그때마다 고쳐주기 위해 사용하는데 정말 만족스러운 앱이다. TAB을 어떻게 하는지 모르겠다는 점만 빼면 말이다.

간단한 메모앱, 그러나 라이브 타일 메모기능까지 지원! - Sticky Notes HD

단순하게 메모를 위한 앱인데, 라이브 타일을 지원해서 몇가지 중요한 이벤트를 기록하거나 사물함 자물쇠 비밀번호 정도를 기록할때 쓴다. 시작화면에 고정해두면 중요한 메모를 한눈에 볼수 있어 매우 유용하다. 강추 강추!

아웃트로

윈도우 폰에서 느끼는 불편함은 사실 거의 없다. 안드로이드를 오랫동안 사용하다 왔지만 필요한 모든 앱이 있었고, 몇가지 오류만 제외한다면 예쁜 UI와 MS의 최적화 덕분에 매우 만족스럽게 사용하고 있다.

볼 때 마다 느끼지만 루미아 1020은 너무 예쁘다. 잠금 화면 까지도.

리눅스 디바이스 드라이버 Linux device driver / 읽기 read() / 쓰기 write() / 열기 open() / 닫기 close() - 1

youngkyu.cho — Thu, 29 May 2014 02:58:33 +0900

인트로

디바이스 드라이버에 관해 공부 중에 자료를 찾다보니 제대로 된 자료를 찾을 수 없었다. 쉬운 말로 이해되게 정리한 자료가 있었으면 했는데.. 그래서 직접 찾은 자료와 공부한 내용을 알기 쉽게 정리했다. 더 쉬운 설명에 대한 이야기나 잘못된 내용이 있다면 메일로 알려주거나 댓글을 달아 알려주길 바란다.

리눅스에서의 디바이스

리눅스에서 디바이스는 특별한 하나의 파일처럼 취급된다. 따라서 파일처럼 access가 가능하다.
/dev 에서 실제 파일처럼 확인이 가능하다.
각 디바이스들은 major number와 minor number를 가지고 있다.
같은 디바이스들은 모두 같은 major number를 가진다. 적합한 디바이스 드라이버를 연결 하기위해 사용한다.
이렇게 뭉뚱그려 하나의 번호로 구분시 각각의 디바이스가 개별적으로 구분이 불가능하므로, minor number를 사용해 각각을 구분한다.

디바이스 드라이버

디바이스 드라이버란 디바이스를 구동시키는 프로그램을 의미한다.
그 종류에는 문자(character) 디바이스 드라이버, 블록(block) 디바이스 드라이버, 네트워크(network) 디바이스 드라이버가 있다.

각각을 하나 하나 살펴보자.

문자 디바이스 드라이버는 buffer cache를 사용하지 않으며 raw data를 제공한다. 예를 들어 Terminal, keyboard, sound card, scanner, printer 드라이버등이 있다.
블록 디바이스 드라이버는 random access가 가능하며 블록 단위로 입출력이 가능하다. 또한 file system에 의해 마운트되어 관리, 사용된다. 예를 들어 hard disk, RAM, CD-ROM등의 디바이스가 속한다.
네트워크 디바이스의 경우 위의 드라이버들이 사용하는 system call대신에 socket(), bind()등의 특별한 system call을 사용한다. 네트워크 다비이스는 통신을 통해 패킷을 송수신 할 수 있는 장치를 이야기하는데 Ethernet, ATM 등의 드라이버가 여기에 속한다.

리눅스 디바이스 드라이버의 구조

간단하게 그림으로 나타내면 다음과 같다. 애플리케이션이 kernel이 제공하는 system call interface를 통해 Device driver를 제어하고 그 아래 하드웨어 계층의 Device를 제어한다. 실제로 애플리케이션이 사용하는 것은 system call interface다. 아래에 나올 함수들만 부르면 된다.

리눅스에서 디바이스 드라이버를 구현한다는 것.

각 디바이스들은 일반적인 파일과 유사한 인터페이스를 이용하여 관리된다.
각 디바이스들은 실제로 파일형태로 존재하고 커널은 파일 operation을 이용하여 I/O를 수행하도록 인터페이스가 구성되어져 있다.
디바이스 드라이버를 구현한다는 것은 파일 operation 구조체에서 요구되는 기능들을 프로그래밍 한다는 것을 의미한다.
파일 operation 구조체는 파일 시스템을 통해 디바이스 드라이버와 프로그램을 연결 시켜주는 구조체이다.

system call interface. (애플리케이션에서의 드라이버 실제 호출 함수)

다음과 같은 순서로 디바이스 드라이버를 이용하는 코드를 작성한다.

여기서 나오는 함수들은 파일에서도 똑같이 사용한다. 왜냐하면 리눅스에서 디바이스들은 일반적인 파일과 유사한 인터페이스를 사용하기 때문이다.

1. open()을 이용하여 device driver file을 연다.
2. write()를 이용하여 디바이스에 무엇인가 적어 디바이스를 제어한다.
3. read()를 이용하여 디바이스에서 무엇인가 정보를 얻어온다.
4. close()를 이용하여 device driver file을 닫는다.

당연하게도, 2번과 3번은 경우에 따라 둘 중 하나 혹은 둘 다 생략이 가능하다.

이때, open() ?

파일 혹은 디바이스를 열기위해 사용한다. 열 때 다양한 옵션을 줄 수 있다. 원래 C언어에서 파일을 열 때 fopen()이라는 표준함수를 제공한다. 이것은 C언어가 제공해주기에 조금 더 사용하기 쉽게 만들어져 있으며, open()에 비하여 portable하다. open()의 경우 리눅스의 system call이기 때문이다. fopen()도 내부적으로 결국은 open()을 호출하지만, 한겹 더 래핑되어 있어 타 운영체제에서도 사용할 수 있다.

헤더 : #include <fcntl.h>

형태 : int open (const char *FILENAME, intFLAGS) / int open (const char *FILENAME, intFLAGS[, mode_t MODE])

옵션 :

반드시 처음에 써주어야 하는 옵션
O_RDONLY	ReaD only. (읽기만 하겠다.)
O_WRONLY	WRite only. (쓰기만 하겠다.)
O_RDWR	ReaD와 WRite를 하겠다. (읽기도 하고 쓰기도 하겠다.)
기타 추가 가능한 옵션 (반드시 처음에 써주어야 하는 옵션 \| ##여기에 들어갈 옵션## ) - '\|'기호다.
O_CREAT	해당 파일이 없을시 생성한다. 이 경우 생성한 파일이다 보니 접근 권한을 명시해 주어야 한다. 만약 파일이 현재 존재한다면 파일을 덮어쓴다. (참고로 오타가 아니라 실제로 CREAT까지다. E 없다.) 예 : open( "jwmx", O_WRONLY \| OCREAT, 0644);
O_EXCL	O_CREAT때 함께 사용하면 파일이 존재할 시 -1을 반환하여 open 되지 않도록 막는다.
O_TRUNC	기존의 파일 내용을 모두 삭제한다.
O_APPEND	파일을 첨부모드로 연다. 파일 쓰기 포인터(마커)가 파일 끝에 위치한다.
O_NOCITTY	파일을 열 process에 대해 device를 제어 터미널에 할당하지 말라는 옵션. device가 현재의 terminal을 제어하지 못하도록 한다. 이는 통신시에 <CTRL>+C 문자가 와서 프로그램이 종료되지 않을 수 있도록 해준다. (이 말이 무슨 말인지 몰라도 된다. 이 글을 읽는 대부분의 독자에게는 필요없는 옵션이다.)
O_NONBLOCK	읽을 내용이 없을 때 기다리지 않고 바로 리턴한다.
O_SYNC	쓰기시 쓰기가 실제로 끝날 때까지 기다린다. 쓰기가 완료되어야 리턴한다.

인수 :

char *FILENAME	파일 이름
int FLAGS	옵션이 여기에 들어간다.
[, mode_t MODE]	O_CREAT 때 파일 접근 권한 표시

반환값 : int (열기 성공시 양수 반환 == 파일 디스크립터 반환, 실패시 -1 반환)

참고 : 파일 디스크립터란 파일 혹은 디바이스, 소켓등을 운영체제가 관리하기위해 필요로하는 정보를 가지고 있는 FCB(file control block)에 부여된 숫자를 가리킨다. 기본적으로 양의 정수로 부여된다. 일련번호 혹은 아이디라 생각하면 된다. 운영체제가 관리를 위해 정보를 가지고 있는 블록에 부여된 일련번호 혹은 아이디.

- http://taesun1114.tistory.com/12 참조

사용 예 :

int fd = open( "test1.txt", O_WRONLY | O_CREAT | O_EXCL, 0644);

혹은

int fd = open( "test2.txt", O_RDWR );

이떄, write() ?

open() 함수로 열기를 한 디바이스 혹은 파일에 쓰기 작업을 한다.

헤더 : #include <unistd.h>

형태 : ssize_t write (int fd, const void *buf, size_t n)

인수 :

int fd	디스크립터. 번호. 오픈시에 받은.
void *buf	파일에 쓸 내용을 담은 버퍼
size_t n	쓰기할 바이트 수

반환값 : ssize_t (정상적 쓰기를 했다면 쓰기를 한 바이트 개수를, 실패했다면 -1을 반환)

사용 예 :

char *temp = "forum, falinux.comn";

...생략

write( fd, temp, strlen( temp) );

중요 : 황당하게도 open()함수는 fcntl.h 에 정의 되어 있지만 write(), read(), close()는 unistd.h에 정의 되어 있다.

이때, read() ?

open 디바이스 혹은 파일을 읽는다.

헤더 : #include <unistd.h>

형태 : ssize_t read (int fd, void *buf, size_t nbytes)

인수 :

int fd	디스크립터. 번호. 오픈시에 받은.
void *buf	파일에서 읽은 내용을 담은 버퍼
size_t nbytes	읽기 할 바이트 수 (일반적으로는 버퍼의 크기랑 동일)

반환값 : ssize_t (정상적으로 실행되었다면 읽어들인 바이트 수를, 실패했다면 -1을 반환)

사용 예 :

#define BUFF_SIZE 1024

...생략

char buff[BUFF_SIZE];

...생략

read( fd, buff, BUFF_SIZE);

이때, close() ?

open된 디바이스던 파일이던 사용을 중지한다.

헤더 : #include <unistd.h>

형태 : int close(int fd)

인수 : int fd - 파일 디스크립터 (open때 받은 번호를 의미한다. )

반환값 : int (정상적으로 close 했다면 0을, 실패했다면 -1을 반환)

사용 예 :

close( fd );

- FALINUX 포럼 참조

Core network와 Access network

youngkyu.cho — Tue, 18 Mar 2014 16:04:53 +0900

Core network와 Access network

Core network

- interconnect된 라우터들의 모임이다.

- 네트워크의 네트워크이다.

Access Network

- 앤드 시스템부터 첫번째 라우터까지를 이야기한다. (L2-switch가 가운데 있다면 그것도 Access Network이다.)

- ISP가 communication link를 제공한다.

인터넷이란 무엇인가?(구성,서비스), 프로토콜이란 무엇인가?

youngkyu.cho — Tue, 18 Mar 2014 15:24:25 +0900

인터넷(Internet)이란 무엇인가? - 어떤 것들이 인터넷을 구성하는가 (H/W & S/W)

인터넷이란 전세계 수많은 컴퓨터 디바이스들이 연결되어 소통하는 컴퓨터 네트워크이다. 얼마 되지 않은 과거엔 개인이 사용하는 linux workstation과 데스크톱 PC, 그리고 메일이나 웹페이즈를 전송하는 server가 가장 주요한 컴퓨팅 디바이스였으나, 현재는 노트북을 비롯하여, 스마트폰과 테블릿, 텔레비전, 게임, 웹 캠, 자동차, 환경 측정 센서, 카메라, 보안 시스템등이 모두 인터넷에 연결되어 있다. 우리는 이러한 디바이스를 호스트(host), 혹은 앤드 시스템들(end systems)이라 한다.

당연하게도 어떤 방식으로든 인터넷에 접근하려면 무언가 link가 필요하다. 이러한 앤드 시스템 혹은 호스트들은 인터넷에 연결하기 위해 wireless links(radio spectrum, satellite등을 이용한) 혹은 wired links(optical fiber나 copper wire등을 이용한)로 불리는 communication links를 이용하고, 이를 통해 접속한다. 서로 다른 재질들로 된 link들은 각각 다른 전송 rate를 가지고 있는데 이를 transmission rate라 하며, bits/sec로 측정한다. 목적지가 header라는 곳에 명시되어 있는 데이터의 덩어리(chunks of data)가 가공되어 패키징 된 packet이라 불리는 것들은 network로 전송되고 목적지에의 호스트 혹은 앤드 시스템은 그것을 풀어서 원래의 data로 재조립한다.

packet switch라는 것은 이러한 packet을 다른 communication link로 보내주는 역할을 한다. 이런 packet switch들은 여러 종류가 있지만, 오늘날 인터넷에는 router와 L2 switch(link-layer switch) 2가지를 사용하고 있다. 두 가지 모두 packet을 정해진 목적지에 보내는 역할을 한다.

L2 switch는 일반적으로 Access network에 사용된다. 반면에 router는 network의 core network 부분에 사용된다. packet이 목적지에 도달할 때 까지 경로를 path 혹은 route라 한다. (router는 L3 switch(ip-layer switch)라 불리기도 한다. 이는 뒤에 나올 OSI 7 layer중 3번째 layer와 관련 있기 때문이다. L2 switch 또한 OSI 7 layer의 2번째 layer와 관련 있기 때문에 그렇게 불린다.)

참고 : 위키백과 OSI 모형

end system은 ISP(Internet Service Provider)를 통해서 인터넷에 접속하는데, 이러한 ISP의 예로는 모두가 잘 아는 SK의 브로드밴드 혹은 올레, 유플러스, CJ등이 있다. 인터넷이란 이들 ISP들이 Interconnted된 것인데, network의 network라 생각 할 수 있다. 보통 ISP는 local적인 regional ISP를 의미하는데, 이들은 가입자들에게 Access network를 제공하며, 동적 IP를 할당해준다.(이러한 서비스를 제공하고 돈을 버는 사업을 하는 통신 사업자들이 ISP이다.)

참고 : 위키백과 인터넷 서비스 제공자

인터넷에는 다양한 프로토콜들이 있다. 프로토콜이 무엇인가에 대해서는 뒤에서 알아보도록 하고, 간단히 어떤 약속이라 생각하자. 인터넷의 프로토콜 예시를 먼저 살펴보자면 TCP, IP, HTTP, Skype(스카이프가 사용하는 독자 프로토콜), 802.11 등이 있다. 이러한 프로토콜은 서로간의 약속이므로 누군가가 중재해서 어떤 약속인지를 명시할 필요가 있다. 인터넷에 관하여 명시된 약속을 우리는 Internet Standard라 하며, 이는 IETF(Internet Engineering Task Force)에 의해 만들어지고 개발되고 있다. IETF에서 만든 standard 문서를 RFC(Request for comments)라 부른다.

인터넷(Internet)이란 무엇인가? - 서비스들의 관점에서 보자.

인터넷이란 App입장에서 보면 어떤 인프라(Infrastructure)이다. 웹을 이용하는 App에는 web 관련 환경을 제공하며, email, 인터넷 전화, 게임등에 필요한 네트워크등을 제공한다. 페이스북과 트위터 같은 SNS 또한 Internet이라는 인프라 위에서 만들어지는 App의 한 형태이다. 또한 인터넷은 API(Application programming interface)도 제공하는데, 이 API에 대해서는 추후에 알아보도록 하자.

프로토콜(protocol)이란 무엇인가?

protocol이란 어떤 약속인데, 어떻게 메세지를 보낼지, 그리고 그 메세지에 어떤 식으로 답할지에 관한 약속이다. "안녕?" 라 하면 "안녕!"라고 대답하고, "Hi!"라 하면 "oh, hi!"라고 하는 것이 인간의 프로토콜이다. 영어로 물었기에 영어로, 한국어로 물었기에 한국어로 대답하는 이 행동이 프로토콜인 것이다. 또 '안녕'이라는 것에 대한 의미와 대답을 서로 인지하는 것 또한 어떤 프로토콜이며, 대답을 하고 질문을 하는 행위는 프로토콜을 서로 공유하기에 가능한 것이다.

네트워크에서 프로토콜은 기계가 이러한 행위를 할 수 있도록 하는 기계들의 약속인 것이다. Internet의 모든 커뮤니케이션은 정해진 프로토콜에 의해 가능한 것이다. sender가 보낸 내용을 receiver가 이해할 수 있어야 하기 때문이다.

인터넷에서의 프로토콜이란 인터넷 entity들 사이의 메세지 format과 보내는 메세지, 받는 메세지의 순서, 어떻게 반응하고 전송하는지에 관한 전반적인 정의인 것이다.

참고 : 텀즈 프로토콜

CSS GENERATOR들 모음 / CSS Maker들 모음(border-radius,text-shadow,font-face,box-sizing,transition,transform,filter,960 grid system)

youngkyu.cho — Tue, 18 Mar 2014 13:17:57 +0900

CSS3 Ggenerator

http://css3generator.com

border-radius , box-shadow , text-shadow , rgba , font-face ,

multiple colums , box resize , box-sizing

outline , transition , transform , gradient

이런 것들을 직접 보면서 조절하면, 자동으로 CSS 코드를 생성시켜주는 generator다. 주로 필자는 text-shadow를 보면서 조절하기 위해 사용했는데, 웹 디자인시 많은 분들이 유용하게 사용 할 수 있을 것 같다.

CSS Filter Effects

http://html5-demos.appspot.com/static/css/filters/index.html

필자는 웹 디자이너가 아니다보니, 포토샵을 잘 다룰 줄 모른다. 아마도 대다수의 웹 개발하는 개발자가 그럴 것이다. 가끔 다양한 사진 효과를 사용해야할 경우가 있는데, 그럴 때 보통은 포토샵으로 편집해서 사용하면 되지만, 포토샵을 잘 다룰 줄 모르는 필자는 브라우저가 제공하는 filter 효과를 많이 사용한다. CSS를 외우고 있어도 햇갈릴 경우도 많고 적용 순서에 따라 효과가 천차만별이라 항상 오랜 시간이 걸려서 작업하곤 했는데, 이 generator는 편하게 보면서 필터 이펙트를 적용할 수 있게 해주고, 코드까지 완성해준다.

CSS filter를 사용할 때 엄청 유용하다.

CSS 3.0 MAKER

http://www.css3maker.com/css3-animation.html

위에 사이트와 비슷한 기능을 제공하는 css 3 메이커이다. 위와 마찬가지로

border-radius , gradient , css transform , css animation , css transition , rgba , text-shadow , box-shadow , text rotation, font face등을 보면서 설정하고 자동으로 CSS를 만들어주는 툴이다.

보통 여기서 필자는 css animation을 설정해서 사용하곤 한다.

CSS MATIC

http://www.cssmatic.com/noise-texture

위에 사이트들에 없는 기능을 하나 제공하는 사이트이다. noise texture을 보면서 설정할 수 있는데, 이는 순수 CSS로 제작된게 아니라 thumbr라는 곳에서 제공하는 api를 사용하여 만들어내는 effect인 듯. 가서 확인해 보시라. 정말 유용하다!

Grid SYSTEM

http://grids.heroku.com/

레이아웃을 잡을 때, grid를 간단히 계산해 주는 툴이다. 별거 아닌 것 같지만, 노벨 평화상을 주고 싶을 만큼 짜증을 줄여준다. 항상 매우 유용히 사용해서 소개한다. CSS 파일 다운로드 기능도 제공한다.

웹 디자인, 웹 개발시에 유용한 툴(useful tools) 모음 (색 배합,번역글 모음,무료 벡터 소스,무료 이미지,ICON,favicon,png to icon,랜덤 유저 생성)

youngkyu.cho — Mon, 17 Mar 2014 15:51:49 +0900

ADOBE KULER

https://kuler.adobe.com

웹 디자인을 전문적으로 하는 디자이너라면 하지 않을 고민일테지만, 개발을 하다 필요에 의해 웹 디자인을 하거나 어찌됐건 디자인을 하게 되는 개발자의 경우, 색감에 매우 둔감해 색상 배합을 엉망진창으로 사용하곤 한다. 색상에 대한 감각이 없기 때문이다. Adobe가 제공하는 Kuler 서비스는 이러한 개발자에게 멋진 색 조합을 추천해준다. 여러가지 옵션을 사용할 수 있다. 물론 개발자나 디자이너외에도 색을 배색할 일이 필요한 분들에게 유용할 것 같다.

한글 번역글 모음 페이지

http://nolboo.github.io/trans

웹 디자인이나 웹 개발을 하며 자료를 찾다보면, 영어가 부족해 좌절할 때가 한 두번이 아니다. 그런 분들에게 소개하는 곳! 다양한 원서와 블로그, 외국 원문들을 번역해 제공하는 한글 번역글 모음 페이지이다. 아래는 이 번역글 페이지가 제공하는 대표글이다.

---

부트스트랩 3 한글 번역 / 구글 웹폰트 빠르게 로드하는 팁 7 가지 / LESS 튜토리얼

최고의 워드프레스 개발자가 되는 방법 / 브라우저는 어떻게 동작하는가?

반응형 디자인 적용하기 / Pure CSS 번역 / Javascript 핵심

Angular.js는 왜 좋은가? / Angular JS의 MVC패턴 개요 / 루비 온 레일스 튜토리얼 번역

PHP의 올바른 방법 / GO 프로그래밍 입문 / 2시간만에 Perl 익히기

Perl 정규 표현식 / 파이썬 10분만에 배우기 / R 매뉴얼

GitHub 사용하는 방법 / 플랫UI

---

Freepik.com

http://www.freepik.com

freepik은 사진과 벡터 이미지, PSD, ICON등을 한방에 찾을 수 있는 강력한 데이터 저장소이다. 게다가 무료!! 뿐만 아니라, 각 색상에 맞는 사진과 벡터이미지만을 골라 주는 기능도 있다. 검색 후 검색창 바로 아래에 세부적인 색상을 선택할 수 있는 기능이 있으니 활용한다면 위의 색 배합 서비스와 함께 유용하게 사용할 수 있을 것이다. 개인적으로 웹 디자인을 하다보면 저작권에서 조금 자유로운 벡터 이미지와 아이콘들이 필요한데, 그럴 때 유용하게 필자가 찾는 사이트이다. PPT같은 프레젠테이션 파일을 만들거나 워드 작업시에 필요한 이미지를 구하는데도 매우 유용할 것 같다.

P LACEHOLD.IT

http://placehold.it

웹 페이지의 레이아웃을 구성하다보면 이미지를 넣을 장소긴 한데 아직 넣을 이미지를 구하지 못한 경우가 많다. 그럴 때 정해진 규격의 사이즈로 대신 박을 수 있는 Dummy 이미지를 제공한다. http://placehold.it/300x300 처럼 간단하게 img 테그의 src 어트리뷰트에 적어주면 사용할 수 있다. 아주 유용하다. 다른 Dummy 이미지 서비스들도 있지만 사이즈까지 표시해 줌으로 개인적으로는 가장 유용한 것 같다. (저 칙칙한 회색까지도 바꿔서 사용 할 수 있다는 점!!)

METRIZE ICONS

http://placehold.it

레티나와 같은 고해상도 디바이스가 많이 나오고, 스마트폰으로 확대가 용이하다보니 고화질 이미지를 사용하거나 벡터 아이콘을 사용하는 경우가 많다. 필자의 경우 이때 마음에 드는 아이콘 찾기가 쉽지 않았는데, Metrize는 필자가 좋아하는 스타일의 아이콘을 다양한 형태로 제공했고 매우 유용히 사용했다.

아름다운 아이콘을 SVG와 폰트, PDF, AI, EPS 파일까지 제공함으로 웹 디자인시 매우 유용하게, 간편히 활용 할 수 있다.

converticon.com

http://converticon.com/

페비콘을 만들 때 유용하게 사용하는 사이트이다. PNG파일이나 GIF, JPEG 포멧을 간단히 ICON으로 바꿔주는 웹앱이다. 반드시 즐겨찾기에 추가해 둘 툴!

RANDOM USER GENERATOR

http://randomuser.me/

랜덤 유저를 생성해준다. 이름 뿐만 아니라, 사진과 전화번호등 다양한 정보를 제공한다. 웹 디자인 시 유용하게 사용 할 수 있을 것 같아 즐겨찾기에 추가해 두었는데, 아직 딱히 사용할 일은 없었지만 분명 웹 디자이너분들은 스킨 제작시 유용히 사용하리라 생각된다.

SIC/XE의 구조(Architecture), SIC과 어떻게 다른가?, Special symbols

youngkyu.cho — Thu, 6 Mar 2014 02:41:00 +0900

SIC과 SIC/XE

SIC/XE는 SIC의 업그레이드판이다. 따라서 많은 Feature은 동일하다. 몇가지 바뀌고 추가되고 변화된 부분을 알아보도록 하자. 메모리가 1Mega(2의 20승)로 SIC의 2의 15승보다 더욱 증가하였다. 뿐만 아니라 Instruction format과 addressing mode도 조금 변화되었다.

레지스터(Register)가 추가되었다. -Additional registers

기존에 SIC이 가지고 있던 5개의 레지스터에 4개가 더 추가되어 총 9개가 되었다. F 레지스터를 제외한 모든 레지스터는 24bit이다.

S와 T 레지스터는 오직 데이터를 저장만 할 수 있다. A 레지스터처럼 accumulator로 사용하는 것은 불가능하다. 또한 F 레지스터는 24bit가 아니라 48bit이다. 이것은 부동소수점(Floating-point)를 위한 레지스터이다. B 레지스터는 index를 붙여서 사용되는 경우가 많다.

부동소수점 데이터 타입(Floating-point data type)

SIC/XE는 SIC에서 48bit 부동소수점 데이터 타입이 추가되었다. 이것은 다음과 같은 포멧을 가진다.

youngkyu.cho — Thu, 6 Mar 2014 02:09:02 +0900

지적재산권과 지식재산권

법률 중 가장 으뜸가는 법은 헌법이다. 그리고 그 아래로 여러가지 법들이 있지만, 공학 전공자로서 다른 무엇보다 정확히 알아야하고 중요한 법률은 '지식재산권'일 것이다. 과거에는 지적재산권이라는 이름으로 불리었으나, 형용사를 만들 때 사용하는 '~적'이라는 표현이 일본식 표현이고, '지적'이라는 표현이 직관적이지 못해(네이버 검색창에 지적까지만 치면 지적도가 나옴.) 지식재산권으로 몇년전에 바뀌었다. (쓸데없는 일을 했다고 표현하는 분들도 있는데, 개인적으로 법이 대중에 가까이 가는 방식으로 보여 매우 긍정적으로 보였다.)

지식재산권, 줄여서 지재권(Intellectual property rights)은 2개의 축이 떠 받들고 있다. 그 첫번째 축은 산업적 관점에서 접근하는 지식재산권. 줄여서 산업재산권. 더 줄여서 산재권 (industrial property)이다. 특허와 실용신안, 영업기밀, 상표권, 디자인권(의장권)이 여기에 속한다. 각 권리들은 각각을 보호하는 더 세부적인 개별법이 따로 있다. 어떤 법이든 제1조는 그 법의 목적 조항인데, 개별법 중 특허법 제 1조는 "발명을 보호함으로써 산업발전에 이바지함을 목적으로 한다" 이다. 여기서 주목할 부분은 산업발전이다. 이것이 바로 산재권의 목적이기 때문이다. 특허법 제 1조와 산업재산권의 가장 기본적 목적이 산업발전에 이바지한다는 것을 알고 있다면, 다른 개별법들의 제 1조도 알 수 있다. 상표권은 "상표를 보호함으로써 ~ " 일 것이고, 디자인권은 "디자인을 보호함으로써 ~ "일 것이다. 이 산업재산권은 특허청 관할이다. 두번째 축은 문화적 관점에서 접근하는 지식재산권인데, 이것을 줄여서 문화재산권이라하지않고, 저작권(copyright)이라 한다. 저작권은 문화 발전이 목표다. 따라서 저작권 제 1조는 아마 "저작권을 보호함으로써 문화 발전에 이바지함을 목적으로 한다." 일 것이다. 이것은 문화를 관할하는 청에서 담당하는 법이다. ( 현 문화체육관광부 )

원래 이 두개의 법이 지식재산권을 처음 지탱할 땐, 형이하학적인 장사, 사업, 돈과 관련된 산업 관점과, 형이상학적인 문화. 이렇게 2가지로 구별하였고 이것이 꽤 분류가 잘 되었다. 그러나 최근들어 문화산업 이라는 말이 생기기 시작하며, 문화가 하나의 형이하학적인 돈과 연계된 산업이 되어버렸다. 그러다보니 철학적 관점에서 나누었던 2개의 축이 조금 무너지기 시작한 것이다. 이에 따라 법은 저작권의 목적을 수정한다. 그렇게 저작권법 제 1조는 "저작권을 보호함으로써 문화 발전 및 관련 산업 발전에 이바지함을 목적으로 한다"로 변화되었다.

지식재산권이라는 하나의 큰 범주에 속하는 2개가 각기 다른 곳에서 관리되는 것이 의아할 수 있다. 물론 하나의 기관이 관할하는 것이 옳을 수 있고 그것이 답일 수 있다. 지금 대한민국이 관점과 목적이 달라 다른 기관에서 담당한다는 것 뿐.

SIC(Simplified Instructional Computer)의 구조(Architecture), 명령어 포멧(Instruction formats), 주소 형식(Addressing modes)

youngkyu.cho — Thu, 6 Mar 2014 01:39:26 +0900

SIC과 SIC/XE란?

기본적으로 시스템 프로그램(소프트웨어)들은 하드웨어와 밀접한 관련이 있다. 이러한 관련을 '기계 종속적'이라고 하며, 따라서 특정한 기기를 집어 학습하여야한다. 실제 Machine은 매우 복잡하여 학습하기 좋지 않고, 가장 기본적인 Feature들에 충실할 수 없으므로, SIC과 SIC/XE를 통해서 이해하도록 한다. 이때 SIC과 SIC/XE는 Hypothetical한(가상의) 컴퓨터로 실제 컴퓨터 명령어(Simplified Instructional Computer)를 단순화시켜 이해하기 수월하도록 만들어 놓은 것으로, 실제의 Machine에서 자주 쓰이는 특징들이 포함되어있다. 가상의 컴퓨터이나, 실제와 유사한 상황을 만들 수 있도록 기본 버전인 SIC 뿐만아니라, SIC의 확장된 형태의 SIC/XE를 동시에 사용하여 설명한다.

SIC은 가상 컴퓨터의 스탠다드 모델이며, SIC/XE는 확장된 모델인데, 이 두개의 컴퓨터는 상위호환(upward compatible)을 보장한다. SIC에서 작동되었던 프로그램들은 모두 SIC/XE에서 정상적으로 작동된다. 단 SIC/XE의 프로그램들이 SIC에서 작동된다는 것은 보장하지 않는다. 이는 이 가상의 컴퓨터들이 하위호환(backward compatibility)을 보장하지 않기 때문이다.

추가정보 : 위키피디아 SIC

SIC의 구조(Architecture) - 메모리(Memory)

SIC은 8비트가 한 바이트로 이루어져 있다. 모든 주소는 바이트로 표현되며 저장된다. 3개의 consecutive한(이어진) Bytes를 Word라고 하며, Word를 구성하는 3바이트 중 최하위 바이트의 위치로 주소가 지정된다. SIC의 전체 메모리는 2의 15승이다.

SIC의 구조(Architecture) - 레지스터(Registers)

SIC에는 각각의 특수한 목적을 지닌 5개의 레지스터가 존재하며, 그 크기(길이)는 각각 24bit이다. 레지스터들은 숫자로 된 표현과 Character형식의 표현, 이렇게 두가지 다를 가지고 있다. 이때 Character 형태로 된 표현을 Mnemonic이라 한다.

A(0)는 일반적으로 사용되는 레지스터로, 기본적인 산술 연산에 활용된다. 누적기(Accumulator)이라 번역된다.
X(1)는 주소를 저장하고 계산하는데 사용되는 레지스터이다. 비유하자면, 'for(int i=0;i<10;i++){//code}'에서 i같은 역할을 한다.
L(2)은 Function call시 사용되던 스택과 같은 역할을 하는 것으로, 어떤 메모리로 점프 할지, return할 주소는 어디인지를 저장하는 역할을 한다. 링크 레지스터라고 한다.
PC(8)는 다음 작업(명령)이 저장되는 곳이다.
SW(9)는 컨디션 코드를 포함한 다양한 정보를 담고 있는 레지스터이다.

SIC은 스택을 가지고 있지 않다. 따라서 linkage 레지스터에 돌아갈(return) Address를 저장한다. 그러다보니 recursive(재귀적) 프로그램은 작성하기가 쉽지않다.

SIC의 구조(Architecture) - 데이터 포멧(Data formats)

SIC은 2가지의 데이터 포멧을 가지고 있다. Character과 Integer가 그것이다. Floating-point number는 지원하지 않는다. (확장된 버전인 SIC/XE에서는 지원한다.) 모든 Character는 8bit로 된 ASCII코드로 관리된다. Integer는 24bit의 2진수로 관리된다. 현대의 모든 컴퓨터들이 그렇듯, 음수는 2의 보수(2`s complement)로 표현한다.

SIC의 구조(Architecture) - 명령어 포멧(Instruction formats)과 주소 모드(Addressing mode)

명령어 포멧은 24bit로 되어 있다. 제일 앞 8자리는 opcode로 어떤 명령을 내릴 것인가를 나타내며, X는 Index-Address mode를 나타내는 플래그로, 1이면 Index-Address mode로 동작하며, 0이면 직접(Direct) 주소를 나타낸다. 직접 주소는 그 주소를 직접 사용하는데 반해, 인덱스 주소는 해당 주소에 Index 레지스터의 값을 더한 것을 주소로 사용한다. ( 주소 + X:인데스 레지스터의 주소 ) 이러한 instruction format을 1세대 언어에서는 그대로 사용하였다.

SIC Machine 명령어 종류(Instruction Type)

1세대 언어에서는 위의 Instruction format을 그대로 사용하였지만, 우리는 Aseembly라는 2세대 언어를 사용하여 학습을 진행할 것이다. SIC의 Assembly명령어를 크게 종류(type)로 구분하면, 6가지로 구분 할 수 있다.

Load와 Store
Arithmetic & Logic
Comparison
Conditional Jumps
Subroutine Linkage
I/O

참고 : http://www-rohan.sdsu.edu/~stremler/2003_CS530/SicInstructions.html

SIC 명령어 - Load와 Store

LDA, LDX, STA, STX 이렇게 4가지만 우선 살펴보자. (다른 명령어도 존재한다.)

LDA ALPHA란 데이터를 ALPHA에 가서 값을 LoaD하여 A에 집어넣어란 명령어이다. 이때, ALPHA에 가서라는 것은, 저 ALPHA의 주소로 가서 value를 읽어오라는 것을 의미한다. LDX도 조금 주체가 바뀔 뿐 동일하다.

STA GAMMA란 데이터를 A가서 값을 읽어 STore in GAMMA 하라는 의미이다. STX도 주체가 바뀌지만 역시 동일하다.

위의 내용이 이해가 되었다면 아래 LDL,STL,STSW는 무리없이 이해할 수 있다. 그러나 LDCH와 STCH는 조금 고민해야하는데, register는 24bit고, 이곳에 byte(8bit)를 저장하기 위해서는 어딘가가 잘려야 한다. 이때 잘리는 부분은 앞의 16자리로, 맨 우측, 즉 가장 뒤의 8자리만 저장되고 로드된다. 이 부분만 이해하면 똑같이 STCH와 LDCH도 이해할 수 있을 것이다.

SIC 명령어 - Arithmetic & Logic

이 명령어들은 모두 A 레지스터와 관련이 있는 것으로, A를 주어로 생각하면 해석하기 편하다. 항상 A는 생략되었다 생각하자.

SIC 명령어 - Comparison

이 타입엔 2가지 명령어가 있다. 하나는 COMP, 다른 하나는 TIX이다. COMP는 비교를 하는 것으로,

비교되어 나온 값(크다, 작다, 같다 같은.)을 SW 레지스터의 Condition code에 저장한다.

TIX는 X에 1을 증가시킨 후, X가 가리키는 값과 ALPHA를 비교 한다고 생각하면 된다.

SIC 명령어 - Conditional Jumps

CC(of SW)에 따라 점프하는 명령어이다.

J는 CC에 관계없이 다음 명령인 PC에 ALPHA를 넣는다. JLT,JGT,JEQ는 조건에 따라 결정되는데, 이전 COMP명령어에서 A 레지스터가 주체였으므로, JLT는 'A레지스터 값이 더 작다면'으로, JGT는 'A레지스터 값이 더 크다면', JEQ는 'A레지스터 값과 같다면'으로 해석될 수 있다. (위의 예의 ALPHA와 이 예의 ALPHA는 다른 ALPHA로 아무런 관계가 없다. 편의상 사용한 것.)

SIC 명령어 - Subroutine Linkage

위의 코드 JSUB READ는 일단 L(링커; 리턴 할때 찾아 갈 값 보관용) 레지스터에 다음 할 명령이었던 PC를 저장해두고, PC에 READ란 서브루틴을 부른다. 그리고 READ의 명령들을 수행한 후, 다시 원래의 루틴으로 L레지스터의 값을 참조해 돌아온다.

RSUB는 리턴과 유사한 의미라 보면된다.

SIC 명령어 - I/O

인풋과 아웃풋은 한번에 1바이트씩만 전송되며, A레지스터의 마지막 1바이트(8비트)를 사용한다. 모든 디바이스는 각각을 구별하기위해 unique한 8비트의 코드가 부여된다. 따라서 구별되는 한도 내, 최대 2의 8승개의 디바이스가 붙을 수 있다.

TD INDEV는 INDEV란 디바이스를 테스트하는 명령이다. 이 테스트의 결과는 CC에 저장되며, <(LT)라면 디바이스가 레디된 상태, =(EQ)라면 아직 준비가 되지 못한 상태를 뜻한다. RD는 디바이스에서 1byte를 읽어 A 레지스터 가장 마지막 1byte에 저장하란 뜻이고, WD는 A 레지스터의 값을 내보내는 명령이다. 1바이트씩만 처리되므로, 여러바이트는 반복으로 처리해주어야 한다.

Define Storage

4가지로 Reserve를 할 수 있다.

BYTE : 문자 혹은 16진수 상수를 생성한다.
WORD : 한 워드 정수 상수를 생성한다.
RESB : 지정해준 수만큼의 바이트들을 예약한다.
RESW : 지정해준 수만큼의 워드들을 예약한다.

예를 들어 생각해보자.

ALPHA RESW 1 => 1 만큼의 워드를 예약.

FIVE WORD 5 => 상수 5 생성.

CHARZ BYTE C'Z' => 캐릭터 상수 Z 생성.

C1 RESB 1 => 1만큼의 바이트 예약.