CKEditor는 더이상 오픈소스만으로 제공되지 않는다

오픈소스 프로젝트를 이용하는데 있어 주의해야 하는 것 중 하나가 LISENCE를 잘 살펴보아야 하는 것인데, 이 프로젝트는 프로젝트를 사용함으로 인해 이 사용한 프로젝트에 법적인 제약이 걸리게 된다.
단적으로 GPL Lisence의 경우에는 이 소스를 사용한 프로젝트의 전체 소스를 공개해야 한다.
반면 MIT Lisence의 경우에는 이러한 제약이 거의 없고 상업적 이용되 허용된다.

CKEditor Pricing을 살펴보면, OpenSource Project와 상업적 용도가 구별되어있다는 것을 알 수 있다.
CKEditor가 상당히 안정화됨에 따라 이와 같은 가격정책을 취한 것으로 생각되는데, 일반적으로 소스를 오픈하지 않는 프로젝트라면 SummerNote를 쓸 수 밖에 없는 상황이 아닌가 싶다.

CKEditor도 Lisence가 GPL, LGPL, MPL 이 세 가지로 나누어져 있는데 이 세 라이센스 중 한 가지를 따라야 하며, 법적(legal)하게 SourceCode를 public하게 만들어두어야만 한다.
Standard Lisence의 경우에는 OpenSource용이고, 이 경우 Commercial하게 사용하지는 못한다. 즉, 오픈소스 프로젝트에 Support 가격이 들어간 것일 뿐인 것이다.

오픈소스는 어떻게 운영되는가

오픈소스 프로젝트는 기본적으로 개발자들의 열정으로 이루어진다.
사회 공헌적 성격도 있고, 자신이 만든 소스를 여러 사람들이 사용해 더 큰 생태계로 발전해 나가기를 희망하는 것도 있다.
기업이 공개하는 오픈소스의 경우에는 자사의 서비스와 연계되어있는 경우나 자사가 이용하는 라이브러리/프레임워크가 전 세계에서 널리 사용되어 보편화 되고 이로 인해 시장 점유율이라는 것과 이쪽 분야에 대한 전반적 발전을 이끌어 낼 수 있다는 점에서 의미가 있다. (단적인 예시로 구글의 TensorFlow가 공개된 이후 TensorFlow가 학계에서 무척 많이 이용되고 있으며 관련 연구의 진척이 폭발적으로 일어나고있다.)

오픈소스 프로젝트 개발팀은 어떻게 밥먹고 사는가

MySql와 같은 유명 오픈소스 프로젝트들은 크게 두가지 방법으로 서비스를 제공한다.
일반 사용자들을 위한 것, 그리고 기업 사용자들을 위한 것.
회사나 공공기관의 경우에는 솔루션 도입에 앞서 염두에 두는 것이 ‘가격’만이 아니라 ‘유지보수’, 즉 이용중에 접하는 버그 혹은 에러상황에 대해 내부에서 프로젝트 전체를 관리하지 않고서도 자사의 서비스를 안정적으로 유지할 수 있느냐, 그리고 이 솔루션 도입시 에러를 내지 않는다는 (혹은 에러를 빠르게 해결 가능하다는) 보증이 필요한 것이다.

따라서 개발팀은 프로젝트는 공개하되, 개발팀 차원에서 지원이 필요한 경우에 계약을 통해 돈을 받고 유지보수를 계속 하는 것이다.

여담

오픈소스 프로젝트는 사실 PullRequest에 의해 진행되는 면도 무시할 수 없다. 그러나, Core개발자들이 풀타임으로 일하지 않는다면 OpenSSL의 HeartBleed와 같은 문제가 언제든 발생할 수 있다.

OpenSSL는 대다수의 프로젝트에서 의존성으로 사용되는 어머어마하게 많이 사용되는 프로젝트임에도 풀타임 개발자가 한명뿐이었다는 점, 오픈소스 프로젝트가 갖게 되는 가장 심각한 문제를 명백하게 보여준다.
모두가 관리하는 것이 아니라 모두가 방치했을 수 있다는 점, 그리고 빠른 패치와 업그레이드가 오히려 문제를 가져올 수 있다는 점, 그리고 이 문제는 소수가 사용하는 내부 시스템이 아니라 전세계의 대다수의 서비스가 사용하는 의존성 패키지였다는 점.
공유지의 비극이 일어난 상황이라고 보아도 무방하지 않을까…

React Native 0.37버전의 The Basis 번역을 마쳤습니다.

현재 작업은 ReactNative Korean Translated v0.37에 올려져 있습니다.

React Native의 ​Tutorial번역 시리즈입니다.
원문: getting-started
이번 번역은 현재(2016.11.15) 최신 Stable인 0.37버전의 문서를 번역하였습니다.

#01: 시작하기

React Native에 오신 것을 환영합니다!
이번 게시글에서는 React Native를 여러분의 시스템에 설치하고 곧바로 실행 할 수 있도록 안내합니다.
만약 여러분이 이미 React Native를 설치해두셨다면, 이번 게시글을 건너뛰고 튜토리얼로 가셔도 됩니다.

이번 게시글은 여러분이 어떤 시스템을 사용하는지에 따라 약간 내용이 다르고, iOS/Android중 어떤 것을 사용하느냐에 따라서도 내용이 다르답니다.
iOS와 Android 모두 개발하는 것도 당연히 가능합니다! 여기서는 그냥 시작을 어떤 환경으로 할지 정하는 것 뿐입니다.

1

주의: iOS개발은 Xcode가 깔려있는 macOS(OS X)환경에서만 가능합니다.

필요한 의존패키지들 설치하기(macOS/OS X에서)

윈도우에서 의존 패키지를 설치하는 것은 문서 아래쪽의 윈도 의존 패키지 설치하기를 참고해주세요.

React Native를 개발하기 위해서
여러분은 node.js와 Watchman, React Native command line interface와 Xcode가 필요합니다.

Node, Watchman, react-native-cli 설치하기 (iOS, Android 공통)

node와 Watchman을 Homebrew를 통해 설치하는 것을 권장합니다.
터미널에서 아래와 같이 입력해 설치할 수 있답니다.

1
2

brew install node
brew install watchman

Watchman은 facebook에서 파일 시스템의 변화를 감시하는 용도로 사용하는 툴입니다.
더 나은 퍼포먼스를 위해 사용을 강력히 추천합니다!

위에서 node와 함께 npm이 자동적으로 설치되었을거랍니다. 아래 명령어로 react-native-cli를 설치해주세요!

1

npm install -g react-native-cli

(번역주)-g 옵션은 시스템 전체에서 사용할 수 있도록 시스템 영역에 설치한다는 뜻입니다.

만약, 권한 문제로 설치에 실패하신다면 sudo npm install -g react-native-cli로 설치해보세요!

만약 Cannot find module 'npmlog'같은 에러를 만나셨다면, npm을 다음 명령어로 수동 설치해보세요.: curl -0 -L http://npmjs.org/install.sh | sudo sh.

Xcode 설치하기 (iOS개발환경)

Xcode를 설치하는 가장 쉬운 방법은 Mac App Store에서 받는 방법입니다. 앱스토어에서 Xcode를 설치하면 iOS시뮬레이터와 iOS App빌드를 위한 여러 툴들이 자동으로 함께 설치됩니다.

Android Studio 설치하기 (안드로이드 개발환경)

만약 여러분이 안드로이드를 개발하는 것이 처음이라면, 개발환경을 갖추는 것은 약간 까다로울 수 있습니다.
이미 안드로이드 개발을 하고있던 환경이라면, 설정을 거의 건드리지 않아도 React Native로 개발을 시작하실 수 있습니다.
둘 중 어떻든, 아래 과정을 확인해보세요.

1. Android Studio 받고 설치하기.

Android Studio는 여러분의 React Native앱을 실행시킬 Android SDK와 AVD(안드로이드 VM)를 제공해줍니다.

Android Studio는 Java Development Kit (JDK) version 1.8 이상을 필요로 합니다. 터미널에서 javac -version 명령어로 몇 버전의 JDK가 깔려있는지 확인해보세요!

2. AVD, HAXM 설치하기

Android Studio 설치를 시작할 때 custom옵션으로 설치를 진행해 주세요.
다음 문항들이 다 체크되어있는지 꼭 확인해보세요:

• Android SDK
• Android SDK Platform
• Performance (Intel ® HAXM)
• Android Virtual Device

다 체크되어있다면, “Next”를 눌러 설치를 진행해 주세요.

(역자주) HAXM이 없어도 여전히 사용은 가능합니다. 그러나 안드로이드 가상머신의 성능이 저하될 수 있고, 이 옵션은 사용하시는 시스템에 따라 사용가능 유무가 달라지므로 크게 신경쓰지 않으셔도 됩니다.

만약 Android Studio를 이미 설치하셨더라도, Android Studio 재설치 없이 HAXM 설치를 하실 수 있습니다.

3. Android 6.0 (마시멜로) SDK 설치하기

안드로이드 스튜디오에서는 기본적으로 최신 버전의 Android SDK를 설치해줍니다. 하지만 React Native(0.37)에서는 안드로이드6.0(마시멜로) SDK(역자주)정확히는 v23.1를 사용합니다. 이 SDK는 “Welcome to Android Studio” 화면에서 SDK Manager를 실행하고, Configure탭에서 설치하실 수 있습니다.

또다른 방법으로는, 안드로이드 스튜디오의 “Preferences” 메뉴 아래 Appearance & Behavior → System Settings → Android SDK 으로 들어갈 수 있습니다.

SDK Manager에서 “SDK Platforms”을 누른 후, “Show Package Details”를 눌러보세요. Android 6.0 (Marshmallow)를 찾으신 후, 아래 목록들이 모두 체크되어있는지 확인해 보세요:

• Google APIs
• Intel x86 Atom System Image
• Intel x86 Atom_64 System Image
• Google APIs Intel x86 Atom_64 System Image

위 그림에서는 7.0만 설치되어있는걸 보실 수 있습니다. 6.0을 체크해주세요!

다 체크되어있다면, “SDK Tools”탭을 눌러보세요. “Android SDK Build Tools”를 펼쳐보시고, Android SDK Build-Tools 23.0.1가 깔려 있는지(체크되어있는지) 확인해 보세요.

마지막으로, Apply버튼을 눌러 SDK와 빌드 도구를 설치해주세요.

4. ANDROID_HOME 환경변수 설정하기

React Native command-line interface는 ANDROID_HOME 환경변수를 필요로 합니다.

아래 코드들을 ~/.bashrc (혹은 이와 같은 것들)의 마지막에 넣어주세요.

1
2
3

export ANDROID_HOME=~/Library/Android/sdk
export PATH=${PATH}:${ANDROID_HOME}/tools
export PATH=${PATH}:${ANDROID_HOME}/platform-tools

ANDROID_HOME이 저 위치가 맞는지 꼭! 확인해주세요. 만약, Homebrew를 통해서 Android SDK를 설치하셨다면 아마도 /usr/local/opt/android-sdk가 ANDROID_HOME이 될겁니다.

등록한 환경변수는 터미널을 재실행 한 이후에 적용됩니다.

5. 안드로이드 가상 머신 시작하기

안드로이드 스튜디오에서 “AVD Manager”를 열어보면 지금 시스템에 깔려있는 이용가능한 안드로이드 VM의 목록이 나타납니다.
아래 명령어를 터미널에서 입력해도 볼 수 있어요.

1

android avd

“AVD Manager”에 들어가신 후 AVD를 선택하고 “Start…”를 클릭하시면 안드로이드 VM이 실행됩니다.

보통의 경우 안드로이드 스튜디오 설치 중 AVD도 설치되지만, 안드로이드 스튜디오 설치 중 AVD가 설치되지 않는 경우는 흔한 경우랍니다. 다음 가이드Android Studio User Guide를 따라서 새로운 AVD를 수동으로 만드실 수도 있습니다.

React Native 설치 테스트하기 (iOS VM으로 확인하기)

React Native command line interface를 이용해 새로운 React Native 프로젝트를 시작해볼게요.
“AwesomeProject”라는 멋진 이름을 가진 프로젝트로요 :)
다음 명령어들을 따라치면 프로젝트가 생기고 가상 iOS머신에서 우리의 프로젝트가 곧장 실행될거에요!

1
2
3

react-native init AwesomeProject
cd AwesomeProject
react-native run-ios

조금만 기다리면 우리의 AwesomeProject가 실행된 모습을 보실 수 있을거에요.

react-native run-ios명령어는 우리의 앱을 실행하는 방법 중 하나일 뿐이랍니다. Xcode에서 실행하셔도 되고, Nuclide를 통해 실행하셔도 됩니다.

React Native 설치 테스트하기 (Android VM으로 확인하기)

만약 바로 위에있는 iOS로 테스트를 해본 상태라면, 마지막 줄의 react-native run-android만 입력하세요.
React Native command line interface를 이용해 새로운 React Native 프로젝트를 시작해볼게요.
“AwesomeProject”라는 멋진 이름을 가진 프로젝트로요 :)
다음 명령어들을 따라치면 프로젝트가 생기고 가상 안드로이드 머신에서 우리의 프로젝트가 곧장 실행될거에요!

1
2
3

react-native init AwesomeProject
cd AwesomeProject
react-native run-android

만약 모든 환경이 제대로 설정되었다면, 안드로이드 VM하나가 실행되고 우리 앱이 안드로이드에 뜰거랍니다.
react-native run-android명령어는 우리 앱을 실행하는 방법 중 하나일 뿐이랍니다. Android Studio에서 실행하셔도 되고, Nuclide를 이용하셔도 됩니다.

앱 수정해보기

만약 위에서 성공적으로 앱이 실행되었다면, 약간 수정을 해봅시다!

1. iOS 앱 수정하기

   • index.ios.js 파일을 열고 몇몇 줄을 수정해 보세요.
   • Command⌘ + R을 눌러서 iOS Simulator를 다시 로딩해 어떤 변화가 있는지 확인해보세요.

2. Android 앱 수정하기

   • index.android.js 파일을 열고 몇몇 줄을 수정해 보세요.
   • R키를 두번 누르거나 Reload를 개발자메뉴에서 눌러 어떤 변화가 있는지 확인해보세요.

이게 끝이에요!

축하합니다! 여러분은 성공적으로 React Native앱을 실행하고 수정까지 해 보셨어요.

이젠 뭘해야할까요?

• 만약 이미 존재하는 앱에 React Native를 적용하고 싶으시다면, Integration guide 문서를 확인해보세요.

• 만약 위 튜토리얼이 제대로 실행되지 않았다면, Troubleshooting 문서를 확인해 보세요.

• 만약 React Native에 대해 좀 더 알고싶으시다면, Tutorial문서를 확인해보세요.

원문: http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html

1
2

유의사항: 현재(11.14) celery가 4.0버전으로 stable 릴리즈가 되었습니다.
아래 문서는 3.1의 마지막 버전의 문서를 번역한 것입니다. 최신 문서는 곧 업데이트 될 예정입니다.

Celery는 공식적인 패키지로 django-celery를 제공합니다. 이 문서는 celery의 현재(2016.11)의 최신 버전인 3.1버전을 기준으로 하고 있습니다.

장고(Django)와 함께하는 Celery 첫걸음

원제: First steps with Django

장고와 함께 Celery사용하기

유의점:
이전 버전의 celery는 장고와 독립적인 패키지를 필요로 했지만, 3.1버전부터는 더이상 그렇지 않습니다. 이제 장고에서 공식적으로 celery를 바로 사용할 수 있도록 지원하며, 따라서 이 문서는 celery와 장고를 간단하게 연결하는 부분만을 다루고 있습니다. 즉, 장고와 함께 사용하지 않고 독립적으로 사용하는 celery와 완전히 같은 API를 사용하고 있기 때문에, 현재는 First Steps with Celery를 읽고나서 다시 이 문서로 오시는 것을 추천합니다. 이미 작동하고 있는 celery 앱을 갖고 계시다면, Next Steps 가이드를 참고하시기 바랍니다.

Celery를 장고 프로젝트에서 사용하시려면, 우선 Celery 라이브러리의 인스턴스를 정의해야 합니다. (이 인스턴스는 아래에서 ‘app’이라고 불립니다.)

만약 최신 장고프로젝트(django 1.10)의 형식을 따라 사용하고 계시다면, 장고 프로젝트는 아래와 같은 형태일 것입니다. (프로젝트 이름: ‘proj’)

1
2
3
4
5

- proj/
  - proj/__init__.py
  - proj/settings.py
  - proj/urls.py
- manage.py

만약 이런 구조로 되어있다면, 추천하는 방법은 장고 프로젝트 폴더(proj/proj/)안에 celery.py파일을 생성하는 것입니다. 아래와 같이요.

1
2
3
4
5
6

- proj/
  - proj/__init__.py
  - proj/settings.py
  - proj/urls.py
  - proj/celery.py
- manage.py

파일: proj/proj/celery.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

from __future__ import absolute_import

import os

from celery import Celery

# Django의 세팅 모듈을 Celery의 기본으로 사용하도록 등록합니다.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

from django.conf import settings  # noqa

app = Celery('proj')

# 문자열로 등록한 이유는 Celery Worker가 Windows를 사용할 경우
# 객체를 pickle로 묶을 필요가 없다는 것을 알려주기 위함입니다.
app.config_from_object('django.conf:settings')
app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)


@app.task(bind=True)
def debug_task(self):
    print('Request: {0!r}'.format(self.request))

위와같이 celery.py파일을 만드신 후에, 장고 프로젝트 폴더의 init.py 모듈에서 이 celery 앱을 import해와야 합니다. 이 과정은 장고가 시작될 때 @shared_task 데코레이터의 사용을 가능하게 합니다.

파일: proj/proj/init.py

1
2
3
4
5

from __future__ import absolute_import

# 아래 import는 장고가 시작될 때 항상 import되기 때문에
# shared_task가 장고에서 작동하는 것을 가능하게 해 줍니다.
from .celery import app as celery_app # Celery를 import합니다.

참고로, 위에서 제시한 장고 프로젝트의 구조는 거대한 프로젝트에 적합합니다. 만약 First Steps with Celery 튜토리얼처럼 작고 간단한 프로젝트라면, 한 모듈(한 파이썬 파일)에서 App과 Task를 모두 다루는 것도 괜찮습니다.

자, 이제 우리가 여기서 처음으로 만든 모듈(celery.py)를 뜯어 보도록 합시다. 우선, 우리는 absolute import를 future에서 import 할 것입니다. 다른 library와 꼬이지 않게 위해서요.

1

from __future__ import absolute_import

그 다음에, 우리는 Celery의 커맨드라인 프로그램을 위해 기본 DJANGO_SETTINGS_MODULE을 가져와서 설정해줍니다.

1

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

이렇게 장고의 세팅파일을 명시해 주는 것은 터미널에서 사용하는 celery커맨드가 장고 프로젝트가 도대체 어디에 있는 장고 프로젝트를 말하는 건지를 알 수 있게 도와줍니다. 이 코드는 항상! App Instance가 생성되지 전에 적어줘야 합니다.

이 다음에 우리가 해야하는 것은 App Instance 객체를 생성하는 겁니다.

1

app = Celery('proj')

위 코드는 celery 라이브러리의 인스턴스가 됩니다. 물론, 여러 다른이름으로 여러개의 인스턴스를 만들 수도 있습니다. 그런데, Django와 Celery를 사용할 때에는 하나만 만들어도 충분합니다.

우리는 장고 세팅 모듈을 Celery의 설정 소스로 삼아줄 것인데요, 바로 이게 여러개의 인스턴스를 만들 필요가 없는 이유랍니다. Celery를 장고 세팅에서 바로 설정할 수 있게 해주기 때문이죠!

이곳에 Object를 바로 넣어줄 수도 있지만, 문자열(Str)로 넘겨주는 것이 더 나은데요, 이렇게 해주면 worker가 Windows나 execv를 사용할 때 Object를 serialize할 필요가 없기 때문입니다.

1

app.config_from_object('django.conf:settings')

이렇게 문자열로 넣어줍시다.

일반적으로, 재사용 가능한 앱을 만드는 것은 모든 작업 코드들을 다른 파일인, 예를들어 tasks.py와 같은 파일에 몰아두는 것입니다. 그리고 celery는 이 모듈들을 자동으로 찾을 수 있답니다.

1

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

위 코드로 celery는 자동적으로 장고 세팅에 재사용 가능한 앱에서 tasks.py를 찾을 겁니다.(단, task들이 있는 파일 이름이 tasks.py여야 자동으로 찾을 수 있습니다.)

1
2
3
4
5
6

- app1/
    - app1/tasks.py
    - app1/models.py
- app2/
    - app2/tasks.py
    - app2/models.py

이와 같은 모양으로, 각 앱 아래에 tasks.py를 두는 것입니다.

이 방법을 통해 개별적 모듈들을 CELERY_IMPORTS 세팅값에 등록해주지 않아도 됩니다. lambda를 통해 필요한 경우에만(재사용 가능한 앱이 있는 경우에만) 자동탐색이 동작하게 되기 때문에, Celery App을 import한다고 해서 장고 세팅 객체를 검사(evaluate)하지는 않습니다.

마지막으로, debug_task라는 예제는 request받은 정보를 단순하게 dump하는 작업만 합니다. 그리고, bind=True라는 Task옵션은 Celery 3.1에서 도입된 기능으로, 현재 작업 인스턴스를 좀 더 쉽게 refer하도록 도와줍니다.

@shared_task 데코레이터 이용하기

우리가 작성한(혹은 지금 보고있는 분이 작성한) task들은 재사용 가능한 앱들에 있을텐데, 이러한 재사용가능한 앱들은 Project자체에 의존하기는 어렵습니다. 그리고 app을 단독으로 직접적으로 import할 수도 없죠.

@shared_task 데코레이이터는 딱딱한(concrete) 앱 없이도 task를 만들 수 있도록 해 줍니다.

demoapp/tasks.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

from __future__ import absolute_import

from celery import shared_task

@shared_task
def add(x, y):
    return x + y

@shared_task
def mul(x, y):
    return x * y

@shared_task
def xsum(numbers):
    return sum(numbers)

참고:
장고-셀러리 예제 프로젝트의 전체 코드는 아래에서 보실 수 있습니다.
https://github.com/celery/celery/tree/3.1/examples/django/

장고 ORM와 Cache를 Celery결과 백엔드로 이용해 봅시다

만약 task의 결과를 장고 database에 저장하고 싶다면 우선 django-celery 라이브러리를 먼저 설치해야 합니다.(위에서 이미 설치했겠지만요!)(혹은 SQLAlchemy Result Backend를 이용해도 됩니다.)

django-celery라이브러리는 Django ORM와 Django Cache Framework를 Result Backend로 사용하게 해 줍니다. 이걸 사용하려면,

1. django-celery 라이브러리를 설치해 줍니다.

1

$ pip install django-celery

2. djcelery를 INSTALLED_APPS(장고 프로젝트 settings.py)에 추가해 줍시다.

3. 데이터베이스 테이블을 만들어 줍시다

1

$ python manage.py migrate djcelery

4. Celery가 django-celery backend를 사용하도록 설정해줍시다.
   4-1. 만약 Database Backend를 이용하고 싶다면..

1
2
3

app.conf.update(
    CELERY_RESULT_BACKEND='djcelery.backends.database:DatabaseBackend',
)

4-2. 만약 Cache Backend를 이용하고 싶다면..

1
2
3

app.conf.update(
    CELERY_RESULT_BACKEND='djcelery.backends.cache:CacheBackend',
)

4-3. 만약 Celery를 Django settings에 직접 연결해 두었다면 app.conf.update부분 없이 바로 괄호 안의 문구를 settings.py안에 넣어두기만 하면 됩니다.

(유의점)상대적 import:__
__import를 하는 방법은 항상 일치해야 합니다. 만약, project.app 을 INSTALLED_APPS 에 import 해 주었다면 from project.app 와 같은 형식으로 import해주어야 합니다. 혹은 각각의 task들이 이름이 모두 다르게 하는 방법도 있습니다.
__추가정보: Automatic naming and relative imports

워커 프로세스 실행해보기

실 배포 환경에서는 worker를 시스템 daemon으로 사용해야합니다. (Running the worker as a daemon 을 참고하세요.) 하지만, 테스트할 때에는 worker instance를 celery worker manage 커맨드를 통해 시작하는 것이 더 편리합니다. 장고의 runserver를 이용하는 것 처럼요 :)

1

$ celery -A proj worker -l info

위 코드로 간단하게 실행이 가능하고, command-line 옵션을 모두 보려면

1

$ celery help

라고 쳐 봅시다.

이제 어디로 가야할까요?

만약 좀 더 배우고 싶다면, Next Steps 튜토리얼을 보세요. 그 튜토리얼을 마친 이후에는 User Guide를 보고 공부할 수 있을거에요.

오늘 크롬을 켜고 인터넷 브라우징을 하는데 일상적으로라면 Native Adblockr로 인해 광고가 뜨지 않아야 하는 곳에서 광고가 떴다.

크롬에 들어가보니 크롬측에서 앱을 비활성화 한 것. 재활성화 하려 해도 크롬에서 중단시켰다며 활성화가 되지 않았다.

그래서 앱의 최근 리뷰 중 개발자 댓글로 프로그램이 구성된 방법이 uBlock + 커스텀필터 라고 하고, 커스텀 필터는 개발자 깃헙 소스인

https://raw.githubusercontent.com/NativeHyun/HyunGuard/master/General/general.txt

이 파일을 참고해 작동한다고 했다.

그래서 커스텀 Chrome Native Adblockr를 구성해보기로 생각.

크롬 웹 스토어에서 uBlock을 검색, 두가지가 나왔다. uBlock orign와 uBlock.

전자가 더 많은 리뷰가 있어 전자로 다운받았다.

그리고 uBlock의 세팅(크롬 우측상단 앱 아이콘 클릭시 나오는 팝업의 좌측 상단에 작은 설정아이콘)에 들어가 아래와 같이 사용자 필터로 위의 깃헙소스를 추가해 준다.

그러면 Native Adblockr와 정확히 동일하게 광고가 차단된다.

Ps. 왜 앱이 내려간건지 모르겠다..^^;;

기본적으로 커스텀맥(해킨토시) 설치는 큰 어려움이 따른다.

그런데, 이번에 설치한 OS X El Capitan은 기본적인 설정만으로도 상당히 쉽게 설치되었기 때문에(그래도 약간의 설정은 필요하다) 매우 놀랐다.

설치 PC사양은 다음과 같다.

CPU: I5-4670 (Haswell, 하스웰)
RAM: DDR3 8Gx2 (<span id="grpDescrip_">G.SKILL Ripjaws X Series 16GB (2 x 8GB)</span>)
M/B: ASRock ASRock H87 Performance 에즈윈
HDD: WD Blue 1TB (8MB cache / 2.5")
VGA: AMD HD7970 3G (HIS 라데온 HD 7970 기가에디션 OC D5 3GB IceQ X² 잘만테크)

설치를 시도한 OS는 OS X 10.11.6 (El Capitan)버전이었고, 설치 디스크 제작은 순정 맥을 이용해 제작했다.

설치에 사용한 Kext와 여러 프로그램들은 아래 드롭박스 링크에서 받을 수 있다. PW:installosx

[ 다운로드 ]

[설치 과정]

가장 먼저 해야 하는 것은 바로 순정 설치 디스크를 제작하는 것이다.

순정 El Capitan을 받기 위해 맥의 AppStore에서 El Capitan을 다운로드 하면 LaunchPad에 저장된다.

저장이 완료되면 설치 창이 뜨는데, 간단히 무시하고 TonyMac의 Unibeast를 통해 GUI로 부팅 디스크를 만든다.

El Capitan / UEFI만 선택하면 부팅 디스크를 아주 깔끔하게 만들어준다.

부팅 및 설치는 전면 USB3.0단자를 이용해 이루어졌다.(혹자는 usb2.0으로 진행하라고 했지만, 큰 문제 없이 진행되었다.)

USB에는 여러 프로그램(MultiBeast / Clover / CloverConfigurator / 기타 kexts/Scripts)을 담아두면 OS X 설치 이후에 좀더 편안하게 설치 마무리를 진행할 수 있다.

위쪽에 올려둔 드롭박스 링크의 압축파일에는

• Clover Configuator : EFI 파티션 자동인식 및 마운트 기능 / config.plist 수정기능 제공 / Clover 자동 확인 및 업데이트 제공

• Clover : 클로버 부트로더. OS X으로 부팅 가능하게 만들어준다.

• MultiBeast : OS X의 각종 드라이버(kext파일들)를 EFI파티션에 잡아준다. 이번설치에서는 굳이 쓰지 않아도 성공적으로 설치됨.

• Kext파일들 : 위 HW에 필요했던 기본적인 kext들. EFI파티션의 KEXTS폴더에 10.11버전 폴더에 넣어주면 된다.

• MenuMeters : OS X 설치 후 시스템 상태를 메뉴바에서 그래픽으로 볼 수 있게 지원. OS X설치후 항상 쓰는 프로그램이라 넣었을 뿐, 운영체제 설치 자체와는 관련이 전혀 없다.

• AudioCloverHDMI : OS X에서 기본적으로 지원하지 않는 HDMI 오디오 출력을 가능하게 만들어준다. 스크립트형.

이렇게 구성되어있다.

+alpha:

이번에 사용한 메인보드가 ASRock보드인데, 부트로더가 efi파일을 잡지 않아 버그가 난 경우가 있었다.

https://www.x86.co.kr:447/qa/1274453

클로버를 저렇게 설치해주면 된다.

이 글은 root 계정에서 작업되었습니다.

VPS등으로 SSH접속을 할 때 bash가 아닌 zsh+OhMyZsh조합을 이용하면 좀 더 편한 관리가 가능하다.

VPS에 접속 한 후 가장 먼저 해야 하는 작업, apt 패키지를 최신 상태로 업데이트+업그레이드 하기.

apt update && upgrade

OhMyZsh 설치에는 git이 사용된다. zsh와 git을 설치해 주자.

apt install zsh git

Zsh을 좀 더 예쁘게 사용하기 위한 방법, Oh My Zsh. (http://ohmyz.sh)

curl을 이용해서 받기 원한다면

sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

wget을 이용해 받기 원한다면

sh -c "$(wget https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

본 포스트에서는 curl을 이용한다.

설치가 완료되면 아래와 같이 zsh로 연결된다.

아래 내용은 root 계정 + virtualenv환경에서 진행됩니다.

Ubuntu 14.04 LTS / Python3.4.4 에서 pip로 mysqlclient를 설치하려고 하면 다음과 같은 에러가 발행한다.

OSError: mysql_config not found

이 에러는 다음의 apt 패키지 설치로 해결할 수 있다.

apt install libmysqlclient-dev

그러나, 이 모듈을 설치한 이후에도 아래와 같은 에러가 발생 할 수 있다.

unable to execute 'x86_64-linux-gnu-gcc': No such file or directory

즉, GCC가 없어 컴파일을 할 수 없다는 에러이기 때문에 다음과 같이 build-essential을 설치해줘야 한다.

apt install build-essential

다음을 모두 설치한 후에는 위와 같이 설치가 깔끔하게 된다.

우분투 14.04에는 기본적으로 Python2와 Python3이 설치되어있다.

그러나 pip로 virtualenv를 설치할 경우 기본적으로 python2를 가상환경의 기본 Python으로 잡게 되는데,
이번 게시글에서는 mkvirtualenv명령어의 기본값을 python3으로 설정하는 방법을 안내한다.

따라서 virtualenv를 사용하기 위해서는 APT를 통해 다음 모듈들을 설치한다.

apt update && upgrade




apt install python-dev python3-dev python3-pip

(참고: python-pip는 python2용 pip, python3-pip는 python3용 pip3을 설치한다.)

pip3 install virtualenv virtualenvwrapper

설치가 완료된 후, nano / vi / vim 등의 편집기로

bash 쉘을 사용할 경우

nano ~/.bashrc

zsh 쉘을 사용할 경우

nano ~/.zshrc

편집기에 들어가

# python virtualenv settings
export WORKON_HOME=~/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON="$(command \which python3)"  # location of python3
source /usr/local/bin/virtualenvwrapper.sh

위 내용을 붙여준다.

네번째 문장에서의 virtualenvwrapper.sh는

find /usr -name virtualenvwrapper.sh

을 통해 나오는 스크립트의 위치로 지정해 주면 된다.

bashrc나 zshrc의 수정이 끝난 경우

​
mkdir ~/.virtualenvs

를 통해 virtualenv들이 담길 폴더를 만든다.

이제 쉘을 종료한 후 다시 연결한 후

​
mkvirtualenv 가상환경이름

하면 ~/.virtualenvs 안에 가상환경이 생긴다.

​
workon 가상환경이름

을 통해 가상환경을 활성화 시킬 수 있으며, 가상환경 이름을 입력하지 않는 경우 가상환경의 리스트가 출력된다.

가상환경을 빠져나오기 위해서는

​
deactivate

를 입력하면 된다.

Mac OS X El Capitan(10.11.5)에서 pip로 virtualenvwrapper를 설치 시도시 six-1.4.1버전을 제거하는데 권한이 없다고 나온다.

Sudo를 통해 관리자 권한으로 실행해도 같은 오류가 발생하는데, 이것은
https://github.com/pypa/pip/issues/3165
이슈에서 답을 찾을 수 있다.

바로 Mac OS X El Capitan의 System Integrity Protection때문이다. ROOT 계정으로도 제거하지 못하기 때문에, 해결방법은 다음과 같다.

pip install virtualenvwrapper --ignore-installed six

위의 옵션으로 내장된 모듈 six를 건너뛰고 설치하게 만드는 것이다.