흔한 개발자 이야기

1. 커미터 목록 정리

Subversion 저장소를 checkout 해둔 경로에서 다음 명령어를 입력해서 커미터 목록을 저장한다.

이제 파일 내용을 보면 각 줄마다 커미터 정보가 아래와 같은 형식으로 있을 것이다.

meye = meye <meye>

이것을 아래와 같이 적당히 고쳐준다.

meye = mEye <meye@dev.meye.net>

2. git-svn으로 Subversion 저장소 가져오기

중간 작업들을 하기 위해서 임시로 가져온다.

3. .gitignore 만들기

Subversion 저장소에 설정한 "svn:ignore" 설정들을 .gitignore 파일로 옮기고 커밋한다.

4. Git bare 저장소를 만들기

이제 준비작업은 다 끝났으니 Subversion 저장소를 옮길 Git bare 저장소를 새로 만든다. 이 저장소의 기본 브랜치(HEAD)를 Subversion의 "trunk" 브랜치와 연결해둔다.

5. Subversion 저장소를 새 Git 저장소로 옮기기

여기까지 끝났으면 이제 Subversion 저장소를 clone 경로는 삭제해도 된다.

이제 trunk로 되어있는 브랜치 이름을 master로 바꾸자.

6. 태그 정리

git-svn은 Subversion의 태그들을 git의 브랜치로 만들어 두기 때문에 이를 git의 태그로 변환하는 과정이 필요하다. 각 줄의 > 는 입력하는 것이 아니고, 하나의 명령을 여러 줄에 걸쳐서 입력할때 쉘에서 보여주는 프롬프트 표시이다.(이제와서 설명하기도 좀 그렇지만, 당연히 $ 표시는 쉘 프롬프트 표시이다.)

7. 완료

이제, git 저장소가 준비되었다. 새로 만든 bare 저장소(여기서는 new-bare.git)를 적당한 곳에 복사해놓고 사용하면 된다.

[참고]

• http://john.albin.net/git/convert-subversion-to-git
• http://john.albin.net/git/git-svn-migrate

이전 글(Ubuntu에 Solr 최신버전 설치)에서 설치까지만 다루고, 실제 사용하기 위한 설정들을 두번째 글에 다룰 예정이었는데, 생각보다 포스팅이 늦어졌다. 하지만, 아직도 한글 분석기 Arirang Analyzer 1.1.2 이후로 개선 소식이 없어, Solr 4.7.0 까지 나온 현재에도 4.5.X 까지만 사용할 수 있는 문제는 여전하기 때문에 아직 유용할 것이라 생각해서 정리해본다.

이전 글에서는 Solr 4.5.0만 언급했지만, 4.5.1에서도 Arirang Analyzer는 잘 동작하므로 한글 분석기를 사용하기 위해서는 Solr 4.5.1을 설치하면 된다. 과거 버전이라 Solr 공식 웹사이트에서는 배포하지 않지만, 아파치 아카이브 사이트에서 다운로드 받을 수 있으며 설치 과정은 이전 글에서 소개한 것과 동일하다. (아카이브 사이트라서 그런지 조금 느리다)

1. 코어 설정

이전 글대로 설치했다면, /usr/local/share/solr 디렉토리는 아래와 같이 구성되어 있을 것이다.

저기에서 collection1 이라고 되어있는 것이 코어이다. 여러개의 코어를 설정할 수 있는데, collection1을 복사하거나 이름을 바꿔서 사용할 코어를 만들자. 여기서는 'collection2'라고 이름을 바꿔서 진행해본다.

설치할때 소유자 변환을 해두었기때문에 root로 작업 중이 아니라면, 항상 sudo를 붙여서 작업해야하는 것에 유의한다.

이제 collection2 디렉토리를 보면 여러개의 파일이 있는데, 당장 사용하기 위해서 수정해야할 파일은 딱 다음 세 개이다.

• core.properties
• conf/solrconfig.xml
• conf/schema.xml

먼저 core.properties 파일을 보면 딱 한 줄이 있는데, 내용을 보면 뭘 고쳐야할 지 바로 감이 올 것이다. 다음과 같이 새로 만든 코어 이름을 적어준다.

다음으로 conf/schema.xml 파일은 인덱스에 저장할 스키마 설정이 있다. 주석을 보면 어떻게 작성해야하는지 감이 올텐데, 중요한 것은 field와 fieldType 이다. <fields> 안에 있는 <field> 태그들이 인덱스에 저장할 스키마들인데, 주석을 보면서 필요한 것들을 설정하면 된다. <types> 안에 있는 <fieldType>은 어떤 field가 있을 수 있는지 형식을 지정할 수 있는데, 한글 검색을 위해서 추가한 Arirang Analyzer를 사용하기 위해서 새로운 형식을 만들 필요가 있다.

<types> 안의 적당한 곳에 아래 내용을 넣으면, text_ko 라는 형식 사용할 수 있다.

conf/solrconfig.xml 파일에는 코어 설정들이 있는데, 바로 사용해보기 위해서는 라이브러리 경로 설정들을 바꿔줘야한다. 나머지 설정들은 천천히 주석을 살펴보고 고치도록 한다. 당장 수정해야할 경로 설정들은 아래와 같다.

위의 설정에서 경로들을 아래와 같이 고친다.

여기서는 다른 설정이 필요없지만, conf/schema.xml 파일에서 스키마가 수정되면, conf/solrconfing.xml 파일을 수정해야할 수도 있다.

2. 라이브러리 복사

conf/solrconfig.xml 에서 변경한 라이브러리 경로대로 라이브러리를 복사하자. 이전 글에서 했듯이 solr를 다운로드 받아서 압축을 푼 디렉토리에서 복사한다.

3. 인덱싱

설정이 끝났으니 이제 인덱싱을 해볼 순서이다. 그 전에 먼저 설정들이 바뀌었으니 jetty 재시작부터 하자.

여기에서는 간단히 동작하는 것만 확인하기위해서 Solr 튜토리얼에 있는 방식으로 example 코드와 데이터를 사용해본다. 아까 사용한 solr 압축 푼 디렉토리 밑에 example/exampledocs 라는 디렉토리가 있을텐데 거기로 이동하면, 간단히 인덱싱을 해볼 수 있다.

4. 확인

인덱싱이 잘 되었는지는 다음 URL로 접근해서 확인할 수 있다.

http://localhost:8080/solr/collection2/select?q=solr

또는, 다음 URL로 확인해볼 수 있다.

http://localhost:8080/solr/collection2/browse

여기까지 했으면 기본적인 설치/설정은 해본 것이지만, 사실 한글 분석기는 사용하지 않았고, 실제로 사용해보려면 사용할 데이터에 알맞는 스키마를 설정해야한다. 이것은 (기약은 없지만) 다음 글에서 다뤄보겠다.

나온지는 꽤 오래된 책인데, 이제야 읽었다.

(마이크로소프트 같은) 성공하는 기업의 비밀은 뭔가를 잘 해서가 아니라 다른 회사에 비해서 중대한 실수, 즉 초난감한 결정을 적게 했기 때문이라는 전제에서 이야기를 풀어나가고 있다. 굵직굵직한 IT기업들의 흥미로운 숨은 이야기들을 다루고 있어서 그냥 재미로 읽기에도 괜찮았다.

---

초난감 기업의 조건

저자

릭 채프먼 지음

출판사

에이콘출판 | 2007-11-20 출간

카테고리

경제/경영

책소개

실패한 초우량 기업들의 사례로 배우는 기업 마케팅 성공전략! ...

글쓴이 평점  

---

코딩 호러 블로그에 올라온 글들을 모아서 엮은 책. 블로그에 올라온 글들을 엮었다는 점에서 조엘 온 소프트웨어 책과 비슷한데, 저자인 제프 앳우드는 질문/답변 사이트로 유명한 스택 오버플로우 공동 창립자이다.

서비스를 만드는 팀에 속한 개발자들에게 유용한 보석같은 정보/지식 들이 듬뿍 담겨있어서 뭐 하나 버릴게 없지만, 몇 가지만 적어본다.

... 아이디어만 있는 것은 속이 텅 빈 껍질에 불과하다. 성공이 아이디어의 질에 의해 결정되는 경우는 거의 없다. 그것은 대부분 실행의 질에 의해 결정된다. 따라서 당신이 실천에 옮기게 될 거대한 아이디어가 정말로 탁월한 것인지 여부를 놓고 걱정하는 것이 아니라 실행 방법이 옳은 것인지 걱정해야 한다.

- "아이디어가 아니라 팀을 가꿔라" 중에서 (p.81)

... 그렇다고 해서 그것이 제대로 동작한다는 사실을 의미하는 것은 아니다.

사용자들이 실제로 애플리케이션을 이해할 수 있는가? 그 애플리케이션을 사용해서 필요한 업무를 수행할 수 있는가? 제대로 동작하는 애플리케이션을 가르는 기준은 바로 이런 질문이 돼야 한다.

- "싸구려 사용성 테스트" 중에서(p.295)

게임은 학습을 돕는 도구다

게임은 사람들로 하여금 특정한 목표를 향해 나아가도록 도움을 준다

- "게임화" 중에서 (p.322, p.323)

원문이 블로그인 특성상 주석에 많은 링크가 달려있는데, 책으로 읽다보니 일일이 확인하기 어려운 단점이 있었다. 그래서 한국어판 출판사인 위키북스에서 책 소개 페이지의 관련자료 부분에 본문링크를 정리해 두었다. 책을 읽고나서 확인할때 유용하다.

이 책의 속편인 "코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기"도 있던데, 시간 나는대로 꼭 읽어봐야겠다.

---

이펙티브 프로그래밍

저자

제프 앳우드 지음

출판사

위키북스 | 2013-03-29 출간

카테고리

컴퓨터/IT

책소개

코딩 호러 블로그의 운영자이자 스택 오버플로우 공동 창업자가 알...

글쓴이 평점  

---

우분투에서 Solr를 사용해보려고 했더니 12.04 LTS 버전에 있는 패키지는 1.4.0 이었다. 우분투 최신버전이라고 해도 3.6.2라서 현재 Solr 최신버전인 4.6.0과는 차이가 있었다. 하다못해 마이너 버전 차이정도는 좀 눈감아주겠는데, 이건 좀 심하다 싶다.

어쨌든 저런 이유로 최신버전을 직접 설치했고, 그 과정을 한번 정리해보았다.

1. Solr 최신 버전(현재 4.6.0) 다운로드
2. 패키지 준비
3. jetty 설치/설정
4. 서비스 시작

1. Solr 최신 버전 다운로드

Solr 공식 페이지에서 다운로드 한다. solr-4.6.0.tgz 파일을 받으면된다.

2. 패키지 준비

배포본에 있는 war파일을 기본으로 필요한 것들을 조금 추가한다.

1. solr-4.6.0.tgz 압축 해제
   

   cd solr-4.6.0/dist/
   mkdir temp
   cp solr-4.6.0.war temp/
   cd temp
   jar xf solr-4.6.0.war
   rm solr-4.6.0.war
   

   
   
2. 필요한 파일 추가
   필요한 라이브러리들을 위에서 war 파일 압축을 푼 WEB-INF/lib/ 에 추가한다.
   내가 추가한 것은 한글분석기인 Arirang Analyzer(현재 루씬 한글분석기 커뮤니티에서 받을 수 있음. 네이버 카페 가입 필요)와 Solr를 동작시기키위해서 필요한 것들이다.
   

   (위에 이어서)
   cp ../../example/lib/ext/* ./WEB-INF/lib/
   cp arirang.jar ./WEB-INF/lib/
   

3. 재압축
   

   jar cf ../solr.war *
   

3. jetty 설치/설정

1. 설치
   

   (계속 이어서)
   sudo apt-get install jetty
   cd ../.. (solr-4.6.0으로 이동)
   sudo cp -a example/solr /usr/local/share/solr
   sudo chown -R jetty:jetty /usr/local/share/solr
   sudo cp dist/solr.war /var/lib/jetty/webapps/
   

2. /etc/default/jetty 편집
   

   NO_START=0
   JETTY_HOST=0.0.0.0
   JAVA_OPTIONS="-Dsolr.solr.home=/usr/local/share/solr -Dsolr.clustering.enabled=false $JAVA_OPTIONS"
   

4. 서비스 시작

sudo service jetty start

http://localhost:8080/solr/ 로 접속하면 다음과 같은 Solr 페이지를 확인할 수 있다.

5. 참고

현재(2013/11/27), 루씬 한글분석기 커뮤니티에서 배포하고 있는 Solr 4.X용 Arirang Analyzer 1.1.2는 Solr 4.6에서는 에러가 발생하는 것으로 보인다. 따라서, 새 버전의 Arirang Analyzer이 나오기 전에는 4.5를 사용해야할 것 같다.

어느 회사의 채용 퀴즈를 보고 잠깐 파이썬으로 풀어봤다.

다음에서 주최하는 DevOn에 다녀왔다. 이전의 DevOn이나 다른 국내 개발자 컨퍼런스와는 다른 컨셉의 행사를 기획했다고 해서 그런 변화가 괜찮을지 반신반의했는데, 다녀와보니 이런 형태의 컨퍼런스가 개발자들에게 더 유익하다는 생각이 들었다. 특히, 개발자들의 교류, 소통을 장려하는 측면에서 좋았다.

Processing 코드랩을 하나 듣고, 계속 부스를 돌아다녔는데, 동아리 후배들이 부스를 운영하고 있어서 거기도 들렀고, 냠냠이 전시도 들렀다. 다른 곳들도 돌아다니다보니 오랜만에 종광님도 센차유저그룹 부스에서 만났다.

여러 동아리 부스들에서 만났던 학생들이 인상적이었는데, 아직 어린 나이에 많은 것들을 시도해보는 모습이 부럽기도 하고, 나는 뭘 하고 있나 하는 생각에 자극도 되었다.

그 외에는 워드프레스사용자모임에서 사용해서 그런 퀴즈 플랫폼이 있다는 것을 알게되었고, 예전에 한번 슬쩍 봤던 기억이 있는 AXISJ가 꽤 쓸만해 보였다. 그리고, 모바일 파이어폭스에서 동작하는 웹사이트를 데스크탑에서 디버깅할 수 있는 기능이 있다는 것도 새로 알게 되었다.

이번 행사에서 아쉬운 점을 하나 꼽자면 의외로 허술하게 만들어지고 운영된 행사 웹사이트였다. 아마 행사 기획 자체가 좀 색다른 형태라서 웹사이트 제작에 신경을 많이 쓰지 못한게 아닌가 싶을 정도였다. 결제와 가입은 있지만, 환불및 탈퇴는 없었고, 그 흔한 비밀번호 찾기도 없는 사이트에, 발표 세션별로 신청을 할 수 있게 한다는 공지와는 달리 행사 전체를 통째로 신청해야했다. 게다가 어떤 세션은 시간이 중복되는데도 신청이 되는 경우도 발견했다.

웹사이트도 그렇고 행사가 약간 산만한 느낌도 있어 강연을 찾아듣기는 어려웠지만 그만큼 우연한 발견이 많았던 것 같고, 행사 전체가 개발자들의 축제같은 느낌도 들고 신선한 느낌이었다.

Naver에서 추최하는 개발자 컨퍼런스 Deview에 다녀왔다. 이틀에 걸쳐서 진행되었는데, 두번째 날에만 다녀왔다. 내가 들은 것을 좀 정리해본다.

1. Google 검색

• 구글에서 크롤링할 때, 쿼리 파라메터까지 파싱해서 값에 상관없이 동일한 페이지를 보여주는 것은 무시하고 동일한 링크로 처리한다고 한다.

2. RecoPick

• 쿠키기반 UID, 행동에 의한 추천
• 유사한 기호의 사용자를 필터링하기 위해서 Minhash 기반 필터링 사용
  
• 추천 가중치 : 레퍼러, 행동(구매 > 장바구니), 시간, 기사 유사도
• 추천된 키들의 순서로 MD5를 구해서 키로 사용

3. Docker

• 리눅스 컨테이너를 사용하여 배포와 관리를 편하게 하는 도구. https://www.docker.io/
  

기타 다른 것들은 Deview 2013 홈페이지에서 확인할 수 있다.

PHPFest 2013이 있었다. 국내에서는 많이 사용하면서도 기술 공유는 비교적 적은 PHP 개발자들에게는 가뭄에 단비같은 행사가 아닐 수 없다. 2009년에 PHPFest가 있었고, 최근에는 제작년에 있어서 갔던 기억이 있다. 밑에 있는 올해 행사 공지를 봤을때, 관심있는 발표가 꽤 있어서 꼭 가야겠다고 생각했다. 가보니 생각보다 참석한 사람도 많았고, 발표 내용도 좋았다. 각 세션별로 들은 내용을 한번 정리해 본다.

1. PHP 애플리케이션 성능 향상방법

• 빠른 코드를 만들기 위해서 연구하느라 리소스(시간, 비용)를 투입하는 것 보다는 PHP 최신 버전을 사용하는 것이 효율이 좋다.
• OpCache 등의 캐시를 사용하라.
• 리팩토링을 위한 툴을 활용 : xdebug, Jmeter
  

2. Elastic Beanstalk

• 비용만 괜찮았다면 회사에서 사용하고 싶을 정도로 편리하게 해놨다. 이제 시작하는 스타트업의 경우는 괜찮은 선택일 수도 있겠다. 자세한 것은 아마존웹서비스 안내를 참고.
  

3. MySQL - 5.5 이하 버전을 기준으로

• FROM절 서브쿼리
• Stored function에서의 Deterministic : NOT인 경우(Default) 인덱스를 사용하지 않아서 성능 이슈
• IN (서브쿼리) 형태 : 외부 쿼리 결과의 ROW 수 만큼 서브 쿼리가 수행됨. 해결은 JOIN으로 대체하거나 괄호 안의 서브쿼리를 미리 상수화하는 방법, GROUP BY로 해결하는 방법도 있다고 한다.
• 트랜젝션시에는 외부 작업을 하지 않아야 한다.(외부 작업이 중단되버리면 Lock이 오래 지속됨) 자원이 IDLE인데 쿼리 처리 속도가 느리면 다음과 같이 Lock을 확인해본다.
  

  > SHOW ENGINE INNODB STATUS;
  ...
  .... TRANSACTION 3F0B, ACTIVE 23sec .... // 1초 이상이면 문제임
  > pager grep ACTIVE; // 유닉스에서 위의 구문만 찾을 수 있도록 해주는 명령

• 긴 쿼리는 이해하기도 어렵고, 최적화가 어려우므로 피하자.
• Unique Index가 많으면 Lock
• memcached 등의 캐쉬를 사용한다면, 없는 데이터에 대한 것도 캐쉬할 필요가 있을 수 있다.
  
• 문의는 http://cafe.naver.com/realmysql

4. Javascript

• 이벤트 핸들러는 버블링을 사용 : Target은 hasClass() 등을 사용해서 판별
• (이제는) localStorage를 사용
• 문자열 합칠 때에는 배열을 join한다. 다른 예는 Array(11).join("a") 의 형태.
  
• 개체를 추가할때는 append()보다는 html()을 사용
  
• 추천 툴 : jsmatch, jsperf, DynaTrace, Yslow
  

후기를 좀 더 보태보면, 원래 계획표에 있는 코드이그나이터 발표는 발표자의 안타까운 개인 사정으로 취소가 되었다는 것을 행사가 시작하면서 미리 공지되었기에 이해하더라도, 마지막 순서로 있는 HipHop 발표는 하지 않고, 갑자기 Q&A 시간을 가지는 바람에 좀 당황했다. 나처럼 HipHop 발표를 기대한 사람들이 분명 있었을텐데 별다른 설명도 없었고, 설명을 듣는다고 달라질 것도 없는 것 같아서 따로 물어보지는 않았지만, 이전의 PHPFest도 그랬듯이 행사진행이 매끄럽지 않다는 느낌을 가지게 했다. 그리고, 사전 등록도 받았는데, 경품 추첨 같은 것도 미리 준비했으면 어땠을까 하는 아쉬움이 남는다.

진행상의 옥의 티는 있을지라도 행사 자체는 유익했다. PHP Korea에서 목표로 하고 있듯이 매년 PHPFest가 열리기를 기대한다.

Ben Horowitz가 블로그에 올린 Why We Prefer Founding CEOs를 "우리가 '창업자 CEO'를 선호하는 이유"라는 제목으로 번역한 글이 있어서 읽어보았다.

이 글에서 대부분의 훌륭한 기술 회사들이 창업자 CEO를 통해서 만들어졌다고 이야기하면서, 이러한 이유에는 "혁신"이 자리하고 있다고 주장한다. 이 혁신의 원동력은 뛰어난 혁신가였던 창업자 CEO들의 용기라고 하는데, 이들에게는 세가지 특성이 있다고 한다.

• 폭넓은 지식 (Comprehensive knowledge)
• 도덕적 권위 (Moral authority)
• 장시간의 헌신 (Total commitment to the long-term)
  

또한 CEO의 자질이 있는지 알아볼 수 있는 특성을 두가지로 설명하고 있다.

• 리더십(Notes on Leadership에서 확인 가능)
• 열정