서비스를 운영하다보면 서버에서 이메일을 발송할 일이 있을때 여러가지 이유로(보안상 계정 관리, 발송한 메일을 확인 등) 지메일 계정으로 쓰고 싶은 경우가 종종 있습니다. 지메일은 메일사본을 보관해주고 웹인터페이스를 제공하기 때문에 저는 중요한 고객서비스를 제공할때 자주 사용하고 있습니다. 

이번에 신규서버에 설정할 일이 생겨서 설정 과정을 공유합니다.


이번에 제가 테스트한 환경은 Linux Mint 18.3 입니다. 

하모니카 커뮤니티 에디션, Linux Mint 18.3, Ubuntu 16.04 등은 모두 동일한 방법을 사용해서 적용하시면 됩니다.


패키지 설치

필요한 모든 패키지 설치는 다음과 같이 실행합니다.

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules


처음 설치하시는 경우 postfix 설정 도우미가 어떤 용도로 사용할지 물어보게 됩니다. 이때 Internet Site 를 선택하세요.


postfix 환경설정

postfix 설정파일 편집

sudo vi /etc/postfix/main.cf 명령으로 설정파일을 편집합니다. 

항상 편집을 시도하기 전에 원본을 복사해서 보관해두는 것을 잊지마세요.

파일의 내용은 아래내용을 그대로 사용합니다.


# gmail smtp setting

relayhost = [smtp.gmail.com]:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options = noanonymous

smtp_tls_CAfile = /etc/postfix/cacert.pem

smtp_use_tls = yes


계정정보 파일 생성

sudo vi /etc/postfix/sasl_passwd 명령으로 계정정보 파일을 생성하고 아래의 붉은색부분을 자신의 지메일 계정 정보로 적습니다.

[smtp.gmail.com]:587    USERNAME@gmail.com:PASSWORD

postfix 에서 사용할 수 있는 db파일로 변환

다음의 명령으로 계정정보 파일을 루트만 접근하도록 변경하고 postfix에서 사용하는 파일형태로 변환해 줍니다.

sudo chmod 400 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

CAfile 생성

환경설정에서 정의해준 CA파일을 다음과 같이 생성해 줍니다.

cat /etc/ssl/certs/thawte_Premium_Server_CA.pem | sudo tee -a /etc/postfix/cacert.pem


postfix 서비스 재시작


sudo /etc/init.d/postfix reload


테스트

만일 mailutils 가 설치되지 않은 경우에는 이 명령어가 동작하지 않습니다. 설치가 되지 않은 경우에는 다음과 같이 설치해줍니다.

sudo apt install mailutils


메일발송을 다음과 같이 테스트 해 봅니다. 붉은색 부분을 자신이 확인할 수 있는 이메일계정으로 변경해주세요.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소


디버깅

문제가 발생하여 로그를 확인하고 싶은 경우는 

tail -f 10  /var/log/mail.log 명령어로 postfix의 작업과정 확인합니다.



지메일 환경설정

2단계 보안인증

게정 로그인 정보가 정상임에도 불구하고 다음과 같은 오류가 로그파일에 남는 경우에는 지메일에서 추가적인 환경설정이 필요합니다.

postfix/smtp[21326]: CF7CE24225C: SASL authentication failed; server smtp.gmail.com[108.177.125.109] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mail/?p=BadCredentials k24sm23509527pfj.32 - gsmtp


이 이유는 지메일의 보안설정때문에 발생합니다.

먼저 아래 링크에서 2단계 인증을 사용하도록 변경합니다. 이때 보안코드를 받을 수 있는 휴대폰이 있어야 합니다.

https://myaccount.google.com/u/2/security



앱 비밀번호 생성

인증을 마쳤으면 다음과 같이 앱 비밀번호를 생성해줍니다. 새로운 앱을 원하는 이름으로 만들고 이때 발급되는 비밀번호를 복사해둡니다.


다음과 같이 이전에 설정한 파일의 비밀번호 대신 복사한 비밀번호를를 사용하도록 변경합니다.

sudo vi /etc/postfix/sasl_passwd 


[smtp.gmail.com]:587    USERNAME@gmail.com:발급받은앱비밀번호

저장해주고 다시 변경된 내용을 postfix에서 사용하는 파일형태로 변환해 줍니다. 저장이 안되는경우는 파일의 쓰기 권한 때문입니다. vi 에서는 저장할때 :wq! 하시면 강제 저장이 됩니다.

sudo postmap /etc/postfix/sasl_passwd

테스트 및 확인

다음과 같이 테스트 해봅니다.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소




오랜만에 포스팅입니다.

얼마전 소프트웨어 기업을 대상으로 강의요청이 있어서 교육을 진행했습니다. 5시간 정도 교육을 마치고 교육 수강하신 분들을 대상으로 회고를 해보니 의미있었던 내용이었다는 이야기를 듣고 한번 정리해야 겠다는 마음이 들었습니다.

오늘 주제는 Waterfall, Agile, Scrum, Kanban 이라는 용어에 대해서 알아보고, 어떤 경우에 어떤 방법을 사용하는 것이 좋은지 이야기 하려고 합니다. 상세한 내용은 별도로 공유하는 자료를 참고하시기 바랍니다.

저는 소프트웨어 개발방법론 맹신자는 아니지만 개발방법론의 효용가치에 대해 인정하는 편입니다. 중요한 것은 방법론이 아니라 적절한 방법론을 적절한 곳에 사용하지 않는 사람이 문제 아닐까요. 

학교에서 배우는 소프트웨어 공학에 요즘 스크럼, 칸반이 들어있는지 모르겠지만 최근의 소프트웨어 개발방법론은 애자일 방식을 채택하는 경우가 많습니다. 

주변에서 요즘은 애자일 개발방법론을 사용하고 있다는 회사들을 종종 접하게 됩니다. 아래의 애자일 개발방식을 사용하고 있다는 사람들에게 물어본 조사결과를 보면 58%는 Scrum을 사용하고 10%는 Scrum과 XP의 하이브리드 형태를 사용하고 있습니다. 그리고 8%는 multiple methodologies를 사용하고 있죠. 7%는 Scrumban 5%는 Kanban을 사용하고 있습니다.



이 이야기는 애자일 개발방식을 사용하는 사람들이 저마다의 환경에서 적합한 방법을 채택하고 있다는 의미입니다. 하지만 아직 국내에서는 실제 현업에서 다양한 적용사례를 만나기 어려운 현실입니다. 현업에서 이야기를 하다보면 애자일과 스크럼을 동일시 하는 경우도 자주 보게 되는데 스크럼은 애자일의 서브셋 입니다.


애자일이란?

소프트웨어 개발의 기초 원칙과 정신을 선언한 철학입니다. 소프트웨어를 개발하는 더 나은 방법들에 대한 이야기를 담은 문서가 2001년 Agile Alliance 라는 그룹에서 만들어지는데 12가지의 원칙을 담고 있습니다.


애자일 철학을 반영하는 개발방법론들

Scrum?

Scrum은 Agile을 구현하는 가장 보편적 인 방법 중 하나입니다. 스크럼은 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델입니다. 


Kanban?

일본에서 '시각적 기호'또는 '카드'를 의미하는 Kanban은 Agile을 구현하는 시각적 프레임 워크입니다. 현재 시스템에 대한 작고 지속적인 변경을 촉진합니다. 그 원칙은 다음과 같습니다 : 워크 플로우를 시각화하고, 진행중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상시킵니다. 


XP(Extreme Programming)?

익스트림 프로그래밍 (Extreme Programming)은 진화하는 고객 요구 사항에 대한 품질과 응답성을 개선하기 위한 소프트웨어 개발 유형입니다. XP의 원칙은 피드백을 포함하고, 단순성을 가정하고, 변화를 수용합니다.


기타 Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear 등의 방법론도 애자일 개발 방법으로 사용됩니다.


그럼 모든 소프트웨어 프로젝트에 지금까지 우리가 잘 알고 있는 Waterfall을 버리고 애자일 철학을 반영한 방법론을 사용하는 것이 필요할까요? 언제 이런 애자일 개발 방법을 선택하면 좋을까요?


Waterfall 이 필요한 경우

- 범위의 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우 

- 프로젝트는 매우 간단하거나 여러 번 해본 적이 있는 경우

- 요구 사항은 잘 알려져 있고 고정되어 있을 때

- 고객이 원하는 것을 정확하게 미리 알고 있는 경우

- 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우


Scrume 이 필요한 경우

- 프로젝트 요구사항이 바뀌고 진화하는 경우

- 지속적인 피드백이 필요한 경우

- 프로젝트 팀이 자율성을 원하는 경우

- 정기적으로 소프트웨어를 제공해야 하는 경우


Kanban 이 필요한 경우

- 반복을 요구하지 않는 프로젝트

- 언제든지 배포 할 수 있는 것을 원하는 경우

- 팀이 변화를 선호할 때

- 팀의 배포 흐름을 개선하고 싶을 때

- 이해하기 쉬운 시스템을 찾고 있을 때


No silver bullet.

모든 프로젝트를 해결할 수 있는 유일한 소프트웨어 개발방법론은 없습니다. Waterfall, Scrum, Kanban, XP 등 다양한 소프트웨어 개발방법을 알고 우리팀에 좋은 방법을 찾아보고 서로 피드백하며 실행해가는 과정을 통해 조금씩 나아지는 것이 좋은 소프트웨어를 만들기 위해 필요한 것이며 저는 이것을 애자일이라고 부릅니다.


20180318_언제 애자일을 써야 좋을까.pdf




Microsoft Office 365 서비스를 사용하기 위해서 DNS 설정을 변경하는 일이 있었습니다.

DNS 필드 중 SRV 레코드에 대해서 값을 추가해달라는 요청이 있었는데 SRV 레코드가 어디에 사용되는지 모르겠더군요.

제가 찾아본 내용을 정리합니다.


영문에 익숙하다면 http://en.wikipedia.org/wiki/SRV_record 를 참고하시기 바랍니다.


SRV 레코드는 SRV(서비스 로케이터) 리소스 레코드입니다. 유사한 TCP/IP 기반 서비스를 제공하는 여러 서버를 단일 DNS 쿼리 동작을 사용하여 찾을 수 있게 합니다. 이 레코드를 사용하여 잘 알려진 서버 포트 및 전송 프로토콜 종류에 대한 서버 목록을 DNS 도메인 이름의 우선 순위로 정렬하여 관리할 수 있습니다. 


zone 파일의 설정구문) service.protocol.name ttl class SRV preference weight port target


설정 예) ldap._tcp.contoso.msft 600 in srv 0 100 389 london.contoso.msft

             s      p           n           t      c    p  w   p                 t


설명)

service  :  서비스를 위한 이름 정의 

protocol :  프로토콜 정의

name    :  레코드에 의해서 참조되는 도메인 이름 정의

ttl          :  표준 DNS 레코드의 time to live의 정의

class    :  표준 DNS의 레코드 클레스의 값 정의

priority   :  호스트 우선 순위 정의

weight   :  로드밸런싱 메카니즘을 위한 정의

port       :  호스트에서 서비스 하기 위한 포트정의

target    :   서비스를 제공하는 호스트의 FQDN 정의



SRV 리소스 레코드의 상세한 설명은 아래를 참고하세요.


service 

원하는 서비스의 심볼 이름입니다. 잘 알려진 서비스의 경우 RFC 1700에 "_telnet" 또는 "_smtp"와 같은 예약된 유니버설 심볼 이름이 정의되어 있습니다. 잘 알려진 서비스 이름이 RFC 1700에 정의되어 있지 않으면 대신 로컬 또는 사용자 기본 설정 이름을 사용할 수 있습니다. 널리 사용되는 일부 TCP/IP 서비스, 특히 POP(Post Office Protocol)에는 단일 유니버설 심볼 이름이 없습니다. RFC 1700에서 이 필드에 표시된 서비스의 이름을 할당하면 RFC 정의 이름만을 사용할 수 있습니다. 로컬로 정의된 서비스만 로컬로 이름을 지정할 수 있습니다. 


protocol 

전송 프로토콜 종류를 나타냅니다. RFC 1700에서 이름을 지정한 모든 전송 프로토콜을 사용할 수 있지만 주로 TCP나 UDP가 됩니다.


name 

이 리소스 레코드에서 참조하는 DNS 도메인 이름입니다. SRV 리소스 레코드는 검색이나 쿼리를 수행하는 데 사용되지 않는다는 점에서 다른 DNS 레코드 종류와 다릅니다.


priority 

target 필드에 지정된 호스트의 우선 순위를 지정합니다. SRV 리소스 레코드를 쿼리하는 DNS 클라이언트는 여기에 나열된 가장 낮은 번호로 우선 순위가 지정된 호스트 중 연결 가능한 첫째 호스트에 접속을 시도합니다. target 호스트의 우선 순위 값이 같은 수준인 경우에도 임의 순서로 접속을 시도할 수 있습니다. 우선 순위 값 범위는 0에서 65535입니다.


weight 

target 필드에 여러 서버가 지정되어 있고 모두 같은 우선 순위 수준으로 지정되어 있는 경우 로드 균형 조정 메커니즘을 제공하기 위해 기본 설정 이외에도 이 필드가 사용됩니다. 동일한 우선 순위 수준 중에서 대상 서버 호스트를 선택하는 경우 이 값을 사용하여 응답을 받은 SRV 쿼리에 사용되는 대상 호스트의 정확한 순서와 선택 균형 조정을 결정하는 데 사용할 수 있는 추가된 우선 순위 수준을 설정할 수 있습니다. 0이 아닌 값이 사용되면 이 값의 크기에 비례하여 이 값과 우선 순위가 같은 서버가 시도됩니다. 값 범위는 1에서 65535입니다. 로드 균형 조정이 필요하지 않으면 이 필드에 0을 사용하여 레코드를 읽기 쉽게 합니다.


port 

service 필드에 표시된 서비스를 제공하는 target 호스트의 서버 포트입니다. 서버 포트 번호에는 흔히 잘 알려진 할당된 서비스 포트 번호가 사용되지만 포트 번호의 범위는 RFC 1700에서 지정한 대로 0에서 65535입니다. 필요에 따라 할당되지 않은 포트를 사용할 수 있습니다.


target 

요청된 서비스 종류를 제공하는 호스트의 DNS 도메인 이름을 지정합니다. 사용된 호스트 이름 각각에 해당하는 호스트 주소(A) 리소스 레코드가 DNS 네임스페이스에 있어야 합니다. 이 필드에 마침표(.) 하나를 사용하여 이 DNS 도메인 이름에서 이 SRV 리소스 레코드에서 지정한 요청된 서비스가 가능하지 않음을 명백하게 나타낼 수 있습니다.

  1. 탱이 2015.12.04 18:18 신고

    좋은 글 감사합니다. :) 글 퍼가요.




사용자 인터페이스 설계를 위해서 어떤 방법을 사용하나요? 저는 그때그때 상황에 따라서 보고 바로 작업에 들어갈 수 있는 문서를 원하는지 아니면 빠른 의사소통을 위해서 프로토타입이 필요한 것인지에 따라 다양한 도구(PowerPoint, Balsamiq Mockup, Axure RP, 네이버 Design Studio 2 등)를 사용해서 작업합니다. 화면설계를 지원하는 다양한 도구가 있지만 문서공유 및 수정을 위하여 모든 팀원이 학습없이 쉽게 사용 가능한 파워포인트가 가장 많이 사용되는 것이 현실인데 이때 소개하는 PowerMockup을 사용하면 빠른 작업이 가능합니다.




설치


PowerMockup은 독립적인 소프트웨어가 아니라 PowerPoint 와 함께 Add-on 형태로 동작합니다. 따라서 PowerPoint가 없으면 사용이 불가능하죠.


http://www.powermockup.com/



Download Free Trial 를 클릭하면 설치 파일을 다운 받을 수 있고 다운받은 파일을 실행하고 파워포인트를 실행하면 파워포인트 메뉴 상단에 "PowerMockup" 나타나며 왼쪽에 Library가 노출 됩니다.





기능


기본적인 사용법은 아래 화면과 같이 우측에 자리하고 있는 스텐실 라이브러리에서 원하는 모양을 드래그해서 사용합니다.




PowerMockup은 파워포인트의 Add-on 형태로 설치되는데, 설치된 이 후에 파워포인트 화면 우측에 스텐실 박스가 나타납니다. 좌측에 보이는 것과 같은 스텐실 박스에서 원하는 웹 컨트롤들을 끌어와 놓는 형태로 작업이 진행되기 때문에 스토리보드 레이아웃을 만들어 놓은 상태라면 간단하게 페이지 작성이 가능하고, 개인이 만든 커스텀 스텐실의 추가도 가능하기 때문에 라이브러리에 포함되지 않은 스텐실은 직접 만들어 작업할 수도 있습니다.






Trial 버전에서는 제공되는 스텐실이 몇가지 되지 않지만 정품으로 구매하면 다음과 같이 자유로운 화면설계가 가능합니다. 아래 화면은 PowerMockup 홈페이지의 스크린샷입니다.





구매


http://www.powermockup.com/order



오픈소스 개발자나 블로거인 경우에는 메일을 보내면 무료로 라이센스를 받을 수 있다고 하니 아래 링크를 참고하세요.

http://www.powermockup.com/order/free-license







업무의 대부분이 이메일로 소통되고 있는데, 이슈를 따로 레드마인에 가서 등록하는 비효율적인 영역의 업무를 줄이기 위해서는 이메일을 통한 이슈등록이 필요합니다. 이번에는 레드마인의 이슈를 이메일로 등록하는 방법을 진행해볼까 합니다.


운영 환경

OS : CentOS 6.x

Version : Redmine 2.2.0


이 글은 레드마인이 설치된 상태에서 시작하기 때문에, 레드마인이 설치되지 않은 경우는 이전글을 참고해서 설치하시기 바랍니다. http://yes.imhappyo.com/403



레드마인 2.x 버전에서는 설정에 필요한 기본적인 내용이 모두 포함되어 있으므로 실제 우리가 설정해야 하는 것은 자동으로 pop3 또는 imap 이메일 서버에 접근해서 이슈를 가져오게 만드는 과정뿐입니다.


저는 redmine@abydos.co.kr 이라는 이메일 계정으로 보내는 내용을 자동으로 레드마인에 등록하는 시나리오를 구상하고 다음과 같이 설정했습니다.


1) 이메일로 받는 것이 가능하도록 레드마인 관리자로 로그인하여 설정을 변경.

관리-> 설정-> 수신메일-> 수신메일에 WS를 허용 하고 키생성을 눌러서 API키를 생성해 둡니다.





2) cron을 이용하여 주기적으로 이슈를 가져오도록 설정.

5분마다 레드마인이 redmine@abydos.co.kr 계정의 imap 서버를 접근하여 이슈를 가져오는 cron 설정은 다음과 같습니다. (pop3를 사용하신다면 아래의 예를 참고하세요)


Gmail imap 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_imap RAILS_ENV="production" host=imap.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=993 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority


Gmail pop 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_pop3 RAILS_ENV="production" host=pop.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=465 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority


설정이 끝났습니다. 이제 여러분이 redmine@abydos.co.kr 에게 쓰는 메일은 기본적으로 issue_repo 라는 프로젝트로 Issue 라는 tracker로 자동으로 등록됩니다. 너무 간단하죠 :-)

뒤의 옵션 중 allow_override 는 메일의 본문에서 적는 내용을 우선해서 등록하라는 의미입니다.


2) 이메일을 보내서 등록된 이슈 확인


지금부터 이메일 본문에 아래의 내용이 있으면 이슈가 등록됩니다.

Project: 프로젝트아이디
Tracker: Issue(결함, 새기능, 지원, Issue)
Priority: 보통(낮음, 보통, 높음, 긴급, 즉시)
Status: 신규(신규, 진행, 해결, 의견, 완료, 거절)
Category: 설정한 카테고리
Assigned To: 홍길동(또는 id)



문제가 생겨서 진행과정을 디버깅하는 경우에는 맨뒤에 --trace 를 붙여서 실행하시면 됩니다.



참고) 레드마인 공식사이트에서 제공하는 관련 링크
http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails




  1. hadragon 2014.02.27 16:05 신고

    안녕하세요 잘 봤습니다^^
    저는 우분투 레드마인을 사용하고 있는데 CentOS 말고 우분투에서 설정하려면 어떻게 해야할까요?ㅠ
    또한 이슈를 등록하고 싶은 프로젝트가 바뀔 경우에는 crontab -e를 통해 'project='를 수정해야하나요?

  2. Favicon of http://openbee.kr BlogIcon 오픈비 chaeya 2014.03.04 10:34 신고

    어떤 설정인지 몰라서 정확하게 답변은 어렵지만 레드마인이 OS에 종속적인 것은 아니니 설정은 동일할 것 같습니다. 그리고 프로젝트가 다른 이름을 가지고 있다면 문의하신 것처럼 crontab 의 project를 수정하시면 됩니다.



이번 글은 설치된 레드마인을 Eclipse와 연동하는 방법에 대해서 작성하려고 합니다.
기본적으로 레드마인 공식사이트에서 제공하는 아래의 링크에서 읽으면 되지만, 오픈소스 프로젝트들은 환경이 각각 다르기 때문에 한번에 쉽게 되는 법이 없죠 :-)
http://www.redmine.org/projects/redmine/wiki/HowTo_Mylyn


설치 환경

OS : CentOS 6.x

Version : Redmine 2.2.0

Eclipse : STS


이 글은 레드마인이 설치된 상태에서 시작하기 때문에

레드마인이 설치되지 않은 경우는 이전글을 참고하세요 - http://yes.imhappyo.com/403

저는 CentOS 6.x 를 사용중이고 Redmine 2.2.0 버전을 설치한 상태입니다.
레드마인 사이트의 공식 가이드나, 구글링에서 나오는 Eclipse 연동을 위한 예전의 글은
낮은 버전의 레드마인을 위한 설명이 대부분이라 적당한 문서를 찾지 못해서 기록해둡니다.

설치는 크게 2단계로 나누어집니다.
1단계 - 서버에 설치된 레드마인에 mylyn 플러그인을 추가하는 단계입니다.
2단계 - 이클립스가 설치된 개발용 PC에서 이클립스 플러그인을 깔고 설정하는 단계입니다.

1단계) Redmine 서버에 Mylyn Plugin 설치

Redmine 2.2.0 설치된 서버에 redmine_mylyn_connector plugin을 설치합니다
http://danmunn.github.com/redmine_mylyn_connector/


redmine_mylyn_connector를 설치하는 과정에서 libxml-ruby 의존성 문제 발생하네요
- 의존성문제는 다음과 같이 해결 (http://michael.f1337.us/2009/08/26/172339834/)

yum install gcc make libxml2-devel
Install the libxml-ruby gem:
gem install libxml-ruby --no-rdoc --no-ri


의존성을 해결했으니 이제 플러그인을 설치합니다.

 - 저는 postgresql sqlite을 사용하지 않기에 --without 옵션에 추가되었습니다

cd [redmine-install-dir]/plugins
git clone git://github.com/danmunn/redmine_mylyn_connector.git
cd ..
rake db:migrate_plugins RAILS_ENV=production
bundle install --without development test postgresql sqlite


설치를 완료했으면, 설치한 레드마인의 관리자> 환경설정> 플러그인 에서 아래의 화면이 있는지 확인합니다.



2단계) PC에 eclipse plugin 설치

Eclipse PC에 Mylyn Connector for Redmine 설치(저는 STS로 설치확인)
Window > Install New software > Update Site 에 아래주소를 추가합니다.

http://redmin-mylyncon.sourceforge.net/update-site/N/


주소를 추가하면 아래와 같은 화면이 나옵니다. 체크박스를 모두 체크한 후 설치를 진행합니다.




이클립스 플러그인설치를 마쳤이니 이제 이슈를 가져오는 설정을 합니다.


New > Task 를 생성합니다.







화면처럼 설정이 다 되었으면 Validate Settings 를 눌러서 접속을 확인해 봅니다.

정상적으로 접속이 되었다면 이제 이슈를 가져오는 Query 생성 과정을 진행합니다.

Task List 윈도우에서 마우스 오른쪽 버튼을 누르고 새 쿼리를 생성합니다.










기타 유용한 도구
Third Party Tools - http://www.redmine.org/projects/redmine/wiki/ThirdPartyTools
윈도우용 Tortoise SVN 클라이언트에 플러그인으로 동작하는 프로그램인데, 컨텍스트 메뉴로 Redmine에 입력하는 설정을 할 수 있게 해줍니다.

* turtlemine(Tortoise Redmine Plugin) - http://code.google.com/p/turtlemine/wiki/BugTraqConfiguration





오늘 자료 검색하다가 발견한 내용인데 악성코드 관련된 사건들을 한번 살펴보게 되었습니다. 최근에 한국인터넷진흥원에서 발간한 자료를 발견했는데 정리가 잘 되어 있네요.

지나간 사건들을 살펴보니 서버관리를 주로 하던 시절에 nimda 차단 룰셋을 아파치에 적용하느라 끙끙대던 생각이 나기도 하고, MSSQL 설치 후 업데이트 패키지를 추가로 꼭 설치해야 하던 시절도 생각이 나네요. 

최근의 관련된 보고서를 보니 여전히 트로이목마가 많다고 되어있습니다. 이것 저것 챙길 것도 많지만 회사와 개인을 위해서하도 PC보안은 반드시 관리해야 하겠습니다.


악성코드 관련 사건의 역사

•1986년 최초의 MS-DOS 바이러스 ‘브레인(Brain)' 출현
•1987년 세계 각지에서 바이러스가 발견되기 시작
•1988년 Brain 바이러스의 전 세계 전파, 모리스(Morris) 웜 출현
•1990년 다형성 기법의 바이러스 등장
•1991년 연결형 바이러스 Dir-II 발견
•1992년 미켈란젤로(Michelangelo) 바이러스 발견
•1995년 매크로 바이러스 출현
•1996년 최초의 엑셀 매크로 바이러스 ‘라루 바이러스(Laroux virus)’ 발견
•1998년 백 오리피스(Back Orifice) 등장
•1999년 전자우편으로 전파되는 웜 등장
•2000년 비주얼 베이직 스크립트를 이용한 바이러스 전파
•2001년 코드레드(Codered) 웜의 전파
•2003년 슬래머(SQL Slammer) 웜에 의한 1.25 인터넷 대란
•2004년 악성 IRC봇 변형의 대량 양산
•2005년 소니 BMG의 DRM 관련 루트킷 이용한 브레프리봇 (Win-Trojan/Breplibot) 트로이목마 발견
•2008년 MBR에 감염되는 새로운 형태의 악성코드인 트로이목마 Win-Trojan/Mbrookit이 발견
•2010년 스턱스넷(Stuxnet)이 알려짐





비트앱센터에서 어제 저녁 “Scrum 네~ 이놈!” 이라는 제목으로 세미나가 있었다. 
아마도 제목을 보고 많이들 신청하지 않았을까?

서둘러 간다고 했지만 저녁시간이라 배고픔을 참지 못하고 버거킹에 들러서 약간 늦었다.
(참석하는 예의상 그러면 안되지만 참을 수 없는 허기 ㅋㅋ) 

강사분은 현업에서 오랫동안 해오신듯 했지만 어떤분인지는 잘 모르고  그냥 강사 약력을 보고 참석했다.
외국에서 스크럼과 관련한 몇가지의 인증을 획득한것을 보니 뭔가 다른 이야기가 있지않을까 하는 생각에서 참석했다.



주요한 내용)
1. 현업에서 경험한 많은 고민거리들에 대한 자신의 생각
2. 스크럼에 대한 설명
3. 스크럼을 적용하는 데 가장 중요한 것은 무엇인가

많은 좋은 이야기를 들었지만  스크럼만으로 모든것을 해결하려는 태도보다는 기존의 전통적인 방법론에 대한 이해와 사람과 프로젝트에 대한 이해가 필요하다는 이 그림이 강의의 핵심인것 같다. 



돌아오는 길에 나는 몇가지의 생각을 했다.

1) 예상보다 더 많은 자료를 보니 많은 준비를 하셨구나. 짝짝~
2) 주의 집중을 위해서 마술도 하는 준비성 깜놀. 짝짝~
3) 마지막에 보여준 '박이사와 박봄'은 대중의 기호를 무시한 듯 ㅋㅋ
 
처음에는 스크럼에 집중했지만 점차 시간이 지날수록 사람에 집중하게 되는 이야기를 하는데
나도 겪고 있는 이야기를 들어서인지 고개가 끄덕여지더라.

우리 주변에서 자꾸 이런 강의가 많아지는 것은 즐거운 일이다.  
세상이 점점 좋아지고 있다. 
어제는 Agile Korea 컨퍼런스가 열렸습니다.

늦잠을 잔 덕분에 서둘러서 출발했지만 상암동은 내게 너무 먼 거리. 도착해서 들어가니 Ice Breaking 이 진행중이었습니다. 얼른 테이블의 종이를 챙기고 진행했습니다. 같이 참석한 분은 참석자들이 낄낄거리며 인사하는 모습을 보고 일번적 컨퍼런스와 다른 그 분위기에 좀 놀라는 모습이었습니다.



애자일의 첨병으로 활동하는 김창준님의 키노트는 많은 생각을 하게 했습니다.
애자일의 약점이라는 주제로 실제 프로젝트에서 저도 느끼고 있던 느낌들을 이야기하더군요.

1) 애자일은 사회적 측면이 중요하지만 신뢰를 구축하기 위해서 좋은 방법이 없다. 따라서 긍정심리학, 코칭등의 추가적인 준비가 필요하다. 애자일기법만으로는 부족하다.

2) 외부 팀과의 폐쇄적인 운영으로 인하여 팀 스스로 잘되고 있는것처럼 생각하기 쉽다. 번다운차트를 떨어뜨리는 것을 목표로 스프린트를 완성하는 단기피드백에 너무 치중하기보다는 외부와의 교류를 통해 팀의 단점을 들여다보고 개선해가야 한다. 애자일은 장기전이다.

3) 애자일은 사람에대한 도메인을 다루고 있다. 사람에 대한 도메인은 복합적 요소를 가진 영역이므로 베스트프랙티스를 맹목적으로 따르는것은  도움이 안되며, 유연성이 중요하다. 행복한 가정일수록 패턴이 다양하다는 연구도 있음.


외부에서 구경하기 힘든 여러가지 애자일사례를 만날 수 있었고, 특정 주관사가 아니라 많은 자원봉사자의 자발적인 참여로 만들어진 행사라서 더욱 뜻깊었네요 열심히 준비해주신 분들에게 감사를 드립니다.

<득템한 멋진 플래닝포커>
어제 지인과 식사도중 개발자의 실력에 대한 안철수씨의 강연내용 이야기가 나왔습니다. (이런 주제를 이야기 할 수 있는 지인이 있다는건 참 행복한 일이죠)

“현대는 한 사람의 천재가 모든 것을 할수 있는게 아니라 한 사람이 못할 일을 여러 전문가가 함께 모여 만들어가는 시대다”며 “전문가의 실력은 전문 지식 곱하기 커뮤니케이션 능력이다”

Source : “고단한 SW개발자 생태계, 그래도 희망은 있다” - http://goo.gl/i12Z7

전문지식 곱하기 커뮤니케이션 능력이 실력이라니~
개발자는 제대로된 기능을 만들기도 벅찬데, 커뮤니케이션 능력도 배양해야 한다니 쉬운일이 아닙니다.
게다가 현업에서 보면 A개발자와 B영업간에 "뭔 말이 통해야 말을하지~" 하는 푸념을 종종 듣습니다.
하지만, 대부분의 개발자는 자신이 커뮤니케이션 능력이 부족하다고 생각하지 않습니다. 상대방이 논리가 빈약하고 실체가 없는 모호한 대화방식이 아니라, 좀 다른 대화방식으로 이야기하기를 바라는것 뿐이죠 :-)

그럼 개발자와 대화를 이끌어내기 위해서는 어떻게 해야할까요?

얼마전 트위터에서 웃음을 자아냈던 공대생 남친 관리법(http://goo.gl/qvBUC)에서도 보이듯이, 개발자는 개발자스러운 대화방식으로 접근해야 커뮤니케이션이 가능합니다. 개발자는 자신이 이해가능한 합리적인 결과물에 대해서는 큰 이견을 제시하지 않는다는 특성을 가지고 있죠. 꼭 개발자가 아니라도 합리적 내용물을 기반으로 이야기하면 쉬운 대화가 가능합니다.

제 생각에 개발자와 대화하기 가장 좋은 방법은 애자일 실천법 중 하나인 CTIP(Continuous Test & Intergration Platform) 라고 생각됩니다. 지난 몇년간 Agile 기법에 대한 학습과 현업에서 적용결과, 저는 애자일의 핵심이 사람과의 소통인것을 얼마전에야 깨닫게 되었습니다.

혼자 개발하는 문화에 익숙한 개발자는 무엇인가 함께 만들어야만 하는 상황을 만나면, 구성원간 커뮤니케이션에 어려움을 겪습니다. 이때 CTIP를 통한 정적분석도구를 활용한 결과물과 코드커버리지, 그리고 이슈관리도구를 통하여 문제점을 가시화하고 합리적 결과에 기반한 개발자와의 대화를 시도하면 SW개발자와의 쉬운 대화가 가능합니다.

저는 SW개발의 생산성을 향상시키기 위한 최선의 방법은, 좋은 개발문화를 형성하여 개발자간 커뮤니케이션능력을 배양하고, 협업을 통한 시너지가 창출될 수 있도록 유도해주는 것이라고 생각합니다.


Source : 2011 한국소프트웨어 아키텍트 대회
<지속적 테스트와 통합을 위한 SW개발 아키텍처>


<이슈관리시스템을 통한 문제제기>


<위키를 이용한 문서협업>




<SW개발을 위한 공개SW 기반의 지속적 테스트와 통합 아키텍처>


그리고, Agile 2011 Conference가 8월6일 열린다고 합니다. http://pragmaticstory.com/1776 에 트랙에 대한 설명을 해주셨네요. 언젠가는  가 볼 기회가 있겠죠?  :-)

+ Recent posts