Team G.HARD :: cult of hard-corder

* MVC
 : MFC 프로그래밍을 해봤으면 많이 들어봤겠지만, 일반적으로 어플리케이션은 3 layer로 나누어서 프로그래밍한다. 웹 어플리케이션 역시 구조가 나누어진다.
  Layer를 나누어 프로그래밍하면 솔직히 더 많은 클래스, 인터페이스가 생기고 복잡한 메소드들도 추가되는데 왜 이렇게 나누려고 하는가?라고 의문이 들것이다.
  나 역시 그런 의문이 들었었고, 서비스를 하나씩 개발하면서 알게되었다. 이렇게 명시적으로 나누어 둠으로서 각 Layer간의 결합도를 낮출 수 있으며, 무엇보다 고객의 요구사항으로 인해 한 Layer에서 변경사항이 생기더라도 그 여파가 다른 Layer에게 많이 미치지 않게할 수 있다(ripple effect). 이론상으로 OOP 관점에서 잘 만들어진 Object들끼리의 결합일 경우에는 말이다. (자자... OOP 프로그래머가 할꺼라면 디자인 패턴을 공부해보자.)

* Model
 : 모델 객체. 보통 DB의 특정 테이블을 읽어와서 매핑한다. 자바의 모델 객체는 setter/getter 메소드와 property의 field로 이루어져 있다. 데이터를 담는 것외의 역할은 하지 않는다.

* View
 : 웹 어플리케이션에서는 Servlet 클래스를 View단이라고 한다. 혹 front end라고도 한다. 사용자에게 데이터를 보여주거나, 데이터를 입력받는 역할을 한다.

* Controller
 : Business Logic, 데이터로 수많은 operation을 처리하고 View로 데이터로 넘기거나 Model을 가지고 DB에 저장하는 역할의 Layer이다.

다음에는 실제적으로 자바 웹 어플리케이션에서 MVC 각 Layer에서 사용하는 Open Source Frame work에 대해 간략하게 알아보겠다.
Posted by xHuro
teQnical/Java dev. l 2007. 1. 13. 20:58
oveRock군의 이상 야릇한 실험과 달리, 난 아주 기본적인 웹 어플리케이션에 대해 논해보고자 한다. 취업하고 소프트웨어 공학이라던가 어플리케이션의 개념없이 투입되어 아직도 고전을 면치 못하고 있다. (사실 취업전에는 임베디드에 거의 목숨을 걸었다.)

현재 내가 있는 회사는 자바(JAVA)가 주 프로그램 랭귀지에다가, 웹 어플리케이션을 만들기 때문에 기본 지식없이 무작정 프로그래밍했다간 낭패를 당할 때가 있다.

혹시나 웹 쪽에 관심이 있거나 진출하려는 사람들을 위해 아주 간단히 자바 웹 어플리케이션이 어떤 구조를 가지는가 앞으로 설명해보겠다. (웹 어플리케이션 뿐만 아니라 대부분의 어플리케이션들은 이런 구조를 가질 것이다.)

여유가 더 있다면, 오늘부터(!) 공부하고 있는 Java Virtual Machine에 대해서도 써볼까 계획이다. (oveRock군... 프로젝트는 Ruby로 할까? ㅡㅡ)


내 블로그에 있던, 작년 여름때 어플리케이션의 구조다. 잘 안보이는 건 일부러 그렇게 했다. (기밀? 이니..)

Posted by xHuro
teQnical/Java dev. l 2007. 1. 11. 21:24

방금 전 팀 블로그에 새로운 기능을 하나 추가했다.
그게 뭐냐고?

아래 링크에 마우스를 살짝 올려'만'보시라. (클릭하진 마시고...)
여기가 어딜까~~~
(주의! : 만약 외부 RSS 리더를 통해 해당 페이지를 접근하셨다면, 제가 의도한 바대로 여러분이 경악하지 않는 부작용이 있을 수 있습니다)

자, 어떠신지?
클릭을 굳이 해보지 않아도, 대략 뭐하는 사이트인지 감을 잡으셨을 것이다.
이제 현재 링크 뿐만 아니라, 왼쪽의 메뉴에 있는 'Link Site' 목록들을 마우스로 훑어내려가보자. 팀원들 블로그와 공개 RSS 피드 페이지의 썸네일이 보이는가?

Snap은 이와 같이 하이퍼링크의 대상 주소에 해당하는 웹 페이지를 작은 창으로 미리 보여주는 스크립트를 제공하는 사이트이다. 뿐만 아니라 검색 서비스도 제공하는데, 현재는 사이트와 이미지 검색을 서비스하고 있는 중이다.
홈페이지 상단 우측에 프리뷰 스크립트를 홈페이지 또는 자신의 블로그에 적용하는 방법과 신청 양식이 포함되어 있다. 사용할 도메인과 메일 주소, 그리고 어디서나 등장하는 인증 코드만 입력하면 바로 단 한줄의 <script></script> 태그가 출력된다. 이 부분을 적용할 페이지의 <head>...</head> 사이에 집어넣기만 하면 되니 관심있는 사람은 한번 써보시도록...
스크립트를 헤더에 삽입한 이후 따로 하이퍼링크들을 고칠 필요는 없다. 스크립트가 다 알아서 해주니까. (이것이 바로 CSS+Javascript의 매력!)

실험 1) 스냅샷 분석
이쯤에서 호기심이 발동한 나머지, 과연 Snap은 어디까지 스냅을 해주는가 실험해 보기로 했다.

1. MICROBIANS
DHTML에 관한한 꽤나 내공 수준이 높은 인간의 홈페이지로, 요즘은 DHTML쪽을 접었는지 기존 소스 코드만 있고 홈페이지 자체는 플래시로 완전 리뉴얼했다. 가봐도 막상 볼 것은 아트웍이 더 많은데, 대체 정체가 뭔지 궁금하다.
자 그럼 가 보자!
http://www.microbians.com 마우스 오버 ㄱㄱ싱
앗;; 동적인 플래시 사이트라서 그런지 한장의 스냅샷으로 홈페이지의 컨텐츠를 가늠하는 것은 우선 힘들어 보인다. 그래도 플래시를 적용한 사이트가 이정도로 보이면 된 거라고 토닥토닥...

2. HTML GURU
한 때 Good Design 상을 2년 연속 수상한 화제의 사이트. DHTML이 과도하게 사용된 사이트기 때문에 이번에는 정말 힘들겠지... 낄낄
http://www.htmlguru.com
헉 -_-;; 나... 나온다.
어떤 방법으로 스냅샷을 찍어오는거야 대체;;

3. 내 홈페이지 (-_-;;;)
현재 공사중인 내 홈페이지는, HTML GURU에 비해 뒤지지 않은 스크립트 난무에 무엇보다 중요한 것은 치명적인 버그가 있다는 사실이다! (자랑이다!)
http://www.overock.com
앗! 나... 나옵니다 (털썩)

4. 블로그의 특정 게시물
이번엔 정말 강적입니다!! 블로그의 특정 글 주소로 접근해, 실제 포스팅이 나오는지 아니면 대문이 나오거나 오류가 생기는지 한번 보자.
http://overock.tistory.com/6
나-_-옵니다...... 그것도 아주 정확히;;

5. '현재' 블로그의 특정 게시물
그렇다면, 현재의 사이트와 동일한 도메인을 가지는 웹 페이지의 프리뷰도 나올까?
사실 이건 조금 진지한 문제이다. 자신의 사이트에 대한 프리뷰를 본다는 건 어찌보면 '쓸데없는' 피곤함일수도 있기 때문이다.
아무튼 지하드 블로그의 '댓글놀이'를 대상으로 실험 ㄱㄱ싱
http://ghard.tistory.com/3
아아... 나오지 않는군요.
이런 전차로, 동일한 도메인을 가지는 웹 페이지의 경우에는 프리뷰를 제공하지 않는다는 사실까지 발견했다.
(여담이지만, 동일한 스크립트를 적용한 다른 사이트의 경우 abc.com으로 등록이 되어있다면 blah.abc.com 역시 동일한 도메인을 가지는 웹 페이지로 인식하고 프리뷰를 출력하지 않았음)

몇 차례의 실험을 통해, 드디어 결정적인 단서를 발견했다.
snap.com의 봇이 한 번도 방문하지 않은 사이트의 경우, 썸네일 창에 프리뷰 대신 'Queued for capture...'라는 메시지와 함께 잠시 후에 다시 확인하라는 메시지를 띄워준다(4번 실험에서 발견한 것). 이후 약 30초만 지나면 자동적으로 사이트 프리뷰가 추가된다(덜덜덜). 물론 사용자가 몰리는 시간대에 미탐색 페이지가 많이 발견되었다면, 프리뷰가 추가되는 시간도 더 늘어날 것이라는 사실을 짐작할 수 있다.

잠정적으로 내린 결론은, snap.com의 봇이 미탐색 사이트를 가리키는 anchor의 요청을 받게 되면 후다닥 해당 주소로 달려와 사진을 찰칵! 찍어와서 서버에 저장한다는 것...
아이디어도 아이디어지만, 기술력 측면에서도 결코 우습게 볼 수 없는 아이템인듯 하다.
사이트의 스냅 샷을 찍는 일이야 표준 브라우저를 구현할 만한 능력만 되어도 만들 수는 있겠지만, 그걸 일일이 queuing하고 서버에 저장하고 하는 동안 발생하는 부하는 어떻게 처리를 하는건지;;

좀더 망상적 상상을 뻗쳐 보면, 사이트에 snap.com의 스크립트를 달아놓는 것만으로도 웹 페이지 방문자가 snap.com의 봇을 조작하는 객체가 될 수도 있다는 가능성을 제기할 수 있다. 언제 어디를 crawling할지 모르는 여타 봇과는 달리 snap.com의 봇은 방문자가 많은 사이트의 링크일수록 방문할 확률도 높아질 테니까, 잘 응용하면 지금 이후에 소개할 snap.com의 검색 서비스 품질을 높이는 자료로 활용될 수도 있다는 소리다. (아니, 아마 벌써 그러고 있다고 믿고 싶다 -_-;;)

실험 2) 검색 서비스
앞서 이야기했듯이, snap.com은 사이트와 이미지 검색 서비스를 제공한다.
굳이 웹 문서가 아닌 사이트 검색이라고 표현한 이유는, 말 그대로 이놈이 '사이트 검색'만 잘 해주기 때문이다.
'mp3'이란 키워드로 검색을 시도해 보았다.
http://www.snap.com/#mp3
아쉽게도, #으로 표시된 anchor에 대해서는 http://www.snap.com과 동일한 프리뷰가 제공되니, 직접 가서 보시라.
최초 검색 서비스를 사용하는 사용자에 대해서는 친절한 튜토리얼까지 동적으로 제공된다.
화면의 좌측에는 심플한 검색 결과가 제공되고 우측에는 프리뷰가 제공되는데, 검색 결과를 한번 클릭하면 프리뷰가 표시되고 한번 더 클릭해야 해당 사이트로 이동해야 하는 점이 조금 불편하다. 어쩌겠는가... 애당초 사이트의 프리뷰를 보여주는 것이 강점인 검색 서비스인데 말이다. 그냥 프리뷰를 통해 정크 사이트를 눈으로 확인하고 필터링할 수 있음에 만족하자.
프리뷰 화면에서, 해당 웹 사이트가 마음에 드는지 들지 않는지를 평가할 수도 있는데, 이는 검색 순위에 영향을 미치게 된다.
구글의 웹 문서 검색과 같은 디테일에는 못 미치지만, 내 관심사에 맞는 컨텐츠를 제공하는 사이트를 검색하는 것이 목적이라면 나름 쓸만하다는 것이 내 결론

이번에는 이미지를 검색해볼까?
'flower'라는 키워드로 검색을 한번 해 보았다(사실, 이미지 검색 서비스를 처음 사용하는 사람에게 'flower' 이미지 검색을 한번 demonstraion하고 있다.
http://images.snap.com/search.php?query=flower
이번에는 제대로 된 화면을 캡춰한 것 같지만, 캡춰 시점이 조금 아닌듯하다. 역시 직접 가서 눈으로 확인하자 -_-;;
flower에 해당하는 이미지들이 앨범 형식으로 제공되며, 검색이 이루어지는 과정에서 부적절한 사진은 저절로 삭제되는 것을 알 수 있다(솔직히 부적절하다의 기준이 뭔지는 그 찰나의 순간으로 판단하기에는 역부족이었음).  만일 어떤 이미지가 자신의 지적 재산물이고, 지적 재산권을 보장받고 싶다면(다시 말해 검색되지 않는다든지) 이미지의 우측 하단에 있는 'copyright concern' 페이지를 통해 이의를 제기할 수 있게 되어 있다.

총론
급하게 발견한 거라서 완전 발로 테스트해보고 발로 적는거지만, 잠시간 snap.com을 둘러본 느낌은..... '이거 굉장한데'이다.
일단 아이디어부터가 심하게 독특하지 않은가 -_-;;
검색 엔진쪽은 검색계의 새 지평을 열기에는 다소 부족한 감이 없지 않아 있지만, fancy하게 쓰기에는 별 손색은 없어 보인다. 웹 페이지 검색의 경우 한글 검색은 거의 결과가 나오지 않았으며, 이미지는 영문 검색 못지 않게 잘 나오는 편임.

정말 어찌보면 별 것 아닌데, 발상 자체가 G.HARD의 지향점과 어느정도 맞는것 같아 소개했음.
이상.

아래 주소는 snap.com에서 '한채영'이란 키워드로 이미지 검색을 해서 나온 사진이니 모두 즐감 ~_~
http://vavigirl.koreastar.org/pic/pic12.htm

 
Posted by 알 수 없는 사용자
teQnical l 2007. 1. 10. 22:13
1 2 

최근에 올라온 글

카테고리

분류 전체보기 (32)
G.HARD bunker (4)
daily routine (18)
rumor says... (0)
teQnical (7)
projeKt (2)

달력

«   2024/04   »
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
tistory!get rss Tistory Tistory 가입하기!