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 리소스 레코드에서 지정한 요청된 서비스가 가능하지 않음을 명백하게 나타낼 수 있습니다.

블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

Tag dns, Srv, 도메인




사용자 인터페이스 설계를 위해서 어떤 방법을 사용하나요? 저는 그때그때 상황에 따라서 보고 바로 작업에 들어갈 수 있는 문서를 원하는지 아니면 빠른 의사소통을 위해서 프로토타입이 필요한 것인지에 따라 다양한 도구(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




블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.




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


운영 환경

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




블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.



이번 글은 설치된 레드마인을 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





블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

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

지나간 사건들을 살펴보니 서버관리를 주로 하던 시절에 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)이 알려짐




블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.


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

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

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



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

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



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

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

우리 주변에서 자꾸 이런 강의가 많아지는 것은 즐거운 일이다.  
세상이 점점 좋아지고 있다. 
블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

어제는 Agile Korea 컨퍼런스가 열렸습니다.

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



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

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

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

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


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

<득템한 멋진 플래닝포커>
블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

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

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

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 에 트랙에 대한 설명을 해주셨네요. 언젠가는  가 볼 기회가 있겠죠?  :-)

블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

조직에 속한 사람이라면 누구나 좋은 생산성을 위한 보다 좋은환경을 구성하는 것의 필요성에 이견이 없을겁니다.
같은 조건에서 보다 좋은 생산성이 기대된다면 하지 않을 이유가 없겠죠.
저도 마찬가지로 생산성을 향상시키는 좋은 방법에 대해서, 여러가지 고민을 하고 있습니다. (좋은 품질을 원할때 팀원에게 해주어야 하는 노력들이라는 예전 글을 읽어보세요)



이번 주에는 무더운 여름(올해는 40도가 넘는 날이 예상된다네요) 사무실에서 도움이 될 만한 것들을 생각해서 꾸며보았습니다.

사무실 여름나기를 위해서 준비한 것들

  • USB선풍기
  • 에어컨 활용을 위한 대형선풍기
  • 여름슬리퍼
  • 대나무방석
  • 대나무돗자리
  • 자연을 책상위로-화분
  • 땀냄새제거 제품
  • 시원한 색감으로 인테리어 변경
  • 책상정리용 박스로 정리정돈


책상위에 녹색식물을 하나씩 골라서 놓았습니다. 부지런하지 못한 저는 물을 적게 주어도 잘 자라는 종류를 골랐습니다. :-)


에어컨이 골고루 갈 수 있도록 대형 선풍기를 에어컨 아래에 배치 했습니다. 바람세기가 장난아니네요~



입구에 화분을 추가로 몇개 더 배치했는데, 얼마나 공기정화에 도움이 될지는 미지수네요 ㅎㅎ


희끄무리한 벽면에는 워크샵 다녀와서 찍은 사진들을 이용해서 꾸미고



창문에도 약간의 꾸밈을 주었습니다.


겨우 매트위에 양말을 벗은 채로 코딩할 수 있는 환경이 얼마나 생산성에 도움이 되겠냐 싶을수도 있지만, 저는 조금씩 개선해 나가려는 노력이 더욱 중요한 것이라고 생각합니다.

여러분도 생산성을 향상시킬 수 있는 여러가지 방법에 대해서 적용 가능한 것들을 하나씩 해보시는게 어떨까요?  Right Now !



블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.


실용주의 프로그래머.
몇년만에 다시 보게 되었는데, 다시 읽어보아도 참 주옥같은 문구가 가득한 책입니다.
어떤 언어를 사용하시던지, 반드시 읽어보시면 좋은 책이라고 생각됩니다.
아직 안보신 개발자분은 꼭 필독하시기를 강추!!!

실용주의_프로그래머

출판사에서 제공하는 목차
http://insightbook.springnote.com/pages/275777

실용주의 프로그래머의 70개 Tips
http://goo.gl/W1Or5
블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.