달력

112019  이전 다음

  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

재밌는 서비스입니다. GitHub의 활동을 기준으로 재밌는 리포트를 생성해주는 서비스입니다.

http://osrc.dfm.io/kenu





Posted by 케누 kenu허광남

댓글을 달아 주세요

다음 커뮤니케이션의 초청으로 제주대에서 발표한 자료입니다.

파일 첨부합니다.


20120518_다음제주_내가 경험한 오픈소스.zip





Posted by 케누 kenu허광남

댓글을 달아 주세요

세상에는 두 종류의 사람 얘기하면서 Hello World를 아는 개발자와 모르는 일반인으로 구분하고는 했습니다. 유사한 경우가 소스라고 했을 때 소스 코드가 먼저 떠오르면 개발자고 토마토 소스처럼 요리용 소스가 생각나면 일반인으로 구분할 수도 있을 것 같습니다.


오픈 소스에 관한 글이 하나 떠서 소개합니다.
http://www.ibm.com/developerworks/kr/opensource/newto/index.html

오픈소스를 가져다가 활용하기 때문에 요즘 프로그래밍 기술에 가속도가 붙어있습니다. 예전처럼 코드를 꽁꽁 숨기려는 노력보다는 바벨탑을 쌓아가듯이 코드를 공유하는 문화가 개발자들 사이에서 유행처럼 번지고 있습니다.

좋은 의도에서 소스를 오픈했는데, 아무리 비용이 들지 않는다 하여도 가져다 쓰는 예의와 법이 있습니다. 그것에 대해서 잘 얘기해주고 있는 글입니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요

첫 장부터 펼쳤습니다. 아직 섹션 하나만 읽은 상태죠. 그런데 왠걸 좋네요. ^^; 브룩스의 Mythical Man-Month 요약도 스토리 중에 잘 되어 있고, 프로그램 용어나 생리를 잘 모르는 사장님 같은 사람들에게 설명하기 쉽도록 표현된 부분도 많군요.

메일링 리스트, 블로그, 버그 관리 소프트웨어, 소스코드 버전 관리 소프트웨어 등 그들이 활용했던 수 많은 도구에도 불구하고 개발자들끼리 커뮤니케이션을 효율적으로 유지하고 필요한 정보를 효과적으로 공유하는 일은 너무나도 어려웠다.
발췌: 드리밍 인 코드, 스콧 로젠버그, P.34

이 책을 다 읽으면 알겠지만 첫 번째 섹션 마지막 표현이 기대하게 만드네요.

케이퍼가 OSAF라는 회사 이름에도 사용한 오픈소스 개발 방법론은 브룩스 이후에 등장한 개념이었다. 그리고 오픈소스 개발 방법론은 브룩스의 패러독스를 극복해줄 가장 그럴듯한 무기처럼 보였다.
발췌: 드리밍 인 코드, 스콧 로젠버그, P.34

데드라인과 같은 소설이 아닌 경험담이라서 더 와닿을 것 같습니다.

^^; 읽을 책 많은데 우선 순위 좀 바꿔야겠습니다. 고 놈 재밌군요.

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 일처리  댓글주소 수정/삭제 댓글쓰기 2009.01.07 23:23

    형님 저도 요즘 그책 읽고 있는데 방법론 나온 부분이 머리에 쏙쏙 들어 오던데요..
    낼 모레 워크샵에서 써먹어야 겠습니다.

  2. bliss  댓글주소 수정/삭제 댓글쓰기 2009.01.08 17:11

    뒤로 갈수록 더욱 흥미진진해질 거라 장담. ^^ 꾸준한(!) 서평 기대할게요. ㅋㅋ

  3. 짱가  댓글주소 수정/삭제 댓글쓰기 2009.01.09 09:30

    이벤트 신청했다가 떨어졌다능...ㅠ.ㅠ..
    그래서 언제 살지 고민하고 있능...ㅠ.ㅠ.

익숙한 툴을 벗어나서 새로운 툴에 적용하는 것은 아주 어려운 일입니다. 윈도우에서 맥으로 스위칭하는 것이 그랬고, 이번엔 이미지 편집기도 고가의 포토샵에서 Gimp로 바꾸는 연습을 하고 있습니다.

작업창의 일부입니다. 오른쪽에 보시면 아시겠지만 레이어 기능이 지원됩니다. psd파일 호환도 되고요.

http://gimp.kr/ 김프코리아는 아직 자주 들어가진 않았습니다. 저처럼 쉽지 않은 길을 선택한 분들인데, 사실 도구는 익숙함의 문제가 아닌가 싶습니다.


Posted by 케누 kenu허광남

댓글을 달아 주세요

  1.  댓글주소 수정/삭제 댓글쓰기 2008.12.19 18:17

    비밀댓글입니다

  2. gildong0  댓글주소 수정/삭제 댓글쓰기 2008.12.21 21:15

    하..저도 포토샵에서 김프로 전향해서 익숙해지려고 노력 중입니다.^^ 근데 쉽진 않네요..ㅎㅎ 거기다 이미지작업은 가뭄에 콩나듯 하는 지라 ...ㅋㅋ 하지만 IE에서 파폭으로 옮길때도 느꼈지만 프로그램은 얼만큼 익숙해지냐와 애증(?)이 있으면 얼마든지 옮길 수 있다고 생각이 듭니다.

  3. 질문  댓글주소 수정/삭제 댓글쓰기 2009.01.08 10:02

    김프 맥용으로 다운받았는데 영문판이더라구요~한글판은 어떻게 받는거죠???

평소에 들여다 보았으면 좋았을텐데 하는 아쉬움이 남습니다. CVS에서 SVN으로 모든 프로젝트가 이전하는 것은 몇 년 전에 알고 있었는데, 오늘 책을 쓰다가 아파치 소프트웨어 재단(Apache Software Foundation)의 저장소를 보고 놀랬습니다. 백 개가 넘는 모든 프로젝트들이 한 저장소에서 관리되고 있습니다. 각 프로젝트별로 trunk, branches, tags 를 각기 관리하고 있습니다.
리비전 번호에 신경을 쓰지 않아도 될 듯 합니다. 숫자는 다르다는 것만 표시하면 될 뿐, 통합 저장소로 인한 리비전 번호의 증가에 괜히 신경쓰지 않아도 될 것입니다.


톰캣 프로젝트 내에도 여러 서브프로젝트들이 존재합니다. 저장소 구성은 다음과 같습니다.

괜히 은근슬쩍 2002년이 떠오르는군요. 자카르타서울 프로젝트. 지금은 동면상태이죠.
http://www.apache-korea.org

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 토비  댓글주소 수정/삭제 댓글쓰기 2008.12.18 14:30

    별로 좋아보이지만은 않습니다. 일단 커뮤니케이션 하기 힘들죠.
    "리비전 넘버 칠십일만팔천오백육십사번을 참조하셈"
    "머.. 칠십...만 오백어쩌고..? 다시 불러주셈"

    좀 지나면 백만 넘어가겠군요. 숨도 같이 넘어가겠습니다. 리비전넘버치다 오타도 많이 나고.. @@

  2. kingori  댓글주소 수정/삭제 댓글쓰기 2008.12.18 15:27

    정말, 번호가 후덜덜하군요!

    그나저나, 저게 정말 좋은 구조인지 아니면 눈물을 머금고 어쩔수없이 선택하다보니 나온 구조인지에 대한 내용을 찾아볼 수 있다면 더 좋겠네요.

고전적인 자바 클래스의 테스트는 main() 메소드에 값을 찍어보는 코드를 넣어서 콘솔에서 확인합니다. 이클립스에 익숙해진 덕에 JUnit에서 System.out.println() 집어 넣는 것은 초딩같은 습관이라고 생각을 "저만"했었습니다. 하지만, 찍어본다는 것 그리고 그것을 눈으로 확인하는 것은 굉장한 심리적 안정감을 주기는 합니다. 아직 assertEquals() 는 보이지 않는 신뢰가 필요하기 때문이죠.

httpunit의 테스트코드를 보니 재밌는 부분이 있었습니다. 상당히 많은 수의 테스트케이스에 main() 메소드가 있었고, 그 메인메소드는 JUnit을 기반으로 해당 테스트코드를 수행하도록 만들어주는 것이었습니다.


suite() 메소드를 inline 리팩토링하면 junit.textui.TestRunner.run( new TestSuite( EncodingTest.class ));  를 통해서 실행을 합니다. Java Application 으로 실행한 결과는 다음과 같습니다.

..............
Time: 3.813

OK (14 tests)

물론 이 클래스는 JUnit을 통해서도 실행됩니다.

다른 사람의 코드를 읽는 것, 프로그래머 소통의 시작이 아닐까 생각해봅니다.

참고로 HttpUnitTest 클래스의 상속구조입니다. ctrl+T 로 이클립스에서 볼 수 있습니다.


 

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. iolo  댓글주소 수정/삭제 댓글쓰기 2008.11.03 22:33

    대부분의 assertXXX 메소드들은 첫번째 파라메터로 메시지를 줄 수 있지 않나요?
    제 경우엔 unit test 안에서만 System.out과 System.err을 쓴답니다^^;

    • 케누 kenu허광남  댓글주소 수정/삭제 2008.11.04 01:55 신고

      메시지가 성격이 다르죠. 보통은 파라미터에 값을 찍어보니까요.
      하긴 실제 코드에서 System.out , System.err 쓰는 것보다는 테스트코드에서 쓰는 게 훨씬 낫죠.

앞서 오픈소스를 통해서 소스 저장소에 등록되는 디렉토리 구조를 살펴보았습니다. 그리고 프로젝트 소스를 일괄처리하는 build.xml 도 살짝 들여다 보았습니다. 이클립스 툴을 쓰면 다 되는 작업을 왜 Ant 빌드스크립트를 만들어야하는지 질문을 종종 들어봤습니다. 지속적인 통합 빌드 같이 주기적으로 반복되는 작업이나 단계가 복잡한 작업들은 빌드스크립트가 효과적입니다. 클릭클릭하는 일도 지겨울 때가 있거든요. 이클립스 작업의 자동화가 빌드 스크립트라고 생각하시면 될 것입니다.

지난 번 소스 가져오기(import) 이후로 소스의 빌드 경로를 잡아보려고 합니다. 로컬pc에서 컴파일되나 안되나 확인하는 것이죠. 소스가 패키지에 맞게 제자리에 있어야 할 것이고, 참조하는 jar파일의 경로도 함께 지정해줘야 합니다.

일단 이클립스 자바 프로젝트에서 소스 폴더를 추가합니다. 자바소스가 있는 폴더를 소스폴더라고 합니다. *.java 파일과 *.properties 파일들이 위치합니다. httpunit-1.7 아래 src 폴더가 바로 소스폴더입니다. 그리고 httpunit-1.7 아래 test 라는 곳도 소스 폴더로 추가합니다. src 아래 있는 클래스들을 테스트하는 테스트케이스들의 소스 폴더입니다.

자동 빌드가 일어나면서 에러가 무진장 일어납니다. jar 파일 연결이 안되서 그렇습니다.

왼쪽 패키지 익스플로러에서 프로젝트를 선택하고 Properties 창을 엽니다. 컨텍스트 메뉴에서 제일 아래 Properties 메뉴를 선택하면 됩니다. 단축키는 alt+Enter
Java Build Path 항목을 선택하고 Libraries 탭을 클릭합니다.

우측의 Add JARs... 버튼을 클릭해서 httpunit-1.7/jars 폴더의 *.jar 파일들을 선택합니다.

오호, 에러가 줄기는 했는데, 하나 남았네요. fnfe를 클릭해서 해당 소스를 열어보겠습니다. 흠, 겁을 상실했군요. 에~ 뭐 꼭 고친다는 뜻은 아닙니다. ^^;

소스를 살짝 보니 캐릭터셋 문제로 Roger Lindsj 이름 옆에 이상한 문자가 생긴 것 같네요. 그것 때문에 아랫줄 if라인이 주석 줄로 따라 올라온 듯 합니다.

if 앞에서 엔터로 줄바꿔주니 고쳐졌습니다. ^^; 잠시 우쭐~

Problems 탭에 에러는 싹 사라졌군요. Warnings는 살짝 봐주기로 하죠. ^^;

소스 폴더가 추가된 모습입니다.

작업공간은 에러 없는 코드로 관리되는 것이 개발자 심리에 좋다고 생각을 합니다. ^^;
Posted by 케누 kenu허광남

댓글을 달아 주세요


앞서 오픈소스인 httpunit을 통해서 프로젝트 소스 구성을 살펴봤습니다. 빌드스크립트인 build.xml를 통해서 프로젝트 소스를 가공하는 방법을 알 수 있습니다. 프로젝트의 작업 지시서와 같은 역할을 하는 것이죠.

이클립스의 아웃라인뷰에 나오는 타겟 목록입니다.
소스를 보면 <project ... default="jar"> 내용을 확인 할 수 있습니다. 기본 프로젝트 타겟은 jar 입니다.

그 외에도 수많은 작업그룹이 보입니다. 각각의 내용을 확인해 봐야 정확한 작업 내용을 알 수 있겠지만 여기서는 jar 를 중심으로 살펴보겠습니다.

<!--  ===================================================================  -->
<!--  Creates the jar archive                                              -->
<!--  ===================================================================  -->
<target name="jar" depends="compile" description="create the jar file">
    <mkdir dir="${lib.dir}" />
    <echo file="${build.dir}/info.txt">Manifest-Version: 1.0
Sealed: false
HttpUnit-Version: ${version}
Build-Date: ${TODAY}
Build-Time: ${TSTAMP}
</echo>
    <jar jarfile="${lib.dir}/${name}.jar" manifest="${build.dir}/info.txt">
        <fileset dir="${build.classes}" includes="com/**"/>
        <fileset dir="META-INF" includes="*.dtd"/>
    </jar>
</target>

주석의 모양도 참고 대상입니다.  타겟의 depends속성을 보면 compile 타겟이 먼저 수행되는 것을 알 수 있습니다. <jar> 태스크를 보면 JAR 파일명이 지정되어 있습니다. 컴파일된 클래스 디렉토리를 기준으로 com 패키지 아래 있는 것이 포함되고, META-INF 디렉토리에 있는 *.dtd 파일들도 jar 파일에 들어갑니다.

compile 타겟을 확인하면 소스의 위치는 확실히 알 수 있겠죠.

<!--  ===================================================================  -->
<!--  Compiles the source code                                             -->
<!--  ===================================================================  -->
<target name="compile-for-java2" depends="prepare,check_for_optional_packages" if="dom3.absent">
    <mkdir dir="${build.classes}" />
    <javac srcdir="src-1.4" destdir="${build.classes}"/>
</target>
<target name="compile" depends="prepare,check_for_optional_packages,compile-for-java2">
    <mkdir dir="${build.classes}" />
    <javac srcdir="${src.dir}" destdir="${build.classes}"
           debug="${debug}" deprecation="${deprecation}" optimize="${optimize}">
        <classpath refid="base.classpath" />
        <exclude name="**/JTidyHTMLParser.java" unless="jtidy.present" />
        <exclude name="**/ScriptFilter.java" unless="nekoHTML.present" />
        <exclude name="**/NekoHTMLParser.java" unless="nekoHTML.present" />
        <exclude name="**/NekoDOMParser.java" unless="nekoHTML.present" />
        <exclude name="**/servletunit/*" unless="jsdk.present" />
        <exclude name="**/JUnitServlet.java" unless="junit.present" />
        <exclude name="**/javascript/*" unless="rhino.present" />
    </javac>
</target>
 
클래스의 빌드 디렉토리를 만든 후에 파일들을 컴파일 합니다. 컴파일 시 관련 jar의 유무에 따라 컴파일에서 제외시키기도 합니다. 여러가지 jar파일들을 사용하는 것을 알 수 있습니다. jtidy, nekoHTML, jsdk, junit, rhino. 대부분 자바스크립트 파서나 실행에 관련된 것들이죠.

httpunit 한 프로젝트에서도 건질 것들이 굉장히 많은 듯 합니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요


오픈소스의 좋은 점 중 하나는 제품 개발과정을 볼 수 있다는 것입니다. 소스 프로젝트의 구성을 볼 수 있고, ant나 maven 등의 빌드 구성과 TestCase를 어떻게 만들었는지 확인이 가능합니다.

httpunit이라는 소스포지의 오픈소스를 통해서 그 구성을 살펴보겠습니다.
http://httpunit.sourceforge.net 에 접속합니다.

왼쪽 메뉴 중 Download를 클릭해서 다운로드 받습니다.

파일을 이클립스에서 import 해보겠습니다. httpunit 이라는 이름으로 자바프로젝트를 하나 만듭니다.

프로젝트를 선택하고 컨텍스트 메뉴에서 Import... 를 선택합니다.

ar 이라고 필터란에 입력하면 Archive File 메뉴가 보입니다.

앞서 다운로드 받은 httpunit-1.7.zip 파일을 선택합니다.

폴더 통째로 import를 해왔습니다.

디렉토리의 구성을 잘 살펴볼 필요가 있습니다.
doc : 아마도 html 이나 프로젝트 관련 문서들 원본 등이 있을 것입니다.
examples : httpunit을 이용하는 예제들 디렉토리
jars : 프로젝트 관련 jar 파일 디렉토리
lib : httpunit.jar 산출물 생성 디렉토리
META-INF : jar 압축시 기본 생성 디렉토리
src : java 소스 디렉토리
test : 테스트케이스 디렉토리
build.xml : 프로젝트 빌드를 위한 ant 빌드 스크립트


이러한 구성을 참고로 자신이 진행하는 프로젝트의 소스 및 파일들을 관리하는 것도 좋을 것입니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 권남  댓글주소 수정/삭제 댓글쓰기 2008.10.26 00:07

    저 같은 경우에는 요즘 Maven을 사용하면서 Maven이 제공하는 기본 디렉토리 구조를 그대로 사용하는 버릇이 생겨버렸네요.
    디렉토리 깊이가 지나치게 깊다는 단점이 있지만, IDE를 사용하면 그 단점이 크게 다가오지는 않기 때문에 뭐 그닥 나쁘지는 않은 것 같습니다.

  2. 나그네  댓글주소 수정/삭제 댓글쓰기 2008.10.27 12:39

    이 포스트가 좋아서 담아갑니다.