2017. 1. 27. 14:29 BlahBlah

블로그 이전

Tistory에서 github pages로 블로그 이전 했습니다. 티스토리 백업 중지는 폐쇄 전 움직임 같아 보여 안심할 수가 없네요.


이전한 블로그 주소는 다음과 같습니다!

RSS Feed 주소 - https://elky84.github.io/


앞으로는 이쪽에서 블로깅을 하게 됐으니~~ 새로 RSS 구독 신청 부탁드립니다!



Posted by 엘키 엘키

댓글을 달아 주세요

2016. 11. 22. 21:00 Scripts/Python

python 입문기

여러 글에서 밝혀왔듯 나는 rubyist다. ruby를 사랑하는 이유는 내가 접했던 언어 중 가장 즐겁게 코딩이 가능했기 때문이다. rails는... 음 이제와 밝히자면, 사실 좀 어려웠다.

ruby가 어려웠다기보다는, 웹에 대한 이해도가 전무한 개발자가 쉽게 기능 개발을 해볼 순 있지만, production 과정까지 가는게 쉽지만은 않았다랄까?


ruby는 해외와는 달리 국내에서는 비주류라는 점이 고민의 포인트가 되긴했지만, 해외에서의 높은 인지도로 인한 풍부한 자료는 그 거부감을 상쇄 시켜줬다.


성능상의 이슈가 있다지만 어지간한 규모의 트래픽으론 성능 이슈를 제기할 정도로 열악한 것도 아니다.


오히려 가장 아쉬웠던 점은 rails가 갖는 장점인 학습 속도에 비해, 단점인 프로덕션 과정에서의 학습 비용이 큰 편이었던 점이라고 할 수 있다.


특히 DB관련한 연동은 추상화 레이어로 인한 개발 과정 이득은 있지만, 인덱스 개념이나 데이터 모델링 개념이 부족한 경우에 프로덕션 트러블의 요인이 되기 쉽상이다. 물론 이는 다른 언어들의 프레임워크들도 가진 문제지만, ruby on rails는 쉬운 학습 비용이 장점인 프레임워크이기 때문에, 이 부분이 조금 더 감점 요인이라고 생각한다.



물론 나는 위 모든 점을 감안해도 rails가 좋다. 여전히.

ruby도 물론이고.


몇번이나 이런 질문을 받은 적이 있다. 왜 rails를 썼냐고.

국내 기준으로 C++이 여전히 주류이고, 웹 기반 서버로 많이 넘어가던 시기에도 php, asp.net, node.js, jsp 등이 주류이던 시기에, 심지어 python도 아닌 ruby였냐고.


그 질문에 나는 항상 같은 대답을 했다.


"내가 그 당시 학습하려 시도한 모든 언어들 중에 ruby가 가장 즐거웠노라고."


업무는 내 삶에서 큰 부분을 차지한다.

그 과정이 즐겁지 않다면, 내 삶이 즐겁지 않을 수 도 있다.

그래서 나는 내가 업무를 즐겁게 하기 위한 선택을, 가능하다면 많이 하려고 하는데, 그 과정에서 ruby는 꽤나 높은 점수를 줄 수 있었다.


그렇다면 python도 즐거워서 골랐나?

그렇진 않았다.


내가 느낀 국내 인지도는


Java > C++ > C# > Python > Ruby > Golang = scala 였다.

사실 나는 ruby 다음 언어로 Golang이나 scala를 해보고 싶었음을 지난 글에서 밝힌 바 있다.


하지만 현재 시점에서 “웹 서버”를 구현해야 할 언어를 골라야 한다는 관점에서, Golang은 시기상조인 면이 많고, 특히 웹서버로 구동하기엔 여타 프레임워크보다 아쉬움을 갖고 있다.

scala로 Play! 프레임워크를 사용해보려 고민도 했으나, 그러기에는 내가 너무 java에 대한 이해도가 부족했다.


게다가 나는 C++ > C# > Java의 선호도를 갖고 있고.



그리하여, ruby와 비슷한 급(?)의 언어이면서, 국내에서의 인지도가 ruby보다 높은 python을 해보기로 했다.


rails를 다시 선택하는 방법도 있었지만, 웹 프레임워크로써 프로덕션 레벨에 올려본 것이 rails 하나이기 때문에 다른 웹 프레임워크의 장단점과 다른 언어 학습의 기회를 같이 맛보기 위한 선택을 하게 됐다.



그렇게 python을 입문하고 나니, 몇 가지 감상이 들어 3달여간 사용해본 경험을 정리해보고자 한다.



indent 강제.

사실상 내가 python보다 ruby를 애호하게 된 이유다.


indent 에도 취향이 있는 것이고, 나는 프로그래밍이 재밌어야, 일이 재밌어야 한다고 주장하는 입장에서 자유도를 억제하는 느낌드는 파이썬의 indent강제는 거부감이 들었다랄까?


막상 사용해보니 코드 읽기에 큰 강점이 있더라.


실제 동작을 유추하기 쉽다보니, 여러모로 메리트가 있었다.


다만 다른 언어들과 조금 다른 것들이 많은데, 예를들어


조건문이나 함수 정의에 :이 마지막에 붙는 점이다.


# ruby
def test()
	statement
# python
def test(abc):
	statement
다음과 같아 진다.

조건문의 경우에도 마찬가지로,

# ruby
if aaa
	statement
end
# python
if aaa:
	statement
같은 형태가 된다.


다들 아시다시피, 들여쓰기가 depth에 따라 코드가 어떤 단락에 포함되는지를 결정짓는다.
# ruby
# 들여쓰기 1
if aaa
	statement
	statement2
end

# 들여쓰기 2
if aaa
	statement
statement2
end
# python
# 들여쓰기 1
if aaa:
	statement
	statement2

# 들여쓰기 2
if aaa:
	statement
statement2
루비는 두 결과가 같다.
하지만, 파이썬은 다르다. 들여쓰기 2에서, aaa 조건이 성립하지 않아도 statement2는 실행된다.


이런 제약이 거추장 스럽게 느껴진게 사실이다.
C++에 비해 상대적 자유도가 낮은 java를 선호하지 않았던 이유도 같은 이유였기 때문인데, 굳이 스크립트 언어에 제약이 있는 언어를 고르지 않겠단 생각이었다.

헌데 막상 파이썬을 사용해보니, 협업에 큰 장점이 있었다.
RSA 알고리즘을 한 줄에 짤 수 있네 마네 말도 많은 perl을 겪은 나로썬, 또 지나친 자유도로 소통 비용을 크게 요구하는 C++을 오래 사용해온 입장에서 크게 와닿으며, 인정하게 된 것은, indent강제가 코드 읽기 비용을 크게 낮춰준다는 것을 확실히 느낄 수 있었다.

이는 디버깅이나 오류 비용이 크게 낮아진다는 얘기기도 하다.

내가 크게 걱정했던 표현력이 막상 크게 제한되지도 않았다.
팀작업에서 큰 이득이 있었고, 오픈소스 코드 분석에서도 큰 장점이 됐다.

아니, 다른 언어들도 이래야 하는거 아닌가 싶을 정도로 마음에 들었다는게 맞겠다.

대다수의 팀에서 일하는 프로그래머들은 팀 코드만 보지 않는다.

오픈소스 진영에서의 개발은 특히나, 다른 사람의 코드를 봐야 할 일이 아주 많다.

그런 측면에서 아주 큰 강점이 있다는 생각이 들었다.



거기에 부가적으로, python도 말하면서 코딩하는 기분이 들었다.
if user is None:
	blah blah

이 얼마나 직관적인가?


django로 개발하면서 머릿속의 내용을 코드로 옮기는데에 멈칫하는 과정없이 술술 진행될 수 있었던 것은, python의 문법이 유연하진 못하지만, 대화하는 느낌이 드는 언어였기 때문이다.


이 점이 나에게 python에 대한 인상을 좋게 만들어주는 요인이 되었다.



나에게있어 python은 어려운 언어는 아니었다.

사실 쉽게 익숙해진 언어라 볼 수 있다고 본다.



ruby를 먼저 접했어서 인지, 아니면 python 자체가 쉬워서인지는 잘 모르겠지만, 여러모로 ruby와는 또 다른 즐거움을 가져다준 언어였다고 생각한다.



이어지는 django 사용기에 조금 더 디테일한 python 사용기를 담아볼 예정이다.

'Scripts > Python' 카테고리의 다른 글

python 입문기  (0) 2016.11.22
Posted by 엘키 엘키

댓글을 달아 주세요

2016. 9. 27. 21:24 Web/Django

Django Celery 사용법

설치

  • pip install -U Celery

  • pip install django-celery

  • 데이터베이스 migration 필요. [djcelery를 위해]

Django 설정

  • settings.py에 아래 내용을 추가한다.

import djcelery

djcelery.setup_loader()

BROKER_URL = "amqp://guest:guest@localhost:5672//"

  • settings.py 파일에 추가

INSTALLED_APPS = (

'djcelery',

'myapp',

)

    • 두 가지를 추가해야 한다. myapp은 개발하고 있는 app의 이름이 되겠다.

Task 생성

from djcelery import celery

@celery.task(name='tasks.add')

def add(x,y):

 return x + y


@celery.task(name='tasks.sleeptask')

def sleeptask(i):

 from time import sleep

 sleep(i)

 return i

  • 테스트 목적으로 두 개의 task를 만들었다. 하나는 즉시 값을 리턴하는 add함수와 10초 뒤에 task를 반환하는 sleeptask 함수이다.

View 만들기

  • django app의 views.py에 아래의 내용을 추가

from django.http import HttpResponse

from myapp import tasks


def test_celery(request):

   result = tasks.sleeptask.delay(2)

   result2 = tasks.add.delay(2,5)

   return HttpResponse("this is task test (id : %s)"%result.id)


이렇게 view 만들어놓고 url view 호출할 있도록 해야한다.


urlpattern 아래 내용을 추가해준다.


import views as taskview


urlpatterns = patterns(

                      ...

                      url(r'^test$',taskview.test_celery),

                      )

가동

  • python manage.py celeryd -l info

직렬화

Consumer

주의 사항

  • 15672는 웹 포트다. 5672 포트로 연결해야 한다.

  • 연결이 RabbitMQ에서 끊어질 시에는 RabbitMQ 관리 웹 페이지에서 Can access virtual hosts가 설정되어있는 계정인지 확인해볼 것.

  • tasks로 만들어 던지는 함수에 req를 바로 던질 수 없다. pickle 가능한 object만 던져야 한다. 즉 파라미터들을 꺼내서 던져야 한다는 의미.

  user_no = int(req.session['user_no'])

  return tasks.celery.delay(user_no)

참고


'Web > Django' 카테고리의 다른 글

Django Celery 사용법  (0) 2016.09.27
Django 사용법 정리  (0) 2016.09.27
웹서버 중에서 Django를 선택한 이유  (0) 2016.09.27
Posted by 엘키 엘키

댓글을 달아 주세요

2016. 9. 27. 21:17 Web/Django

Django 사용법 정리

Django

Django package

python

python package


'Web > Django' 카테고리의 다른 글

Django Celery 사용법  (0) 2016.09.27
Django 사용법 정리  (0) 2016.09.27
웹서버 중에서 Django를 선택한 이유  (0) 2016.09.27
Posted by 엘키 엘키

댓글을 달아 주세요

TCP 서버

  • 장점

    • 성능이 좋다. (=빠르다)

    • 커넥션 기반

    • stateful 기반

      • 가용성을 확보하기 어려움.

      • 코딩은 용이함.

    • notify가 가능. (클라이언트의 요청없이 서버가 패킷 전달)

  • 단점

    • 커넥션 기반이라, 커넥션 유실/복구 이슈

    • 로직간 결합도가 높아지는 경우가 자주 발생한다.

    • 서버 크래시에 대한 높은 리스크.

웹 서버

  • 장점

    • stateless 기반

      • 가용성 확보가 쉬움.

      • state는 모두 db에 존재.

    • 오픈소스 프레임워크가 많고, 검증되어있음.

    • 프레임워크 내에서도, 다양한 기능들이 오픈소스로 배포되고 쉽게 사용 가능.

    • 로직간 결합도가 낮다.

      • state가 없음으로

    • 서버 크래시에도 큰 장애는 없다.

      • 어지간해서는 서버 크래시도 없다.

        • 부하로 인한 timeout이나, 스크립트 오류가 발생할 뿐.

  • 단점

    • 모든 데이터는 요청마다 db를 조회해야해서 성능이 떨어진다.

    • notify가 어려움. (1-request, 1-response 구조)

    • 다른 피어와 통신용으로 사용하기 위해선 polling이 필요하다. [like ajax]


Posted by 엘키 엘키

댓글을 달아 주세요

Django

  • 장점

    • 굉장히 쉽게 배울 수 있는 프로그램 언어인 Python을 기반으로 한다.

    • 인증, 관리와 같이 거의 대부분의 사이트에서 사용하는 기능들이 기본 모듈로 제공된다.

    • 성공적인 도입 사례가 있습니다.(Instagram 등)

    • 높은 코드 완성도를 유지할 수 있다.

      • python의 강제된 indent가 코드 완성도에는 일조함.

    • IDE 지원이 훌륭한 편이다.(Pycharm, Visual Studio 등)

    • AWS, Google Cloud, Azure등에서 전폭적으로 초기 단계부터 지원한 프레임워크다.

      • deploy 및 운용에 대한 개발 비용을 크게 아낄 수 있다.

  • 단점

    • 한글 문서가 아주 풍부한 편은 아니다.

    • typeless 언어의 약점은 그대로 보유하고 있다.

    • python에 대한 높은 이해도가 필요하다.

      • Django는 문제를 python으로 해결하는 편이다. (프레임워크 특화 기능보다)

    • 성능 문제에서 자유롭지 못하다.

      • python은 ruby보다 빠를 뿐이다.

        • Django도 rails보다 빠를 뿐이다.

node.js

  • 장점

    • V8 엔진을 기반으로 한 성능이 뛰어납니다.

    • 오픈소스 문화권하에 있어서만은 아닌, 풍부한 모듈 지원. (유독 많다. 그것도 짧은 기간내에 급속히 증가)

    • C++로 필요한 모듈 작성 가능.

    • 싱글스레드, 비동기 IO 처리에 기반한 빠른 속도

    • 파일 I/O나 네트워크 처리를 이벤트 드리븐 방식으로 처리하기 때문에 빠른 처리가 가능함

    • CPU의 대기시간을 최소화 할 수 있음.

    • CPU 부하가 적고, 많은 커넥션을 동시에 처리해야 하는 구조에 적합.

    • 자바스크립트를 이용해서 개발할 수 있기 때문에 프론트엔드 개발자의 진입장벽이 낮음.

    • 기존 Java 서버에 비해 생산성이 높음

  • 단점

    • 싱글스레드 모델이기 때문에 하나의 작업에 시간이 오래걸리면 시스템 전체의 성능이 급격하게 떨어짐

    • 에러가 발생할 경우 프로세스 자체가 죽어버리므로 주의해야 함(watch dog 등으로 처리 가능)

    • 멀티코어 활용을 위해서 cluster 모듈을 이용해야 하고, 세션을 공유할 경우 부가적인 작업이 필요함

    • 불편한 비동기 프로그래밍 모델

      • 다음 할 일을 계속 콜백(callback) 함수로 넘기는 스타일로 코딩을 하다 보니 Pyramid of Doom이라 불리는 중첩 코드가 나오기 쉽상.

      • 이 문제를 해결하기 위해 비동기 제어 흐름을 좀 더 쉽게 표현하기 위한 async 모듈, underscore 등도 사용했지만, 이러한 프로그래밍 스타일은 Django나 Ruby on Rails에 비교해서 코드의 가독성을 현저히 떨어진다.

    • 초급 프로그래머라도 쉽게 할 수 있다 얘기는 거짓말.

      • 학습 난이도가 높은 편이다.

    • 시스템 관리자에게 쉽지 않은 아키텍쳐.

    • 자바스크립트로 로직을 구현하는 것은 어울리지 않다.

      • typeless 언어가 가져야하는 코드 가독성이 javascript는 부족하기 때문.

rails

  • 장점

    • ruby언어의 장점을 근간으로한 뛰어난 가독성, 그리고 표현력.

    • twitter, github, redmine 이라는 성공적인 도입 사례.

    • 검증된 빠른 개발 속도.

      • rails로 서비스를 개발한 후, 서비스 트래픽이 높아지는 단계에서 다른 플랫폼으로 갈아타는 사례가 많다는 것이 이를 입증함.

    • MVC 모델을 온전히 구현하고 있다.

    • github로 공개된 기능 패키지 수 3위 권을 다 년간 유지하고 있다.

      • 가져다 쓸 수 있는 기능이 아주 많다는 의미.

  • 단점

    • 비동기 API가 너무나 부족함.

    • GIL과 부족한 비동기 API로 인한 성능 이슈가 크게 대두 됨.

      • python 보다도 느림

        • 성능 문제로 인한 최적화 한계를, 다른 플랫폼으로 풀었다는 것은, rails의 미래에 대한 큰 숙제다.

      • 이로 인해, 고도화 과정이 반드시 필요하며, 고도화 과정은 rails 이외의 영역에 대한 높은 이해도가 필요한 경우가 많다.

    • 과도한 수준의 추상화로, 원리를 이해하는 데에는 여타 플랫폼보다 더 큰 시간이 든다.

asp.net

  • 장점

    • C# 사용 가능

    • Visual Studio 위에서 개발 가능

    • MVC 패턴을 제대로 지원함.

      • Model, View, Controller로 프로그램이 분할되어 복잡성을 다루기 쉬워집니다.

      • ViewState, 서버 기반 폼(server-based form)을 사용하지 않아서, Web 응용 프로그램에 대한 완전한 제어를 원하는 개발자들에게 이상적인 환경입니다. (WebForm에 비해서 MVC는 추상화의 수준이 낮습니다. WebForm의 경우, WebForm만 알아도 어떻게든 돌아가는 Website를 만들 수 있지만, MVC는 그게 안 됩니다. 그러다 보니 1강에서처럼 그렇게 많은 선수 과목이 필요하게 되었습니다. )

      • Website의 흐름을 마음대로 제어할 수 있습니다. 과거 WebForm에서는 blog.net/posts/23 같은 주소로 글을 접근할 수 있게 하려면, IIS를 건드려야 했지만, MVC에서는 매우 쉽게 이 문제를 해결할 수 있습니다.

      • 테스트 주도 개발(Test-Driven Development, TDD)을 하기에 좋습니다.

      • 큰 팀에서 많은 개발자와 디자이너들이 Web 응용 프로그램에 높은 수준의 제어를 원한다면 추천할만합니다.  

  • 단점

    • 윈도우 서버 위에서만 온전히 동작.

    • 개발자 풀이 좁음.

    • 오픈소스권 문화가 아니라서 MS가 제공하지 않는 기능은 .NET 플랫폼 지원언어로 개발해야함.

spring [java]

  • 장점

    • 크기와 부하의 측면에서 경량.

    • 제어 역행(IoC)이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모.

    • 관점지향(AOP) 프로그래밍을 위한 풍부한 지원을 함.

    • 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(Container)라고 할 수 있음.

    • 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있음.

    • 대한민국 전자정부 표준 프레임워크의 기반 기술

  • 단점

    • 설정이 복잡한 편이다.

    • 컴포넌트가 다양한 건 사실이나, 컴포넌트로 존재하지 않는 기능을 사용할 경우에 개발 공수가 크다.

play [play]

  • 장점

    • 국내의 많은 교육기관에서 가르치고 있는 Java 기반 프레임워크인 만큼 누구나 쉽게 접근할 수 있습니다.

    • 웹 서버를 내장하고 있어 별도로 서버를 세팅할 필요가 없다.

    • 일반적인 Java 어플리케이션은 빌드하는데 굉장히 오랜 시간이 소모되지만, Play의 경우 변경된 내역에 대해 자동으로 빠르게 빌드하기 때문에 개발 및 테스트 시간을 크게 줄일 수 있습니다.

    • 가장 훌륭한 IDE인 Eclipse와 Intellij에서 Play!를 완벽하게 지원합니다.

  • 단점

    • 한글로 된 문서가 거의 없습니다. 진행중이던 문서화 작업이 중단되었으며, 관련 서적과 블로그를 통해 제공되는 강좌들은 오래되어 Play! 최신 버전과 맞지 않습니다.

    • 번들이라고 하는 서드파티 모듈들이 많지 않고 그나마 있는 것들도 프레임워크 버전에 맞춰서 버전업이 되지 않아 활용 가치가 매우 낮습니다.

    • Twitter의 Rails나 Instagram의 Django와 같은 성공적인 도입 사례가 아직까지 없습니다.

    • Java와 Scala를 골라서 개발할 수 있다고 이야기하지만 실제로 Scala를 공부하지 않으면 개발을 진행하기 어려울 정도로 Scala의 비중이 높습니다.

code igniter [php]

  • 장점

    • PHP 기반 full stack framework 중에서 성능이 매우 뛰어납니다.(Phalcon과 Slim은 경량 프레임워크)

    • 서비스가 성장하여 개발 인력을 늘려야 할 때 비교적 쉽게 관련 기술 보유자를 구할 수 있습니다.

  • 단점

    • RESTful 서비스에 적합한 구조가 아닙니다.

    • Session 처리가 안정적이지 않고, DB Session 만을 지원하기 때문에 File이나 Memory 기반의 Session을 사용하기 위해서는 별도의 개발이 필요합니다.

    • PHP 언어 특성상 구조적으로 깔끔한 코드 작성이 어렵습니다.

    • ORM 기반의 Model이 아니라 코드를 통해 스키마를 파악하기 어렵습니다.


'Web > Django' 카테고리의 다른 글

Django Celery 사용법  (0) 2016.09.27
Django 사용법 정리  (0) 2016.09.27
웹서버 중에서 Django를 선택한 이유  (0) 2016.09.27
Posted by 엘키 엘키

댓글을 달아 주세요

2016. 8. 20. 15:33 OS/Linux

CentOS7 MySQL 설치

CentOS7 MySQL 설치

설치

계정 생성 및 권한 부여


'OS > Linux' 카테고리의 다른 글

CentOS7 MySQL 설치  (0) 2016.08.20
CentOS7 redmine 설치  (0) 2016.08.20
CentOS 7 rails 서버 세팅  (0) 2016.02.08
CentOS 7 FTP 서버  (0) 2016.02.08
윈도우 서버에서 리눅스 서버로의 감상  (0) 2015.11.15
Cent OS 7 svn 설치  (0) 2015.11.13
Posted by 엘키 엘키

댓글을 달아 주세요

2016. 8. 20. 15:32 OS/Linux

CentOS7 redmine 설치

CentOS7 Redmine 설치

방화벽 개방

  • ​firewall-cmd --permanent --zone=public --add-port=3000/tcp

  • firewall-cmd --reload

GCC 설치

  • yum -y install gcc cpp gcc-c++ compat-gcc-34 gcc-gfortran flex

Ruby와 Passenger 빌드에 필요한 헤더파일

  • yum install openssl-devel readline-devel zlib-devel curl-devel libyaml-devel

Mysql과 헤더파일

  • yum install mysql-server mysql-devel

Apache과 헤더파일

  • yum install httpd httpd-devel

ImageMagick과 헤더파일

  • yum install ImageMagick ImageMagick-devel


Ruby설치



Bundler 설치

  • gem install bundler --no-rdoc --no-ri

redmine 설치 3.16 안정화버젼이라서 이거 선택함

  • wget http://www.redmine.org/releases/redmine-3.1.6.tar.gz #/usr/local 에서 작업중

  • tar zxvf redmine-3.1.6.tar.gz

  • mv redmine-3.1.6 /usr/local/redmine #폴더명변경


설정 파일

  • cd /usr/local/redmine/config

  • cp database.yml.example database.yml

  • vi database.yml

production:

adapter: mysql

database: redmine

host: localhost

username: redmine

password: redmine

encoding: utf8

Gem Package 설치

  • bundle install --without development test

테이블 생성 및 초기 데이터 입력

  • cd /usr/local/redmine 으로 이동하

  • rake generate_secret_token

  • RAILS_ENV=production rake db:migrate

  • RAILS_ENV=production rake redmine:load_default_data

    • #한국어 ko 입력

구동

  • bundle exec rails server webrick -e production -d -b 0.0.0.0

    • 데몬으로 실행 여기까지 끝


FAQ

  • 설치 중에 bundle install 시 에러 내용을 자세히 보면 마지막 문구에 뭐를 설치하라고 gem 뭐뭐뭐 이렇게 명령어 나오는데 복사해서 그걸 그대로 입력해서 설치 후 bundle install 다시 실행해야 한다. bundle인스톨은 /usr/local/redmine 에서 해야 한다

  • gem 인스톨 안될시에 gem query --remote -n 이름-d -a 이 명령어로 버젼 높은걸로 찾아서 인스톨

redmine 테마

  • /usr/local/redmine/public/theme 이쪽폴더에 넣고 재시작

redmine 플러그인

  • /usr/local/redmine/plugins 폴더에 넣고 /usr/local/redmine 에서 하단을 실행하여 플러그인을 추가해야한다.

  • bundle install --without development test

  • rake redmine:plugins:migrate RAILS_ENV=production

redmine 구글이용하여 메일보내기

  • cd /usr/local/redmine/config #에서 configuration.yml.example 을 configuration.yml로 만든후

  • vi configuration.yml #들어가서

production:

   email_delivery:

   delivery_method: :smtp

   smtp_settings:

   enable_starttls_auto: true

   address: "smtp.gmail.com"

   port: 587

   domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps

   authentication: :plain

   user_name: "계정명@gmail.com"

   password: "비밀번호”

    rmagick_font_path: /usr/share/fonts/nanumfont/NanumGothic.ttf


  • 이렇게 해도 메일이 안 보내지는 이유는 구글 계정에 대한 보안 설정 오류 일 가능성이 높음.


Redmine 관리


'OS > Linux' 카테고리의 다른 글

CentOS7 MySQL 설치  (0) 2016.08.20
CentOS7 redmine 설치  (0) 2016.08.20
CentOS 7 rails 서버 세팅  (0) 2016.02.08
CentOS 7 FTP 서버  (0) 2016.02.08
윈도우 서버에서 리눅스 서버로의 감상  (0) 2015.11.15
Cent OS 7 svn 설치  (0) 2015.11.13
Posted by 엘키 엘키

댓글을 달아 주세요


블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today29
Total1,605,483

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함