vim 에서 외부 명령을 수행해서 그 결과를 새로운 탭으로 열고자 한다. 여기를 참고로 했는데 잘 안된다. :r !ri -f plain Object 하면 현재창에 여는건 된다. 버퍼에 저장하고 탭으로 넘기거나 split 할 수 있음 좋겠는데…낼 해보자 AM 05:20

아직 갈길은 멉니다만… 2달 안에 뭔가 성과를 내야 하기 때문에 열심히 달려 볼 생각입니다. 저의 인생을 구분지을 때, 2008년 이전과 그 이후로 나눌 수 있는 한해가 되도록 노력할 얘정입니다. AM 02:51

그리고 생각보다 디버깅이 힘들수도 있겠다는 생각이 들더군요. 변서 선언 없이 바로 쓰인다는 점이 오타로 인한 오류를 찾기 힘들것도 같아 보입니다. Test를 강조할 수 밖에 없겠더군요. AM 02:48

다국어 지원에 대한 부분은 좀 우울하군요. 기본 객체인 String 이 그렇게 생겨먹어서야… 마츠는 일본인이면서도 왜 그렇게 구현했을까요? 쩝~ 매우 우울한 부분입니다. AM 02:46

그래도 루비라는 언어에 대해서는 깊게는 아니지만 조금은 이해하게 되었습니다. 루비를 널리 전파하기 위한 복음서로 유명한 책이라서 그런지 쉽게 읽을 수 있다는 장점은 있네요. Java 와는 또다른 유연한 객체지향 언어 입니다. 다만… AM 02:45

스크랩이라는 개념만 빼면 딜리셔스랑 똑같군 쩝;; AM 04:27

아니다. 북마크와 스크랩 페이지는 다르다는 생각에서 이 서비스는 출발한다. 북마크된 정보는 휘발성 정보다. 언제 사라질지 모르지. 그런데 오래도록 저장해 둘 정보가 있긴 할까? AM 03:57

딜리셔스와 차이점은 결국 링크를 저장하느냐! 글거서 별도의 파일로 저장하느냐 인건가? 웹상에 존재하는 자료를 구지 별도의 공간에 복사해서 담아둘 필요가 있느냐가 문제군 AM 03:55

이게 딜리셔슨가?-,- AM 03:50

이걸 웹서비스로 제공하면 어떨까? 현재 다모아는 스크랩한 페이지를 자신의 티스토리 블로그에 등록시켜주는 기능이 있다. 아마 다른 툴들도 지원할듯… 블로그 등록이 아니라 스크랩한 페이지를 서버에 저장시켜 주고 관리하기 편하게 해주는 웹서비스. AM 03:50

그래서! 웹페이지 스크랩을 도와주는 툴이 없는지 찾아 보았다. 물론 있다. 아래 적었든 다나와 라는 국산 툴이 있고, Mac 에선 오래전부터 DEAVONThink 같은 killer app 이 있었고, 파이어폭스 플러그인도 찾았다. AM 03:46

1. 몇년동안 쌓인 북마크로 인해 관리가 안된다-,-; 2. 해당 페이지가 언제까지 존재할지는 아무도 모른다. (2-3년 이내에는 반드시 사라진다.) AM 03:44

RSS 는 해당 사이트에 대한 UPDATE 정보로 인해 계속 변하기 때문에 해당 페이지에 대한 링크는 북마크를 사용해야 할 것이다. 하지만… 북마크 사용은 관리상에 매우 큰 문제점이 있다. AM 03:43

웹서핑 도중에 좋은 글이나 정보를 발견하면 1. RSS 를 제공하면 구독, 2. RSS 없다면 북마크를 건다. AM 03:42

미투에 적기에는 여러가지로 부적절한 글쓰기였습니다. 머;; 수정도 안되고, 글도 역순으로 달리고,,, 이럴거면 블로그에다 쓰던가 하지 말이죠… AM 02:01

사실 제가 쓰고 싶은 주제 몇가지가 다 이런 겁니다. ORM, Framework, Eclipse, 분산환경… 이딴거 재수없다고 쓰고 싶습니다. 그것도 매우 설득력 넘치게 말이죠… 쓰는건 어렵지 않을것 같은데 호소력이 있기는 쉽지 않아 보입니다. AM 01:57

front-end 가 X-Internet 기반이라 가능한 구조인지도 모르겠습니다. 그러나… 현재로서 제가 생각하는 가장 실용주의적인(요즘 유행어) 구조라고 생각합니다. 머;; 저는 그렇다고요 AM 01:54

config? 필요없습니다. URI가 말해줍니다. controller? JSP에서 transaction 관리 합니다. query XML은 필요하죠. AM 01:52

작년에 구축했던 사이트에선 이렇게 했습니다. Action JSP -> DAO -> XML AM 01:51

거기다 사이사이 들어가는 Interface 까지 하면 기능 하나 추가 하는데 필요한 파일이 6개가 넘어갑니다. 물론 이 예는 현재 진행중인 프로젝트 기준입니다. 최소한으로 줄인 겁니다. DTO 같은거 포함되면 더 늘죠. 더 줄이지는 못했습니다. framework 덕에 AM 01:50

사실 오늘 글의 요점은 하나입니다. Web Application 프로젝트에 있어서 너무 OO적인 개념으로의 접근방식의 overhead가 이제 다들 보이지 않나 하는 거지요. ActionServlet Controller DAO query XML config XML AM 01:48

그루핑의 단위를 너무 작게 잡으면 파일의 갯수가 엄청나게 늘어 납니다. 이게 생각보다 overhead가 상당합니다. 그렇다고 너무 넓게 잡으면 관리가 쉽지 않아요. conflict 도 무시 못하구요. AM 01:45

예 2) DAO :: 전에는 테이블 단위로 생성했었습니다. 그러나 형상관리시 conflict 가 너무 자주 납니다. 이젠 화면 단위 또는 서브시스템 단위로 DAO를 묶습니다. 명확한 rule을 정하기는 사실 쉽지 않습니다. AM 01:43

struts 이후에 변해버렸죠. 이제 화면 단위로 쪼갠 서블릿 보기 힘듭니다. 기능 단위로 세분화 되었죠. 그러나 어쩌면 다시 예전처럼 돌아갈지도 모르겠다는 생각이 듭니다. 유행은 다시 돌아오니까요. AM 01:38

예 1) Action Servlet :: 전에는 하나의 서블릿에서 파라미터에 의해서 분기를 해서 처리했었습니다. 당시 그루핑의 단위는 화면 단위였습니다. 조회/수정/삭제 등을 하나의 서블릿에서 분기해서 처리했죠. AM 01:15

상태를 지닐만한 아이들이 거의 없습니다. 어찌보면 Web Application 에서의 객체란 단순히 비슷한 일을 하는 메소드 들의 묶음. 관리의 편의를 위한 그루핑의 단위로 볼 수 있을것 같습니다. AM 01:13