달력

3

« 2024/3 »

  • 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

'공부하는 것'에 해당되는 글 80

  1. 2012.04.29 Spring Framework 3.0 MVC(1)
  2. 2011.10.24 Twitter REST API (2)
  3. 2011.09.14 Twitter REST API (1)
  4. 2011.09.10 GRails 대한 나의 생각... 2
2012. 4. 29. 15:12

Spring Framework 3.0 MVC(1) 공부하는 것/Spring Framework2012. 4. 29. 15:12

스프링 프레임크를 사용하기 시작한지는, 만 5년 정도 된것 같다. 아니 정확하게 이야기하면 알기 시작한지 5년이다. 그 동안 몇개의 프로젝트에는 적극적으로 사용해왔고, 사용하려고 했었다.

솔루션을 위한 내부의 기반 프레임워크를 개발하기에도, 그 자체만으로도 스프링은 너무 훌륭하기 때문에, Application의 공통 부분을 위한 기능들만을 최적화하고, 정의하는 것 만으로도 노력대비 좋은 결과들을 낼수 있었다. 다 로드존슨 아저씨가 많은 시간을 들여서 갈고 닦고, 발전시킨 노력의 결과들이다.

시간이 흐를수록 큰 조직에서는 코드와 PC와 씨름하기 보다는 수 많은 회의와 씨름을 하는 일이 많아진다. 더군다나 같이 협업하는 사람들이 많아지면, 본인이 원치 않아도 관리자의 길에서 뛰고 있는 모습을 보게된다. 딱 지금의 나의 모습니다.

공부하지 않고, 적절하게 판단하고 선택하고 방향에 대해서 이야기 할 수 있을까?
많은 고민을 하지만, 역시 시간이 절대적으로 부족하다.

요즘은 코드를 보기가 힘들정도로, 공부할 여유가 별로없다.
하지만, 사둔 책이 아깝다는 이유이든, 공부의 재미를 알았다는 이유이든 개발자로 살아가는 한은
꾸준히 배워야한다.

스프링 3.1은 또 다른 변호들을 이야기 할지는 모르겠다. 이전에 책을 보면서 정리한 내용인데 일단 올려놓는다.

[Spring Framework 3.0 - MVC]

·         스프링은 DespatcherServlet 7개의 Strategy를 기반한 MVC 프레임워크를 제공한다.

·         이중 DespatcherServlet는 가장 기본적이면서도 SpringMVC의 필수적인 기본 Servlet 역할과 스프링의 특징중의 하나인 Light-weight 컨테이너의 역할을 수행한다.

 

1.     @RequestMapping 핸들러 매핑

o    @MVC는 메소드 레벨에서 컨트롤러를 작성할 수 있다.

o    Annotation은 타입(클래스, 인터페이스)레벨뿐 아니라 메소드 레벨에도 적용 가능함.

o    @MVC 핸들러 매핑을 위해서는 DefaultAnnotationHandlerMapping이 필요하다.

o    DefaultAnnotationHandlerMapping은 기본 핸들러 이므로 다른 Handler Mapping bean이 명시적으로 등록이 되지 않았다면, 기본으로 사용이 가능하다.

o    만약, 다른 핸들러 매핑 빈이 등록이 되었다면, DefaultAnnotationHandlerMapping
명시적으로 등록을 해주어야 사용이 가능하다.

2.     Class/Method 결합 Mapping 정보

o    DefaultAnnotationHandlerMapping

·         @RequestMapping 애노테이션을 활용해서 타입레벨과 메소드 레벨 지원하며
타입레벨을 기본으로 삼고, 메소드 레벨의 어노테이션 정보는 타입레벨의 매핑을 세분화 하는데 사용한다.

o    @RequestMapping Annotation

·         Spring[] value(): URL 패턴

1.     String 배열 타입으로 URL 패턴을 지정해서 사용

2.     URL 패턴은 ANT 스타일과 와일드카드를 사용이 가능하다.

·         @RequestMapping("/hellow")

·         @RequestMapping("/admin/**/user")

·         @RequestMapping("/hellow", "/hi")

3.     "{ }"를 사용할때는, "{ }"의 위치에 해당하는 내용을 컨트롤러 Method에서 파라메터로 전달받을 수 있다. "{ }"에 들어가는 변수를 "path variable"이라고 부른다.

·         @RequestMapping("/user/{userid}")

·         RequestMethoe{} method(): HTTP Request Method

1.     Request Method GET, HEAD, POST, PUT, DELET, OPTIONS, TRACE 7개의 HTTP 메소드가 정의되어 있다

2.     HTTP 메소드를 추가하면 요청 메소드에 따라 다른 메소드를 매핑해 줄 수 있다.

·         @RequestMapping(value="/user/add", method=RequestMethod.GET)

3.     정의된 메소드 이외의 사용시 "HTTP 405 - Method Not Allowed"를 받음.

4.     타입레벨에서 URL을 주고 HTTP 요청 메소드를 지정할 경우 URL 생략가능.

·         @RequestMapping(method=RequestMethod.GET)

·         String[] params(): Request Parameter

1.     이것은 요청 Parameter와 그 값을 비교해서 매핑해 주는 것이다.

2.     같은 URL을 사용하지만, Parameter값에 따라 다른 작업을 할 때 사용한다.

·         @RequestMapping(value="/user/edit", params="type=admin")

3.     특정 Parameter 값이 존재하지 않아야 한다는 조건을 둘 경우 사용

·         @RequestMapping(value="/user/edit", params="!type")

·         String[] header(): HTTP 헤더

1.     Header 정보에 따라 매핑이 가능하다.

·         @RequestMapping(value="/view", headers = "content-type="text/*")

 

o    Type level 매핑과 Method level 매핑의 결합

·   타입(클래스오 인터페이스)레벨에 붙는 @RequestMapping은 타입내의 모든 매핑용 메소드의 공통 조건을 지정할대 사용한다.

·   메소드 레벨의 매핑은 클래스 레벨의 매핑을 상속한다.

      1. 컨트롤러가 각각 /user/add, /user/edit, /user/delete URL에 매핑

@RequestMapping("/user")

public class UserController{

@RequestMapping("/add") public String add(){ }

@RequestMapping("/edit") public String edit(){ }

@RequestMapping("/delete") public String delete(){ }

}

2.     타입 레벨의 URL패턴에 * **를 사용하여 매핑 가능

·         /user/*

·         /user/**  

·         타입레벨에서 공통의 매핑을 정의하고, 메소드 별로 세분화 해서 사용

 

o    Method 레벨 단독 매핑

·   공통 매핑 조건이 없을 경우, 조건을 주지 않고 메소드 레벨에 정의해서 사용.

·   이렇게 정의하지 않는다면, 클래스 자체가 매핑이 되지 않는다.

·   만약, @Controller 애노테이션을 붙여서 자동 빈 스캔을 사용할 경우는, 클래스 레벨의 @RequestMapping을 생략할 수 있다.

o    Type 레밸 단독 매핑

·   클래스 레벨의 URL 패턴이 /*로 끝나는 경우, apthem 레벨의 URL 패턴으로 메소드 이름을 사용할 수 있음.

·   아래는 /user/add /user/edit 로 각각 매핑

@RequestMapping("/user/*")

Public class UserController {

@RequestMapping public String add( ) { }

@RequestMapping public String edit( ) { }

}

 

 

 

 

 

:
Posted by 행복상자
2011. 10. 24. 22:30

Twitter REST API (2) 공부하는 것/Twitter API & Twitter4j2011. 10. 24. 22:30

[정말 나의 게으름으로 글 하나가 또 묻혀져 있었다.]
[지난 번의 1번글을 비슷한 시기에 쓰고, 연달아 정리하려고 했는데]
[또 다시, 뒤 늦게 글을 올리게 되었다. 미안하고 죄송하고, 부끄럽다.] 


 트위터의 API를 사용하기 위해서 필요한 내용들을 간략하게 정리해 봤다. 세부 내용들과 참고해야할 항목들도 정리했는데, 이전 기억을 살리기 보다는 FQA를 이용해서 접근하였다. 따라서 필요한 내용들은 Twitter의 개발자 가이드와 웹 사이트를 이용해서 확인 가능하다.
 
간략하게 정리하였지만, 기본적인 API들에 대한 지원은 Twitter에서 라기보다는 이를 이용한 Wraper 클래스들은 우리의 선배 또는 휼륭한 다른 개발자 들이 이미 개발하여 놓았다. 이를 잘 활용하는 것은 또 다른 문제이고, 다른 영역이라 생각하지만, 자신에 맞는 언어와 라이브러리를 잘 찾아 쓰는 것은 시행착오와 시간을 줄여주는 활동이다.

웹사이트에는 Web site를 위해서 Twitter에서 제공되는 기능들도 설명되어져 있다. (나의 관심사와는 좀 거리가 있어서, 생략...)



[Twitter API 이용하기]
 
  1. Developer document를 읽어봐야 한다.
    • Developer Guide 어떤 Framework 가지고 개발하더라고 반드시 읽어야 기본 문서이다.
  1. Twitter Libraries
    • Twitter 사용해서 List 가져오거나 Oauth 위한 라이브러리들은 아래에 정리되어 있다. 아래 링크를 참조해서 사용하고 있는 또는 필요로 하는 라이브러리를 사용하면 된다. (현재는 13 언어에서 지원하고 있다.)
  1. Twitter Character 140자로 정해져 있다.
  1. REST API 버전 정보는 현재 version 1 되어 있다.
  1. Twitter API 사용하기
    • Open Api 사용할 앱을 등록한다. (아래의 링크에서 등록)
      • Application Name Unique 해야 된다.
      • 작년(2010) OAuth 방식으로 바뀐 이후에, ID/Password 방식이 아니라, 인증키를 얻어야 사용이 가능하다.
  1. Twitter API 사용 제한
    • 인증 방식에 따라 다양하게 사용량이 정의되어 있다.
      • Unauthenticated call: 150 requests/hour
      • OAuth call: 350 requests/hour
    • 유휴하지 않은 OAuth 정보를 포함하게 되면,
      • 인증 받은 메소드: 에러 response 반환한다. (with HTTP 401 error)
      • 인증 받은 메소드: 다음과 같은 헤더 정보를 포함된 Response 받게 된다. 인증 받지 않았기 때문에, API 호출 제한은 Unauthenticated call 따른다.
        • X-Warning: Invalid OAuth credentials detected
      • HTTP GET commend 요청한 메소드들은 사용량의 제약을 받으나, POST commend 제약이 없다.(아래 문서 참조)

 

  • API 사용 제한량 알기
    • REST API 사용 제약에 도달하면, HTTP 400 Response code 받게 된다.
    • Search 또는 Streaming API 사용량이 한계치에 도달할 경우는 HTTP 420 response code 반환한다.

 

  • Search API 사용량 제한
    • REST API 제한이 없다. (그러나, 제약을 위해서 모든 요청은 IP 단위로 관리된다.)
    • 사용량이 한계치 도달 , HTTP 420 response code 받는다.


'공부하는 것 > Twitter API & Twitter4j' 카테고리의 다른 글

Twitter REST API (1)  (0) 2011.09.14
:
Posted by 행복상자
2011. 9. 14. 18:32

Twitter REST API (1) 공부하는 것/Twitter API & Twitter4j2011. 9. 14. 18:32

아주 오래전, 사실은 몇 년전(3~4년전?)인것 같다. 
Twitter를 처음 사용하면서, Twitter의 Open API와 정책들을 살펴보다가, Twitter4J라는 Twitter API를 자바에서 쉽게 사용할 수 있는 라이브러리를 접했었다.
그 당시 몇개의 Library를 검토하다가, 일본인이 만들었더 Twitter4J가 여러가지로 사용하기도 쉽고 적합하다고 판단했었는데, 최근에 개인적으로 다시 살펴볼 일이 있어서, 다시 코드를 분석하게 되었는데, 내가 이전에 기억하던 코드와 전혀 다른 코드들로 구성되어 있었다.

클라스와 메스드들은 모두 Interface로 정의하고, 이를 구현하도록 Class 들이 Re-factoring 되어져 있었다.
코드들도 깔끔하게 정리되어 있고, 정비되어져 있었고, 예제들도 모두 셈플 소스코드를 포함해서 기능별로 나주어져 있었다. (지난 몇년동안 개발자가 많은 노력과 수고를 했던것을 볼수 있었다. 고맙네...) 

아마도, 추측컨데 Twitter4J가 지원하는 플랫폼들이 다양화되면서, 인터페이스와 구현 클래스로 재 구성을 한것으로 보인다. 프레임워크의 패키지 구성을 보면, Google App Engine와 Android 단말을 지원하기 위해서 자바 Package등으로 나누어져 있다.

이를 분석하기 위해서는 먼저 Twitter의 REST API 정책을 다시 한번 살펴 볼 필요가 있다. 지난 2년동안 여러가지 정책이 바뀌고 새로운 기능들이 추가 되었을 것으로 보인다.
전체를 다 살펴보기는 힘들것이고, 개발자 가이드 먼저 살펴 봐야 겠다.


 

'공부하는 것 > Twitter API & Twitter4j' 카테고리의 다른 글

Twitter REST API (2)  (0) 2011.10.24
:
Posted by 행복상자
2011. 9. 10. 09:28

GRails 대한 나의 생각... 공부하는 것/GRails2011. 9. 10. 09:28

내가 RubyOnRails를 처음 알게된 것도 괘 오래전 이었던 것 같다.
2008년 이후로, ROR을 비롯해서, RedRails와 JRuby, Groovy를 개인적인 흥미로 인해서 설치해 보고 사용해 보기도 했지만, 그렇게 오래가지는 않았던 것 같다.

 왜냐하면, 내가 주로 하고 있는 업무는 JAVA 기반의 서비스이다보니, JAVA Virtual Machine위에서 동작해야 하고, 이를 보다 효율적인 측면에서 활용하기 싶었기 때문에, ROR을 직접 이용하기 보다는 다르지만 같은 환경에서 이용해 보고 싶었기 때문이다.

ROR의 쉽고 빠른 개발을 내가 하고 있는 프로젝트에 적용을 한다면, 생산성의 향상과 직관적인 관리를 통해서 보다 효과적이고 효율적으로 프로젝트를 진행할 수 있다고 생각했기 때문이다. (사실은 개발 시간을 줄여서 개발자들이 편해질까하는 순수한 의도와 흥미도 있었다.)
그러나, 개인적인 프로젝트라면 모를까, 팀 프로젝트와 실 운영을 위한 프로젝트 적용에는 많은 어려움들이 수반되고, 안정화와 검증되지 않은 부분에 대한 책임등을 고려할 때, 적용이 쉽지 않았기 때문에 프로젝트에서는 사용하지 못했었다.

GRails를 처음 접하게 된것은 2009년 상반기 였던것 같은데, ROR과 JRuby와 비교하면 굉장히 앞선 무엇이 있다라고 생각하지 않고, 또하나의 메이져는 아니지만, "흥미로운 프로젝트가 또 하나 나왔구나"라는 생각뿐, 큰 감흥은 없었던 프로젝트 였다.

그러가다, SpringSource에서 개발하고 있는 Eclipse기반의 개발툴인 Spring Tool Suite을 사용하다 보니, 
Grails와 Groovy를 쉽게 플러그인으로 설치할 수 있도록 되어 있어서, 설치해서 사용해 보게 되었는데, ROR과 같이 자동으로 Scaffolding해주고, Springframework를 사용할 수 있도록 해주고, groovy 대신에 java를 사용할 수 있다는 것이 마음에 들었다.
 

그리고, 기본 내장되어 있는 in-memory DB인 Hbase와 Tomcat를 통해서 Grails 프로젝트 생성과 동시에, Deploy해서 테스트 할 수 있는 환경이 바로 제공된다는 것이 무척 마음에 들었었다.

단, 새로운 파일들의 생성과 빌드를 위해서 HDD의 I/O가 많아서 불필요한 시간이 든다는 점과, Plug-in간의 
Dependency에 대한 문제가 있어서 인지, 일부 플러그인은 정상적으로 업데이트가 안되곤 했다.
특히, STS를 이용할 경우는 여러가지 편리한 점이 많지만, STS에 대한 Dependency로 인한 Plug-in의 업데이트가 정상적으로 진행되지 않았기 때문에, 문제점 해결에 많은 시간을 보내곤 했다.

그러다가, STS 2.7 버전이 나오면서, 기존에 2.5와 2.6버전에서 가지고 있던 Dependency 문제를 어는 정도 해결해 주었는데, 이직도 Plugin에 대한 Dependency문제가 있다. 특히, Hibernate와 Tomcat은 기본 프로그인으로 설치시 포함되어 있지만, Google App Engine SDK 설치를 위해시, 이들 플로그인들이 정상적으로 제거되지 않는 문제들을 가지고 있고, STS를 종료하고, 수동으로 삭제해주어야 한다.
 

사실, 이는 Grails의 문제가 아니라, STS와 윈도우즈7간의 권한의 취득에 대한 것이므로, 직접적인 책임은 없으나, 제대로된 IDE의 지원은 절실하다.

GRails는 STS의 지원 없이도 사용이 가능하지만, IDE를 이용하는 것은 생산성을 위해서 이기 때문에, 이를 이용하는 것이 사용하지 않는 것보다 이득이 크다.
Ggrils를 통한 개발에서 STS를 이용하지 않는 다는 것은 굉장히 불편한 길을 찾아서 걷는다라는 기분이 든다. 자바 개발에서 사용하던 라이브러리들도 그대로 이용이 가능하므로, 자바로 개발하던 개발자에게는 추가로 개발을 위해서 들여야 하는 학습 시간을 많이 필요로 하지 않기 때문에 이전에 Eclipse를 사용하던 개발자라면, STS를 설치하지 않고, Plug-in 만 설치해서 개발이 가능하다.
하지만, 나는 개인적으로 Eclipse를 설치하는 것보다는 STS를 설치하는 것이 낫다고 생각한다.

올 10월 정도에는 GRails 2.0이 새로 나온다.
여러가지 다양한 Featuer들의 변화가 였보이는데, 어제인가 보니 Grails 2.0 M2버전이 Release 가 되었던 것 같다.
 



 
:
Posted by 행복상자