달력

12022  이전 다음

  •  
  •  
  •  
  •  
  •  
  •  
  • 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
  • 31
  •  
  •  
  •  
  •  
  •  
JSP tag file은 jsp spec 2.0부터 소개된 기술이죠. JSP로 서블릿을 자동생성하듯이 태그 파일로 커스텀 태그를 자동 생성해서 쓰게 됩니다.
이런 태그 파일을 이용해서 반복적으로 사용되는 Ajax함수를 자동 생성하고, 쉽게 사용할 수 있도록 설명한 글을 소개합니다.
http://www.ibm.com/developerworks/kr/library/wa-aj-simplejava1/
Posted by kenu허광남

댓글을 달아 주세요

지난 번에도 언급했던 eBay 개발팀의 이클립스 플러그인 적용에 대한 후속글이 떴습니다.
http://www.ibm.com/developerworks/kr/library/os-eclipse-ebay2/index.html?ca=drs-kr

Megajars 라는 개념은 공감이 많이 갑니다.

소스 파일 수십만 개를 이클립스에서 실행해 본 적이 있는가? 실행하면, 시스템에 엄청난 부담을 주고, 많은 메모리를 필요로 해(이클립스에서 out of memory 예외를 받아 본 적이 있는가?), 시스템이 극단적으로 느려지는 원인이 된다. 이런 경우 시스템에서 실제 소스 코드를 받아 오는 대신 컴파일된 코드로 연결하는 것이 더 좋은 방법이 된다.

from: http://www.ibm.com/developerworks/kr/library/os-eclipse-ebay2/index.html?ca=drs-kr#N100F2

플러그인 만들기 어렵지 않다던데, 어서어서 실험해봐야겠습니다.
쩝.
Posted by kenu허광남

댓글을 달아 주세요

http://www.ibm.com/developerworks/kr/library/os-eclipse-ganymede/index.html?ca=drs-kr
사실 쓰는 것만 씁니다. 그래서 가니메데를 통해서 동시에 배포된 24개의 프로젝트 중에서 아는 것은 몇 개 안 됩니다.
하지만 dW에 소개된 글을 통해서 그 얄팍한 지식을 좀 더 두껍게 만들 수 있습니다.

책을 읽는 경우가 있고, 책의 목차만 보는 경우도 있고, 책의 요약본만 보는 경우도 있습니다.
세 가지 경우 중에서 시간 대비 효과가 가장 큰 것이 마지막 요약본을 보는 경우인데요. 이클립스의 24가지 프로젝트를 정독하기는 힘든 상황에서 요약본은 거의 대학교 시험 앞서서 족보를 보는 것과 같은 효율성을 지니고 있습니다.

하긴 답답함은 해소하겠지만, 어디서 아는 척은 삼가는 것이 좋겠죠. 경험이 없는 지식은 선무당과 같으니까요.
Posted by kenu허광남

댓글을 달아 주세요

  1. nona*  댓글주소 수정/삭제 댓글쓰기 2008.07.10 00:19

    좋은 정보 고맙습니다.
    아직 가니메데에 발맞춰 플러그인들이 버전업하지 않은것 같아 살짝 아쉬움이 남습니다.

    일반적인 자바 웹 프로젝트시에는 이클립스 기본에 wtp만 얹어서 사용하면 가벼이 사용할수 있지 않을까 생각해 봅니다. 한번 시도해 봐야겠습니다.
    늘 툴의 기능은 방대한데 사용하는건 한정되어 있으니까요...

    제일 마음에 드는건 한글 입력입니다. ^^)b

vi, 어렵지 않아요.

java/jsp 2008. 6. 27. 07:18

오래된 에디터 중에 MS-DOS시절의 edit로 불러낸 텍스트 편집기가 있습니다.

사용자 삽입 이미지


마우스가 일반에게 선보이기 직전의 편집기로 기억을 하는데, 윈도우가 나온 후 메모장(notepad)에 자리를 빼았기게 되었죠. 아직도 윈도우XP에서 edit 명령으로 위 화면을 볼 수 있습니다.

리눅스/유닉스에서는 vi와 emacs가 가장 많이 쓰이는 에디터일 것입니다. 물론 pico라는 에디터도 있습니다. vi는 vim으로 확장판이 나오기도 했지요. 윈도우버전도 지원합니다.
http://www.vim.org/

디벨로퍼웍스에 vi에 관한 좋은 컨닝페이퍼가 있습니다.

물론 저는 vi에서 꼭 익혀야 할 필수기능만 주로 쓰고 있습니다.
hjkl ; 좌하상우
:1 ; 문서 맨 처음
:$ ; 문서 맨 끝
:숫자 ; 라인번호로 이동
/패턴 ; 패턴 이동
^b, ^f ; 페이지 back, forward

x ; 삭제
i ; 삽입

^^; TV리모콘 기능보다 많군요. 전원on/off, 채널up/down, 볼륨up/down만 알면 TV를 볼 수 있는데 말이죠.
역시 편집은 어려운 것 같습니다. 편집기를 다른 것으로 갈아타는 것도 따라서 쉬운 일은 아니겠죠.

아마도 자꾸 쓰면 늘겠죠.

related: http://www.ibm.com/developerworks/kr/library/tutorial/l-vi/


Posted by kenu허광남

댓글을 달아 주세요

  1. 구차니  댓글주소 수정/삭제 댓글쓰기 2008.06.27 09:52

    얼마전에 리눅스 설치 하면서 천리안 시절 메일 보낼때 pico로 작성하던게 편해서 vi 대신
    pico를 설치 하려니 패키지에 존재를 하지 않더라구요. 그래서 찾아 봤더니 pico에서 nano로 업그레이드가 되었더라구요 OTL

    그러고 보니 추억의 edit 화면을 다시 보게 되네요 ㅎ
    한번 실행해봤더니 예전 도스 시절로 돌아간듯한 느낌이 마구 드네요

  2. exedra  댓글주소 수정/삭제 댓글쓰기 2008.06.27 11:31

    문서 맨 처음과 맨 끝으로 이동하는 경우에는 다음 키 명령을 추천합니다.

    gg 문서 맨 처음
    G(shift+g) 문서 맨 끝

    hjkl처럼 그냥 이동 명령어입니다.
    그리고 vi cheat sheet라는 한장짜리 pdf문서도 있어요~

    http://oosoom.org/67

    도움이 되셨길 바랍니다.^^

  3. 용용  댓글주소 수정/삭제 댓글쓰기 2008.06.27 11:40

    ms-dos에서는
    간단한 파일 제작은
    >copy con 파일이름
    입력후 빠져나가는것은 CTRL-Z
    파일 확인은 >type 파일이름
    vi같은 편집기는 edlin 으로 할수있죠.
    edit편집기는 좀 무거워서 잘 안쓰더군요.

http://www.ibm.com/developerworks/kr/library/os-eclipse-plugindev1/index.html?ca=drs-kr

소프트웨어 엔지니어를 들어보셨나요? ^^; 제가 가장 좋아하는 직업 중에 하나입니다. 개발자도 아니고 기획자도 아니고, 그렇다고 디자이너도 아니죠. 이 셋을 포괄한 명칭이 소프트웨어 엔지니어입니다. 무슨 일을 하는지는 아시겠죠. 서비스를 만들어가는 직업입니다.

Chris Aniszczyk, 소프트웨어 엔지니어, IBM에 의해서 쓰여진 기사입니다. OSGi라고 떠드는 기술을 사용하는데, Pervasive라는 단어와 연관이 있다는 정도만 저도 알고 있습니다. jar hell(jar 지옥)을 벗어나기 위한 기술이라고 들었는데, eclipse에 밀접하게 적용된 것입니다.

단순 유저에서 벗어나서 하드코어 유저로 올라서는 방법 중 하나가 플러그인 개발이겠죠. ^^; 자동차 운전과 정비에 빗대어 생각해 볼 수 있을 것입니다.
Posted by kenu허광남

댓글을 달아 주세요

온실에서 키운 화초는 약하다고 합니다. 프로그램 개발환경 중에서 가장 온실같다고 할까요, 그런 게 있습니다. 바로 브라우저의 HTML 렌더러입니다. 가장 마음이 넓은 실행기라서 마크업이 깨져도 알아서 대체로 잘 보여주는 편입니다.

때문에 웹 개발자들은 프로그래머 취급도 못받고 허드렛일꾼으로 대하던 시절이 있었습니다.
하지만 그런 유약한 개발습관에서 벗어나 조금 깐깐해질 필요가 있는 것 같습니다.
자바원의 북스토어에서 본 책 중 인상적인 것 하나가 Refactoring HTML이었습니다.

IBM DW에도 비슷한 류의 글이 올라왔군요.

유효성 검사는 여러분의 페이지에 "예측 가능한"이라는 도장을 찍는 방법이다. 태그를 적절히 사용하면, 페이지는 구조적으로 건전하며, 사용과 탐색도 쉽다.

from: http://www.ibm.com/developerworks/kr/library/wa-inherit1/

프로그래머들의 애매한 결과에 대한 삽질은 누구나 겪는 일이지만 HTML 개발자들이 가장 심하다고 말하면 지나친 생각일까요?

유지보수하는 입장에서 HTML을 다루는 자세와 기법에 대해서 도움이 되는 내용이었습니다.

좋아하는 기획자 중 한 부류는 기획서가 깐깐해서 처음에 답답해 보이지만 프로젝트 후반에 말바꾸지 않고 신뢰감있게 독려하는 분들입니다. 웹개발도 깐깐하게 바꿔보는 것이 어떨까요.
Posted by kenu허광남

댓글을 달아 주세요

  1. 쇼팬하워  댓글주소 수정/삭제 댓글쓰기 2008.05.31 23:34

    웹 개발자들은 프로그래머 취급도 못받고 허드렛일꾼으로 대하던 시절이 있었습니다.
    -->이말 공감합니다.
    저도..그렇게 생각햇으니깐여..ㅠ

밴드와 프로그래머

java 2008. 5. 31. 21:39
재즈를 좋아하는 사람들이 있습니다. 오케스트라나 클래식한 음악들과 달리 굉장히 맛깔나는 자유스러움 때문이죠.
재즈를 하는 사람들의 그룹은 보통 밴드라고 합니다. 각자의 애드립과 기교를 갖고 연주를 하지만 전체 하모니는 깨뜨리지 않습니다.
jazz 라는 이름으로 IBM Rational에서 미는 것이 있습니다.
관련 URL :
http://jazz.net
http://www.jazzlab.net
http://jazz.pe.kr

협업 통합 솔루션이라고 할 수 있는데, 여기의 수장이 디자인 패턴 저자 4사람 중 한 사람입니다. Kenu Kent Beck과 함께 JUnit도 만들었습니다. Eclipse 개발에서 리딩을 하고 계신 분입니다. 바로 에릭 감마(Erich Gamma)라는 이름을 가지신 분이죠.
아래 링크를 따라 가시면 에릭 아저씨의 한국 개발자들을 위한 인사말을 들으실 수 있습니다.
http://www.ibm.com/developerworks/kr/event/erich_gamma/

개발에서 튀지 않는 법, 잘 아시는 분은 공유부탁합니다. 묻어가는 법 말고요, 다른 사람들을 잘 이끌어서 모두 같은 방향으로 튀는 법 말이죠.
좋은 연주처럼 좋은 소프트웨어 개발을 위해서 하모니를 맞추는 비법이 급 땡깁니다.
Posted by kenu허광남

댓글을 달아 주세요

  1. sloth  댓글주소 수정/삭제 댓글쓰기 2008.05.31 23:09

    소프트웨어 플젝의 하모니를 맞추는 법은 잘 모르지만요,, 음악에 대해서는 할말이 좀 있어서요^^

    멋진 하모니를 들려주는 밴드의 일원이되려면은.. 연주를 잘 하는것도 중요하지만 "잘 들을줄 알아야" 합니다
    다른 연주자들의 연주를 들을줄알아야하며 자신의 연주또한 들을수 있어야하구... 냉정하게 평가할수 있어야합니다. 자기가 부족하면 분하게 생각하구, 자신의 수준을끌어올릴 '건강한 자존심'도 꼭 필요합니다.

    밴드 음악의 색깔을 결정해줄 리더또는 에이스가 꼭 있어야 합니다.

    좋은 연주와 구린연주를 구별할수 있는 안목이있어야만 합니다.
    자기의 포지션이 아닌 것의 연주를 들을때도 이런 안목이 있어야하며, -예를들어, 건반 주자도 훌륭한 드럼연주를 알아보줄 알아야합니다 - 그리해서 좋은 동료를 고를수있는 안목이 있어야만합니다

    좋은 음악을 들려주는 밴드를 찾기가 힘든이유중 하나죠^^;;

    결론은.. '혼자서는 안되니 동료를 잘 만나야 된다'.. 는 게 되겠군요;

    또, 본인이 좋은 동료가 될 준비가 되있어야 하구요

    • kenu허광남  댓글주소 수정/삭제 2008.05.31 23:21 신고

      넙죽(__)
      정말 좋은 댓글 감사합니다.
      들을 수 있는 귀와 리더의 선택.
      프로그램 프로젝트도 같은 맥락이라고 적극 주장합니다.
      건강한 자존심도 마찬가지로 좋은 말씀이네요.
      ^^b 최고이십니다.

  2. sloth  댓글주소 수정/삭제 댓글쓰기 2008.05.31 23:10

    동문서답 죄송합니다^^,,;

  3. Kenny  댓글주소 수정/삭제 댓글쓰기 2008.06.01 17:56

    Kenu Beck 멋져요. ㅎㅎ

"규모가 크고, 불규칙하게 구성된 웹 사이트는
사이트에 있는 모든 이미지를 관리하는 것처럼 사소하게 보이는 것도
완전히 복잡하게 될 수 있다."
from: eBay의 이클립스, Part 1

작은 사이트를 운영하는 일도 시간이 흐르면 복잡해집니다. 하물며 웹에서 비즈니스를 벌이는 사이트의 복잡도는 얼마나 크겠습니까. eBay와 유사업종인 인터넷쇼핑몰에서 근무하는 저도 비슷한 문제로 골머리를 앓고 있습니다. 저희 팀원들도 마찬가지입니다.

이클립스의 IDE 기능과 플러그인을 직접 만들어서 업무에 적용하는 방법은 꼭 배워보고 싶습니다. 국내에도 그렇게 하시는 개발자들이 있으리라 생각되는데, 이렇게 공유하는 글이 나왔다는 것은 아주 감사한 일입니다.

related:
http://www.ibm.com/developerworks/kr/library/os-eclipse-ebay1/index.html?ca=drs-kr
 
Posted by kenu허광남

댓글을 달아 주세요

Grails에도 ORM이 있군요. Object-Relational Mapping은 프로그래밍에서 자동화의 한축을 그은 기법입니다. 위키피디어의 정의를 참고하세요.

프로그래밍하면서 잡스러운 일들을 자동화시키려고 많은 프레임워크들과 라이브러리들이 나왔습니다. 그리고 CoC(Convention over Configuration)같은 개념들도 귀차니즘을 기반해서 나온 것들이죠. 똑똑한 프로그래머들은 자동화할 포인트를 찾으면 가차 없이 나옵니다.

GORM은 하이버네이트를 그루비(Groovy)로 살짝 덧씌운 것이다("Gibernate"가 "GORM"보다 발음하기가 어려워 쓰이지 않는 것으로 추측한다).
from:
dw: GORM: 재미있는 이름, 진지한 기술 (한글)

가이버네이트보다는 GORM이라는 이름이 더 낫다고 합니다. (맥가이버가 생각나는 저는 ^^;)


공부거리가 자꾸 생겨서 심통이 납니다. 언제 활용하라구요. ^^;
일상이 무료한 개발자는 따라가보셔도 좋을 듯 합니다.
http://www.ibm.com/developerworks/kr/library/j-grails02128/index.html?ca=drs-kr
Posted by kenu허광남

댓글을 달아 주세요

BDD는 또 뭐야

낙서장 2008. 3. 31. 19:41
자바를 좀 한다고 하는 사람들은 TDD를 들어봤을 것입니다. Test Driven Development, 즉 테스트로 주도하는 개발 방법입니다. 2003년인가 http://xper.org 에서 김창준님이 주최하는 XP 그 세번째 이야기 라고 기억되는 연극형 세미나에서 감명을 받은 이후로 계속해서 시도하고 있는 개발방법입니다. 6년째이지만 아직 잘 못하는 방법이기도 합니다.

방법이 기괴한데 먼저 테스트 코드를 짭니다. 테스트의 대상이 되는 코드를 짜기 전에 말이죠. 그래서 이런 형태가 됩니다.
assertEquals( 2, add(1, 1) );


1과 1을 인수로 하는 add() 메소드의 결과는 2와 같아야 된다는 뜻인데, 아직 add() 메소드가 만들어지지 않았지만 이렇게 먼저 선언, 또는 정의합니다. add() 메소드의 결과 동작을 먼저 만드는 것이죠. 에러 납니다. 컴파일도 안됩니다. 아직 없으니까요.

그 다음 동작은 add() 라는 메소드를 만드는 것입니다. 그럼 저 테스트 코드로 add() 메소드의 결과를 확인해 볼 수 있겠죠. 이렇게 개발을 하니 모든 메소드는 자동으로 실행할 수 있는 테스트 코드들을 갖고 있게 됩니다. 이게 모이게 되면 전체 애플리케이션을 테스트할 수 있는 집합체가 구성되는 것이죠.

그런데 이런 방식에는 테스트라는 단어의 레거시가 너무 강했습니다. 일반적인 상식에서는 테스트라 함은 후에 위치한다는 것이 자연스럽기 때문입니다.

사용자 삽입 이미지

그래서 나온 것이 Behavior Driven Development(행위 주도 개발 BDD) 입니다. 자바에서는 JBehave 라는 xUnit과 비슷한 개념으로 나온 것이 있습니다. 이에 관한 developerWorks의 기사를 추천합니다. 사실 저도 Kenny군에게서 일,이 년 전부터 계속 듣기는 했는데, 솔직히 말장난한다는 느낌이 들어서 안 했거든요.

TDD를 하지 않는 이유 중 가장 흔한 것이 "테스팅할 시간이 없어요"와 "테스트하기에 너무 복잡하고 힘든 코드"라는 것이다. 테스트 우선 프로그래밍의 또 다른 장애물은 테스트 우선이라는 개념 그 자체다. 우리 대부분은 테스팅을 감촉적(tactile) 행위, 추상적이기보다는 구체적인 행위로 본다. 우리는 경험적으로 존재하지 않는 어떤 것을 테스트하는 것이 가능하지 않다고 생각한다. 이 개념적인 프레임이 머릿속에 이미 자리잡은 일부 개발자들에게는 '테스트 우선(testing first)'이라는 아이디어가 바보 같은 일로 여겨진다.

그러나 테스트를 작성하고 어떻게 테스트할 것인가 하는 관점이 아닌, 행위(behavior)에 대해 생각해 본다면 어떨까? 여기서 말하는 행위란 애플리케이션이 어떻게 동작'해야' 하는가, 즉 본질적으로 그것의 명세를 말하는 것이다.


국내에도 IDD라 하여 Intention Driven Development를 얘기합니다만 가장 빨리 만들어 내는 방법이라 하여 얘기한다면 BDD와 다르다고 할 수 밖에 없을 듯 합니다. TDD나 BDD의 장점은 Test Harness를 마련해서 기능 추가나 변경에 따른 영향도 감지가 부수적으로 오게 되는 것인데, 그것을 얘기하지 않는다면 유지보수하는 사람들의 고통이 필요하기 때문이죠.
Posted by kenu허광남

댓글을 달아 주세요

  1. Bebop  댓글주소 수정/삭제 댓글쓰기 2008.04.01 01:09

    예전에 TDD가 뭔가 뒤적일때 재밌게 봤었는데...
    새로운 개념들이 나오는군요..BDD, IDD (--;)

  2. 김민수  댓글주소 수정/삭제 댓글쓰기 2008.04.01 03:30

    근데 이런식이면 알파벳순으로 다 될듯합니다.

    ADD 아다다
    BDD
    ...
    TDD
    IDD
    ...
    ZDD

    사실 실제 개발이 아닌 마케팅측면에서 시장(도서출판, 관련개발툴, 고객설득..)을 설득하기 위해 계속 나오는거 같다는 생각이..