Daylogs/Etc

Charles 에서 HTTPS 패킷 확인하기

발생일: 2012.01.31

문제:
HTTP 패킷 확인 툴로 찰스(Charles)를 주로 사용하고 있다.
이번에 HTTPS 요청을 테스트할 게 있어서 모니터링을 시도했으나, 자꾸 Fail이 난다.

브라우저는 크롬을 사용하고 있다.

왜 그런 걸까.


해결책:
혹시나 해서 익스플로러에서 HTTPS 모니터링을 시도해보니, 신뢰할 수 있는 인증서냐고 물어본다.
신뢰할 수 있다고 체크하고 진행하니, IE에서는 정상적으로 보인다.

아무래도 크롬에서 인증서를 신뢰할 수 없어 튕겨내는 것 같다.


혹시나 해서, 찰스 가이드를 찾아보니 찰스가 SSL Proxying을 처리하는 방법에 대해 나와있다.

찰스는 브라우저와 SSL 웹 서버의 중간자(man-in-the-middle HTTPS Proxy)가 되는 방법으로 이를 처리한다.
브라우저는 서버의 인증서를 바라보는 대신에, 찰스가 동적으로 생성한 인증서(Charles CA Certificate)를 바라본다.
마찬가지로 응답 시에는 서버의 인증서를 찰스가 받고, 브라우저는 찰스의 인증서를 받는다.
이 방법으로 찰스는 암호화되지 않은 plain text를 볼 수 있다.
단, 브라우저가 찰스가 생성한 인증서를 신뢰해야 한다.

따라서, IE에서 그랬던 것처럼,
브라우저는 Charles CA Certificate가 신뢰할 수 있는 인증서이냐는 보안 경고를 띄운다.
신뢰할 수 있는 것이라 선택하면 진행할 수 있는 것이고, 아니라면 더 이상 모니터링 할 수 없다.

크롬은 IE와 다르게 신뢰할 수 없는 인증서면 암묵적으로 무시하나보다.
아니면 나도 모르게 언젠가 신뢰할 수 없다고 했다던가...

 
여튼, 요골 해결하려면 찰스가 동적으로 생성한 인증서를 신뢰할 수 있다고 크롬에게 알려줘야 한다.

  1. 크롬에서 옵션 > 고급설정 > HTTPS/SSL > 인증서 관리를 클릭한다.
  2. '신뢰할 수 있는 루트 인증기관' 탭을 선택하고, '가져오기' 버튼을 클릭한다.
  3. 찰스가 설치되어 있는 폴더에서 charles-proxy-ssl-proxying-certificate.crt 파일을 찾아 가져온다.
  4. 가져온 인증서를 신뢰할 수 있는 게 확실하냐고 묻는다.
     그렇다고 하면 크롬은 찰스가 생성한 인증서를 쭈-욱 신뢰한다.

 
이 부분을 설정해도 해결되지 않았다면, 찰스에서 SSL 프록시를 사용할 것이라 체크했는지 확인해본다.

  1. 찰스에서 Proxy > Proxy Settings > SSL 탭에서 'Enable SSL Proxing'을 선택한다.
  2. Locations에 모니터링 할 호스트를 추가한다. 모든 사이트를 모니터링하고 싶을 경우, '*' 을 추가하면 된다.


요호~~ 이제 HTTPS 패킷 확인이 가능해졌다~~~~
 

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG Charles, fiddler, https, 모니터링, 찰스, 철수, 촬스, 패킷
Trackback 0 Comment 0
Daylogs/Etc

Git Tag로 버전 관리하기

발생일: 2012.01.16

문제:
담당하고 있는 서비스에서는 버전 관리 도구로 SVN을 사용하고 있다.
배포는 서버 개발팀에서 담당하고 있는데, 매 배포에 대한 버전 관리는 어떻게 관리하는 지 궁금해서 물어봤더니 각 릴리스에 대한 버전을 브랜치로 따서 관리한다고 한다.
예를 들어, v.1.0을 배포하고자 할 경우, Release Branch의 약어를 써서 RB-1.0 과 같은 이름의 브랜치를 따고, 해당 브랜치를 배포하는 식이다.

요새 Git으로 관리하고 있는 개인 프로젝트에서도 브랜치로 배포 버전을 따면 되겠구나~하고 생각하고 있었는데, 이것저것 알아보다 보니 실제로 브랜치보다는 태그(Tag)를 더 많이 사용하는 모양이다.

태그는 뭐고, Git에선 어떻게 사용하는 걸까?

해결책:

버전 관리 시스템에서 Tag란?
Tag는 특정 스냅샷에 대한 꼬리표(말 그대로 태그)다.
대부분의 버전 관리 도구에서 태그를 지원한다.

사실 지금까지는 습관적으로 trunk만 땡겨와 작업하고 있었는데, 이번 기회에 소스 리파지터리를 자세히 봐봤다.
이제서야 branches 영역과 tags 영역이 구분되어 있고, 개발팀에서는 브랜치를 굉장히 활발하게 활용하고 있다는 걸 알게 됐다.

SVN의 경우, 실제로 브랜치와 태그의 동작에는 차이가 없다고 한다.
두 가지 모두 동일하게 코드를 특정 영역으로 복사하는 것이며, 단지 의미 상의 차이만 있는 것이라 한다.
아마 그래서 서비스에서도 그냥 브랜치로 배포 버전을 관리하는 게 아닐까~~ 추측해본다.


Git에서 Tag 사용하기
Git에서도 태그를 지원하고 있다.

git tag 명령으로 간단하게 이미 만들어져 사용할 수 있는 태그를 조회할 수 있다.
특정 패턴을 가진 태그를 조회하고자 할 때엔 -l 옵션을 사용하면 된다.
예를 들어, git tag -l 'v.1.3.*' 을 실행하면, v.1.3의 태그들만 조회된다.

Git의 태그에는 Ligthweight Tag와 Annotated Tag 두 종류가 있다.
Lightweight Tag는 단순히 특정 커밋을 가리키는 포인터 역할을 하는 반면,
Annotated Tag는 태그를 만든 사람에 대한 정보, 태그 메세지, 서명 등을 추가할 수 있다.

Lightweight Tag는 간단하게 git tag <tagname> 과 같이 만들 수 있다.
예를 들어, git tag v1.3 를 실행하면, 현재 커밋에 v1.3이라는 태그를 붙인다.

Annotated Tag는 태그를 달 때, -a 또는 -s 옵션을 사용하면 된다.
옵션의 자세한 내용은 git tag --help 로 확인~~

적용한 내용의 태그를 조회하고자 할 때엔 git show <tagname> 을 실행~!
이 명령으로 각 태그의 커밋 정보를 조회할 수 있다.


실제로 jquey의 github을 보니 태그를 사용해 릴리스 버전 관리를 하고 있는 걸 볼 수 있었다.
https://github.com/jquery/jquery/tags


Git의 Tag, 잘 사용해보자~~ 


# 참고:
- SVN의 Branching/Tagging: http://wiki.kldp.org/wiki.php/SubversionBook/BranchingAndMerging


저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG GIT, git tag, svn, svn tag, tag, 태그
Trackback 0 Comment 0
Daylogs/Etc

Git의 파일 상태

발생일: 2012.01.15

문제:
git에서 커밋할 때엔 항상 git add . 명령어로 커밋할 대상을 골라놓은 후,
git commit -m [message] 명령으로 커밋했다.

git add 가 정확히 어떤 것인지 모르고 습관적으로 실행했었는데,
이번에 책을 읽다가 알게된 내용을 메모해둔다.


해결책:

Git 프로젝트의 세 가지 단계
가장 먼저 Git 프로젝트의 세 가지 단계에 대해 이해해야 한다.

Git 프로젝트에는 Git Directory, Working Directory, Stating Area 세 가지 단계가 있다.
Git Directory는 Git이 프로젝트의 모든 정보를 저장하는 곳이다.
Git의 핵심이라 할 수 있고, Git을 새로 구축하거나 다른 저장소에서 Clone할 때 Git Directory가 만들어진다.

Working Directory는 프로젝트의 특정 버전을 Git Directory로부터 체크아웃 상태이다.
Staging Area는 곧 Commit 할 파일에 대한 정보를 저장한다. 단순한 파일이고 실제로 Git Directory 내에 존재한다.

Git으로 하는 일은 기본적으로 다음과 같다.
- Working Directory에서 파일을 수정한다.
- Staging Area에 파일을 Stage 해서 Commit 할 Snapshot을 만든다.
- Staging Area에 있는 파일들을 Commit 해서 Git Directory에 영구적인 Snapshot으로 저장한다.


Working Directory의 파일 상태
작업 디렉토리의 모든 파일은 크게 Tracked와 Untracked로 나뉜다.

Tracked는 Git의 관리 대상 파일임을 의미하고 반대로 Untracked는 관리 대상이 아닌 파일을 의미한다.

Tracked 파일들은 또 Unmodified(또는 Commited)와 Modified, Staged 상태로 나뉜다.
Unmodified는 수정되지 않은 파일을, Modified는 수정된 파일, Staged는 커밋 대상인 파일을 의미한다.

예를 들어, 새로운 파일을 만들고 Staging Area에 추가하지 않았다면 그 파일은 Untracked에 포함된 파일이다.
만약, Git의 관리 대상인 파일(Tracked)을 수정했지만 아직 Staging Area에 추가하지 않았다면, 그 파일은 Modified 이다.
파일을 수정하고 Staging Area에 추가했다면 그 파일은 Staged 가 되고,
Commit 했다면 Commited 또는 Unmodified 가 된다.


Staging Area에 추가하기
작업한 파일을 Git Directory로 커밋하려면 반드시 Stating Area에 추가해야 한다.
git add [file] 명령으로 작업한 파일을 Staging Area에 추가할 수 있다.

습관적으로 작성하고 있었던 git add . 는 변경된 모든 파일(정확하게는 Modified와 Untracked인 파일)을 Staged 로 변경하겠다는 의미였다.

git status 명령을 실행해보면,
각 파일을 상태별로 구분해 리스팅 해 줄 뿐만 아니라, 파일의 상태를 변경할 수 있는 팁도 전해준다.
지금까지는 무심코 지나쳤었는데, 이제 자세히 살펴보자.




저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG commit, GIT, git add, Github, modified, staged, stating area, tracked, unmodified, untracked
Trackback 0 Comment 0
Daylogs/Etc

Synergy key mapping between Windows & Mac

발생일: 2012.01.06

문제:
여러 대의 PC에서 마우스와 키보드를 공유하려고 시너지(synergy)를 사용하고 있다.

Windows를 호스트로, 맥을 클라이언트로 잡아놓고 사용하고 있는데,
Windows의 Ctrl, Alt, window 키가 기대했던 대로 맥에서 매핑되지 않는다.

윈도우의 Ctrl 키는 맥에서도 Ctrl 키를,
윈도우의 Alt 키는 맥의 Command 키에 매핑되도록 하고 싶다.

어떻게 수정해야 할까?


해결책:
디폴트로 사용하는 경우, 아래와 같이 매핑된다.

  Windows :: Mac
  Ctrl --> Ctrl
  WinKey --> Command
  Alt --> Alt/Option


 편하게 변경하기 위해선, 스크린을 추가할 때 키보드 매핑 정보를 아래와 같이 변경하면 된다.

  Windows :: Mac
  Ctrl :: Ctrl    // 윈도우의 Ctrl 키는 맥의 Ctrl 키
  Alt :: Meta    // 윈도우의 Alt 키는 맥의 Command 키
  Super :: Alt    // 윈도우의 window 키는 맥의 Alt 키



편하다! ㅎㅎ


# 참고:
  http://superuser.com/questions/90223/synergy-key-mapping 



저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG key, Mac, Synergy, window, 시너지
Trackback 0 Comment 0
Daylogs/Etc

좋은 URI의 설계

발생일: 2011.12.16

문제:
좋은 URI란 무엇일까?

지난 시간들을 되돌아보면, 아무 생각 없이 습관적으로 URI를 지정한 적이 많았던 것 같다.
최근 '웹을 지탱하는 기술'이라는 책을 읽다가 URI 설계에 대한 좋은 내용이 있어 메모해둔다.


해결책:
좋은 URI란 무엇인가?
웹의 발명자 팀 버너스 리는 1998년 'Cool URIs don't change'라는 웹 페이지를 발표했다.

http://www.w3.org/Provider/Style/URI.html

그렇다면, 좀처럼 변하지 않는 Cool URI를 만들기 위해서는 어떻게 해야할까?

1. 프로그래밍 언어에 의존적인 확장자를 이용하지 않는다.
2. 구현에 의존적인 경로명을 이용하지 않는다.
3. 프로그래밍 언어의 메서드명을 이용하지 않는다.
4. 세션 ID를 포함하지 않는다.
5. 해당 리소스를 표현하는 명사로 한다.


나쁜 예)
  http://example.com/cgi-bin/login.pl
  http://example.com/servlet/LoginServlet
  http://example.com/Login.do?action=showPage
  http://example.com/home.jsp?jsessionid=12345678
  http://example.com/sample/people/show/123


어찌보면 너무 당연한 이야기라 쉽게 흘려보낼 것 같다.
다만, URI를 정할 때엔 잊지말고 다시 떠올리자.

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG Cool URI, URI, URL
Trackback 0 Comment 0
Daylogs/Etc

git rm -r . 복구하기

발생일: 2011.12.01

문제:
git 으로 관리하고 있는 소스 폴더가 있는데, 사용하지 않는 파일을 git bash가 아닌 윈도우 폴더에서 삭제했다.
파일 삭제 후 커밋하고 github으로 푸시했는데, 이상하게 폴더에서 삭제한 파일은 github에 반영이 되어 있지 않더라.

이상하다고 생각하고, 매뉴얼을 찾아보다가 git rm 이란 명령어가 있는 걸 발견했다.
rm 도 add 랑 같은 개념이라고 생각하고 가볍게 git rm -r . 명령어를 날렸는데,
폴더 내 모든 파일이 삭제되더라.

오... 갓.

해결책:

git reset --hard HEAD

역시 스택오버플로우. ㅎㅎ
http://stackoverflow.com/questions/2125710/how-to-revert-a-git-rm-r 



저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG GIT, git rm
Trackback 0 Comment 2
Daylogs/Etc

저자 워크숍

발생일: 2011.07.05

문제:
사내 메일에 팀 독서 발표 모임에 대한 사례를 공유한 메일이 왔다.

각자 책을 읽고 워크샵을 통해 발표한 후, 긍정적 피드백과 개선 피드백을 받는 형식이었고,
여러 시행착오를 통해 성공적으로 모임을 정착시킬 수 있었다는 이야기였다.

피드백 과정을 도입할 때에는 김창준님의 컬럼을 참고했다고 하는데,
이 컬럼 내용이 특히 인상 깊어 메모해둔다.

해결책:
저자 워크숍


플랍(PLOP, Patter Language of Programs)이라는 컨퍼런스 행사 중에 저자 워크숍이라는 것이 있는데,
여러 사람의 의견을 통해 저작물을 개선하려는 것이 목적이라고 한다.

전체적인 진행 과정은 아래와 같다.

1. 글을 읽는다.
2. 저자를 환영한다.
3. 저자가 일부분을 읽는다.
4. 요약
5. 긍정적 피드백
6. 개선 제안
7. 저자의 질문
8. 저자에게 감사하기

흥미로운 부분은 4번부터 6번 과정 중에 저자는 한 마디도 할 수 없다는 것이다.

다른 참가자(마찬가지로 각자도 저자이다)들은 4번부터 6번의 과정을 걸쳐 서로 피드백을 나누는데,
특히 긍정적 피드백과 부정적 피드백을 확연히 구분해 놓은 것도 눈여겨 볼 만하다.

피드백을 받은 저자는 취사 선택해 자신의 저작물에 도입하면 된다.


일전에 참여했던 XPER 모임에서도 느꼈던 거지만, 이런 열린 모임은 굉장히... 뭐랄까. 두근두근한다~ ^^

자세한 내용은 원문을 읽어보자~


저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG 모임, 저자 워크숍, 책읽기
Trackback 0 Comment 0
Daylogs/Etc

프레임워크와 라이브러리의 차이점

프레임워크도 제어의 역전 개념이 적용된 대표적인 기술이다.
프레임워크는 라이브러리의 다른 이름이 아니다.
프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.
프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다.
라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 
단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.
반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.
최근에는 툴킨, 엔진, 라이브러리 등도 유행을 따라서 무작정 프레임워크라고 부르기도 하는데 이는 잘못된 것이다.
프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.
애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.


인용: 토비의 스프링3. 1장_ 오브젝트와 의존관계 p.95


평소에 "프레임워크와 라이브러리의 차이점"을 명확하게 구분하지 못하고 있었는데,
'토비의 스프링3' 책을 읽다가 이에 대한 부분이 있어 메모해둡니다.

위 정의에 따르면 jquery, jindo 등은 라이브러리라고 해야겠군요. ^^



저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG framework, Library, 라이브러리, 프레임워크
Trackback 0 Comment 0
Daylogs/Etc

프리젠테이션 잘 작성하기


"어떻게 하면 프리젠테이션을 잡스 횽아처럼 잘 작성할 수 있을까?"


역시 비주얼이다!! 라고 생각하셨나요? (저처럼? ^^;)

그러셨다면 흉내를 좀 내본다고 이미지 위주로 화려하고 빠른 프리젠테이션을 만들었다가

실제 업무에 활용하기엔 적합하지 않아 포기했던 경험도 있으셨을 것 같아요.


요론 고민들에 도움이 될 수 있는 좋은 강의가 있어요.

아래 링크의 슬라이드를 꼭 한 번쯤 시간을 내서 읽어보시길 추천드립니다.^^


[2차 공개강의 : 프레젠테이션에 대한 새로운 시각]


저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG 프레젠테이션, 프리젠테이션
Trackback 0 Comment 0
Daylogs/Etc

SM 개발자로서 SI 프로젝트 개발자에게 바라는 점

얼마 전에 진행하고 있던 프로젝트가 종료되었습니다.
일정에 맞춰 종료되었지만 개인적으로 만족스러운 프로젝트는 아니었습니다.
회사에서 진행하는 프로젝트의 대부분이 그렇듯이 품질보다는 완성에 초점이 맞춰진 프로젝트였거든요.

저희 팀은 유지보수가 주업무다 보니 프로젝트 시 직접 코딩에 참여하지는 않습니다.
그러다보니 SI 팀에서 진행한 프로젝트를 건내 받아 코드를 열어 보고 나면 한숨이 나올 때가 많습니다.
물론 그 중에 굉장히 잘 만들어진 코드가 있기도 하고, 
과연 우리가 만든다면 더 나은 코드가 나올 것이냐. 에 대해서도 장담할 수 없지만,
이걸 가지고 운영해나갈 생각을 하면 저절로 한숨이 나오는 걸 어찌하나요~ ^^;

물론, 프로젝트 진행 중에 함께 참여해서 코드 리뷰하고 하고 중간 중간 점검도 해야하겠지만,
이번을 포함하여 회사에서 진행되었던 대부분의 프로젝트 일정이 어처구니 없을 정도로 촉박했던 터라
여건 상 그렇게 하지 못하는 경우가 대부분이었습니다.
중간에 제대로 점검 및 서포트 하지 못했던 우리의 잘못도 크지요.
결국은, 모두의 잘못인 거겠죠...

아래는 이번 프로젝트에서 잘 지켜지지 못해서 아쉬웠던, 
Java 프로젝트에 있어 지켜져야 한다고 생각하는 것들을 정리한 내용입니다.


개발표준안을 정하고 지속적으로 표준을 지키고 있는지 확인해야할 점들



보시다시피 별 대단한 내용이 아닙니다.
개발자라면 모두 아는 내용이고, 기본적인 거지요.
뛰어난 로직을 바라는 게 아니라, 표준이 잘 지켜진 알아볼 수 있는 코드를 부탁하는 거예요.

문제는 이런 내용을 모두 알고 있으면서도 지키지 않는다는 거예요. (혹시 잘 모른다면 공부하셔야 합니다.)
단지 시간도 없고 귀찮다는 이유로, 대충 마음에 드는 대로 작성하고 Copy & Paste 하고 말아버리는 거죠...
'어차피 내가 할 거 아닌데...' 라는 생각을 가지기도 하고,
심지어는 '쟤네들 이거 받아서는 고생 좀 하겠군.' 이라고 생각하기도 하지요.

다소 도발적일 수도 있지만, 
누군가가 내가 작성한 코드를 보고 
'이거 누가 이렇게 개떡같이 짜놨어??' 라고 하는 걸 상상해보세요.

SI 팀에서는 '우리가 완성한 프로젝트를 누군가가 받아 운영하게 될 것' 이라는 걸 항상 염두해주시면 좋겠습니다.
SI 프로젝트 개발자에게 바라는 건 '코드에 대한 책임감' 입니다.

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG SI 프로젝트, 개발표준
Trackback 0 Comment 1