흔한 개발자 이야기

개발자의 연애, 업무, 해외 취업 등에 관한 이야기와 팁 등을 다룬 가볍게 재미삼아서 읽기 좋은 책.

저자 블로그 : http://theonion.egloos.com

---

개발자를 부탁해

저자

주한나 지음

출판사

인사이트 | 2011-09-30 출간

카테고리

컴퓨터/IT

책소개

대스러움이란 무엇이기에 이다지도 공대생은 고생하는가!주로 이과를...

---

SpringCamp 2014에 다녀왔다. SpringCamp에 가본 것은 처음인데, 참가신청 페이지의 컨퍼런스 소개글을 보면 다음과 같이 소개하고 있다.

애플리케이션 서버 개발자들과 함께 가치있는 기술에 관한 지식과 정보를 '공유'하고 참가한 사람들이 서로 '인연'을 만들고 시끌벅적하게 즐길 수 있는 '개발자들을 위한 축제'를 목표로 하는 컨퍼런스

"Spring"이라는 이름이 들어갔지만, 세션 내용들은 Spring Framework에 대한 이야기에 국한되지 않은 점에서 서버 개발자들의 지식, 정보의 "공유"라는 측면은 좋았다. 하지만, "인연"을 만드는 부분은 좀 아쉬웠다. 이런 컨퍼런스에서 그저 많은 사람들이 한자리에 있다고 해서 통성명하고 이야기를 나누게 되는 것이 자연스러운 일은 아닌 것 같다. 아무래도 중간에서 소개하는 사람이 있지 않으면 새로운 인연을 만들어가기가 쉽지 않은데 이런 점이 좀 더 고민되어야하지 않나 하는 생각이 들었다.

그러면, 들은 발표를 간단히 정리해본다.

조금 더 좋은 개발자가 된다는 것 : 컨퍼런스 발표자가 된다는 것 - 박용권

일종의 기조 연설같은 느낌의 발표였는데, 요지는 이런 자리에서 발표하는 것을 망설이지 말라는 내용이었다.

설계도구 실전 활용 사례 - 안영회

설계도구를 활용하는 것까지는 아직 검증이 되지 않아서 이미 공지된 제목의 발표를 하지 못하고 주제를 바꿨다는 설명을 발표에 앞서 하면서 "실용적 소프트웨어 설계를 위한 근본적인 질문들"이라는 제목으로 발표가 진행되었다. 갑자기 주제가 바뀌었다는 말을 들어서인지 발표를 들으면서도 이상하게 집중도 어렵고 이해도 어려웠다. (그냥 내가 설계에 대해서 아는게 없어서..) 그래도 몇가지 기억에 남는 것만 적어본다.

• 설계시 사용하는 용어의 통일이 중요하다.
• 소프트웨어는 계속 변화하는 유기체이다.
• 완벽하게 설계를 하겠다는 결벽증은 버리자.
• 새로운 개발자는 코드를 파악하고 "멘탈 모델"을 그리는게 중요함

스프링 어플리케이션의 문제해결 사례와 안티패턴 - 정상혁

아주 명확하고 실제로 도움이 될만한 팁을 전수받는 느낌의 발표였다. View cache 기능 관련해서 Spring에 패치된 코드는 간단한 캐쉬를 구현하기에 좋은 예제가 될 수 있다는 것을 알았고, XXE Injection이라는 것을 처음 들어봤다. 자세한 내용은 발표 자료가 공개되면 보면 될 것 같다.

발표 내용과는 관계없지만, 우분투 노트북으로 데모도 보여주면서 발표하는 모습이 자연스러워서 인상적이었다.

실시간 알림 기능 구현 사례 - 이연복

vert.x와 zookeeper를 사용한 푸시 서버를 구현한 사례였는데, BlazeDS와 Flex도 사용했다고 한다.

내가 파이썬을 선택한 이유 - 최윤석

자바(Spring Framework)을 버리고 파이썬(Django Framework)을 사용한 사례에 대한 발표였다. 제목인 "선택한 이유"는 빠른 개발 속도와 필요한 만큼만 배워서 쓸 수 있다는 점에 있었다. 라이브 코딩을 진행했는데 마치 예전에 루비온레일즈를 유명하게 만든 블로그 만들기 동영상을 보는 것처럼 빠르고 간편하게 코딩을 하는 모습을 체험할 수 있었다.

린 스타트업 하다가 "잘"망한 이야기 - 강규영

나에게 오늘의 최고의 발표를 꼽으라면 이 발표를 꼽을 것 같다. 서비스를 만들고, 발전시키다가, 정리하게 된 것 까지 순서대로 흥미롭게 이야기했다.

1. 사용자 조사 : 경쟁 앱을 직접깔아서 사용자들에게 물어봤음 -> 여 - 매너("변태" 문제), 남 - 답장 중요함
2. 디자인
3. ?? (생각이 잘 안남)
   
4. 프로그래밍 : GAE, Urban Airship 등
5. 릴리스
6. 마케팅 : 경쟁 앱을 통해서 메시지로 홍보함. 직접 홍보(X) 간접적인 메세지로 홍보(O)
7. 중지 : 갑작스런 사용자 증가로 비용이 증가, 푸시 서비스 중단
8. 점진적 개선 : OORP에 나오는 Bridge to New Town 패턴을 사용. memcached를 임시 저장소로 사용. Active 사용자의 정보를 구/신 저장소에 모두 저장하다가 Inactive 사용자는 batch로 마이그레이션.
   
9. 끝
   

사용자에게 중요한 요소로 파악된 요소 중 하나인 매너를 확보하기 위해서 수행한 것은 변태(적인 메시지를 보내는 사람)와의 전쟁이었고, 이것에 성공하지 못한 것이 발표자가 밝힌 사업 철수의 한 원인이기도 했다. "변태"를 퇴치하기 위해서 사용한 방법들로 기억나는 것을 적어보면,

• 메시지 필터링 : 정확도는 낮지만 비매너 메시지를 다 잡는 필터A, 정확도가 높아서 확실한 비매너 메시지만 잡는 필터B
• 유죄 추정의 원칙 : 남자의 경우 "변태"로 추정하고 답장을 받았을 경우에만 매너남일거라고 추정함
• 신고 : 신고를 받으면 메시지 전송을 제한
  
• 거짓 신고 방지 : 24시간 유지되는 DB에 한 사용자가 3번까지 할 수 있으며, 3명 이상이 신고하면 처리됨. 처리되면 추가 신고 가능해짐

그리고 또다른 사용자들의 요구 사항 중의 하나인 답장을 받을 수 있도록 하는 방법은 성비 불균형 문제를 해결하는 것이었다. 성비를 비슷하게 만들기 위해서 고안한 장치가 흥미로웠는데 발표자료가 공개되면 그림으로 다시 확인할 수 있을 것 같다. 대충 설명해보면 Active 남자가 보내는 메시지는 Active 여자에게만 보내고, 남는 것들은 쌓아둔 상태로 Inactive 여자에게 메시지가 있다는 것을 알려주는 역할로만 기능하다가 Active로 전환되면 그때 보내는 방식이었다.

그 외에 여자 사용자의 참여를 독려하기 위해서 부영이에게 말풍선을 달아서 메시지를 작성하도록 했더니 5%의 실제 메시지 작성 증가가 있었다는 것이나, 수익구조로 부엉이 꾸미기를 계획했다든지 하는 내용도 있었고, 단문 분석을 위해서 자소분리 후 분석해서 좀 더 많은 정보를 분석할 수 있었다는 내용도 있었다.

즐거운 개발을 위한 스마트한 습관 - 강대권

Redmine + SonarCube + Jenkins = 자동화로 인한 개발 편의

비동기 그리고 이벤트 - 강지훈

비동기나 이벤트라는 것이 새로운 기술이 아니고, 어떤 서비스를 구현할때 적당한 알고리즘이나 솔루션보다는 요즘 유행하는 키워드에 맞는 것만 생각하려는 경향을 경계해야한다는 요지의 이야기가 기억에 남는다.

아직 공개된 발표자료도 몇 개 없지만, 관련된 링크를 모아봤다.

• 설계도구 실전 활용 사례 발표자료
  
• Neo4j로 만들어보는 LOL 전적검색 발표자료
• 시작하자! 단위테스트 발표자료
• Rest Service with Spring 발표자료
• 스프링 어플리케이션의 문제해결 사례와 안티패턴
• 미국인에게 영어 프리젠테이션을 해봤어요
• Spring-Boot (예제) (war 배포방법)
  
• SpringCamp 2014 페이스북 이벤트 페이지
• SpringCamp 페이스북 페이지
• SpringCamp 2014 공식 사이트
• 온오프믹스 SpringCamp 2014 페이지
  

Firefox 개발자 콘퍼런스 2014가 있었다. 유료행사에 평일이었지만, Firefox OS에 관심이 좀 있었기때문에 가보았다. 딱히 정리할만한 내용은 없는 것 같고, 기억에 남는 것들을 키워드와 URL 위주로 나열해 본다.

• MDN(Mozilla Developer Network)에 Mozilla building blocks라고 UI/UX 컴포넌트를 정리해둔게 있다.
• Firefox OS Building Blocks
• HTML5 Boilerplate도 Firefox OS 앱 제작에 도움이 됨.
• WebAPI
• Firefox OS 한글키보드 이름은 jangmiIME였음.
• Webmaker.org
• caniuse.com
• w3c.github.io
• responsiveimage.org
• webpaltform.org
• html5gameengines.com

라인앱 개발 사례 발표자가 발표 중 강조하는 것이 메모리였다. 메모리가 2G 이상은 되어야 앱 개발해서 쓸만한 폰이라고 이야기하더라.

기타 내용은 공식사이트에 동영상도 올라오니 참고하면 되겠다.

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가 꽤 쓸만해 보였다. 그리고, 모바일 파이어폭스에서 동작하는 웹사이트를 데스크탑에서 디버깅할 수 있는 기능이 있다는 것도 새로 알게 되었다.

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

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