새벽 5시반에 LA공항으로 출발했습니다. 마이애미까지 4시간 반 비행하는데, 중간에 응급환자가 생겨서 아리조나에 긴급착륙을 해서 한시간 정도 딜레이 되었습니다.

5시에 등록 시작인데 마이애미(울엄니) 공항에서 택시를 탄 시간이 5시였습니다. 30분정도 걸려서 Westin Diplomat 호텔에 도착했는데, 별 4개 호텔이라던데 제가 다녀봤던 곳 중에 최고입니다.


사진이 80장 정도 되는데 일단 피카사에 올렸습니다. ^^; 1기가까지 무료지원하는군요.

아직도 제 영어는 많이 부족함을 느낍니다. ^^;

로드존슨의 키노트의 핵심은 다음그림과 같습니다. 복잡함과의 전쟁! 스파게티의 바다, 에러의 강, 버그 만, 크래쉬 캐년, 코드의 산 등등입니다. 

ㅎㅎ; 컨퍼런스 참여해 보신 분들은 아시겠지만, 후기 쉽지 않습니다. 
사진으로 땜빵합니다.
  1. Max 2008.12.02 22:19

    사진으로 대리만족 하였습니다. ㅎ;;
    사진 중간에 동영상의 '아~하' 하는 소리가 미국에서만 나오는 감탄사인가봐요? ^^;;
    재밌게 잘봤습니다. :)

  2. naong 2008.12.03 09:41

    복잡함과의 전쟁! 스파게티의 바다, 에러의 강, 버그 만, 크래쉬 캐년, 코드의 산
    너무 재밌네요 . ^^

Controller 와 Service의 차이점
레이어를 나누는 것은, 아, 티어(tier)라고도 합니다. ^^; 나누는 기준은 뭘까요. 그냥 나누는 사람도 많습니다. 레거시 코드들이 증인석에 출두할 수도 있으니까요.

2006년 스프링으로 프로젝트를 하면서 그 때는 이 고민을 하지 못했습니다. 납기일 내에 동작하는 프로그램을 만들어 내야 하니까요. 플젝이 끝나고 그것을 기반으로 확장하는 프로젝트가 많이 열렸습니다.
^^; 슬프게도 사람이 많이 바뀌었습니다. 히스토리를 알고 얘기해 줄 사람도 n모사 s모사로 가버린 다음이죠.

다행히 코드 리뷰라는 것을 새로운 플젝의 외주 사람들과 매일 규칙적으로 한시간 정도 안되게 하는데, 나온 질문입니다.

얘기가 긴 데요. It's a long story.

핵심은 request, response 같은 WAS 디펜던트 한 것을 서비스에서 처리하게 하면 안됩니다. 서비스는 WAS없이도 돌아간다라고 생각하고 짜야된다가 현재의 결론입니다.
^^;

  1. 토비 2008.07.15 17:39

    Servier는 DB가 없이도 돌아갈 수 있어야 되기도 하죠.

  2. 알 수 없는 사용자 2008.07.15 17:55

    그런 생각으로 서비스 레이어를 많이 만들기도 했는데 짜친 녀석 가지고 그러기도 뭐 해서 콘트롤러가 일 하게도 만들어봤어요. ㅋㅎ

  3. 해피씨커 2008.07.15 18:26

    최근 생각하는 건.
    Action <-> Service <-> Dao 구조에서
    Action <-> Service 에서 주고 받는 객체랑
    Service <-> Dao 에서 주고 받는 객체는
    형태가 같더라도 따로 정의해 주는 것에 더 관리적 측면에서 좋다.
    머 이 이야기는 따로 정리 해야 할듯.

  4. 2008.07.19 20:44

    첨에는 그렇게 생각하다가 나중엔 뒤죽박죽이 되어버려요..ㅜㅜ

    • kenu허광남 2008.07.21 02:51 신고

      끝까지 포기하지 않고 계속 다듬어갈 필요가 있다고 생각합니다.

  5. ologist 2008.07.20 21:57

    모델의 경게에 대한 문제는 항상 설계시 고민이 되는 문제죠,.

    헷갈린 상황에서는 객체가 가능한 좁은 범위에서 의미를 갖게 하는 것이 판단의 기준이 될거 같네요.

신기술들이 마구마구 쏟아져 나옵니다. 개발자로 살아간다는 것, 아니 컴퓨터를 이용해서 생계를 이어가는 것 자체가 매우 피곤한 일입니다. 6개월 지나면 2배 빠른 컴퓨터를 반값에 산다는 무어의 법칙 때문이기도 하고, 유토피아를 만들만한 컴퓨터 언어나 소프트웨어의 완전판이 아직 없기 때문이죠.

현재의 컴퓨터 업계를 이끌어 가는 기술과 기술 커뮤니티들을 보면 한 가지 공통점이 있습니다. 기술의 대표가 있기 때문이죠. 컴퓨터 웹 업계에서 몇 년의 경험이 있다면 다음 기술을 얘기할 때 떠오르는 사람이 있을 것입니다.

  • ASP
  • zeroboard
  • phpschool
  • Devpia
  • kldp/linux
  • javastudy
  • javaservice
  • struts
  • spring
  • agile/xp
전 빠져도 되겠죠. ^^;
제 생각과 같은 지 확인해 보시죠.

  • ASP ( taeyo 김태영 )
  • zeroboard ( nzeo 고영수 )
  • phpschool ( 정진호 )
  • Devpia ( 최우인 )
  • kldp ( 권순선 )
  • javastudy ( 조대협 )
  • javaservice ( 이원영 )
  • struts ( 박재성 )
  • spring ( 박재성, 이일민, 안영회, 백기선 )
  • agile/xp ( 김창준 )
  • python ( perky 장혜식 )
  • MINA ( 이희승 )
뭐, 이의를 제기하시거나 추가를 원하시면 말씀해주세요. 제 경험상 주관적인 것이니까요.

인간 본성에 미래에 대한 불확실성이 있기 때문에 누군가 선례가 될 만한 존재를 발견하게 되면 조금이나마 안심하고 따라갈 수 있습니다. 위에 열거한 분들의 공통점은 상당히 오랜 기간 기술의 장을 만들고 다듬고 사람들과 교류하고 했던 분들입니다. 두 글자로 줄이면 "열정"이라고 할 수 있죠.

새로운 기술을 사람들이 환영하는 이유는 새롭기 때문입니다. 하지만 이 기술들이 오래가기 위해서는 스타 플레이어가 필요합니다. 반짝 스타가 있을 수 있지만, 그보다 더 중요한 것은 얼마나 기술이라는 플랫폼 위에서 오랫동안 사람들에게 존재감이 있을 수 있느냐 입니다.

3년만 버티면 동종 기술의 사람들에게 인정을 받기 시작합니다. 5년을 버티면 전문가 소리를 듣기 시작합니다. 10년을 버티면 전설이 되어버립니다. 수많은 추종자들을 이끌고 말이죠.

요약하면 이렇습니다.
커뮤니티? "일단 시작했으면 버텨라" 입니다.

  1. 산티아고 2008.07.08 09:15

    제 분야인 BizTalk도 이제 막 커뮤니티가 생기려는 참인데.. 참 도움되는 말씀입니다. "일단 시작했으면 버텨라", 문제는 스타플레이어로군요.

  2. 참◈서빈 2008.07.09 09:55

    스타플레이어는 혼자 하는게 아닙니다.
    누군가의 도움이 필요하지요.
    다른사람의 생각과 말을 듣고 변화에 익숙한 사람은 성공한다고 생각합니다.

  3. 해리 2008.07.09 10:55

    Ruby on rails (황태산) 이렇게 떠오르네요.

  4. 마검린 2008.07.09 17:06

    정말 동감입니다. 기술은 스타플레이어가 필요한 것 같아욧..

    특히나 "3년만 버티면 동종 기술의 사람들에게 인정을 받기 시작합니다. 5년을 버티면 전문가 소리를 듣기 시작합니다. 10년을 버티면 전설이 되어버립니다. 수많은 추종자들을 이끌고 말이죠."

    이 글이 가슴에 와 닿네욧.. 감사합니다.

  5. nona* 2008.07.10 00:23

    okjsp를 빼먹으셨네요. :)

  6. 권남 2008.07.10 21:45

    Ruby : deepblue(강문식)님요~

+ Recent posts