태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'web'에 해당되는 글 8건

  1. 2012.07.12 도깨비(tokebi) 더미 API (5)
  2. 2007.08.17 Ruby on Rails - Controller의 단위 (5)
  3. 2007.05.11 바람직한 웹? (1)
  4. 2007.05.02 Web - 데이터를 어디에 저장하지? (2)
  5. 2007.04.18 Ruby On Rails - Scaffold의 함정 (2)
  6. 2007.04.07 책 제본했다! 아자~ (4)
  7. 2007.04.01 지름: AgileWebDevelopmentWithRails, PDF Ver
  8. 2007.03.30 Ruby on Rails 공부(?)중

도깨비(tokebi) 더미 API

Daily life/Hard study 2012.07.12 22:19


목표: 아이폰에서 읽고 쓸 수 있는 임의의 저장소 인터페이스를(만) 만드는 것


1. Initial commit
  - put: (app_key, content, tag_list, meta_info)
  - get: (app_key, condition)

  일단 일반적인 모양만 정의하고 세세한 사용은 나중에 정의하기 위하여 메타정보, 조건 등을 dictionary 로 받는걸로 한다. POST 요청만 다루며 GET은 예외를 던져버리도록 하자. 일단 인터페이스를 만드는게 목표이므로 실제로 데이터를 저장하는 부분은 고려하지 않는다.


성능은 고려사항이 아니다. 아이폰 앱을 만들 때 붙여놓을 더미가 필요한 것이므로 django로 후다닥 작성한다. django 1.4 기준이다. 혹시 나중에 필요하게 되면 비동기로 다시 작성한다. 개인적으로 eventlet 에 관심이 ...

  app_key: fixed-length binary
  content: binary
  tag_list: list of strings
  meta_info: dictionary
  condition: dictionary

  URL:
    - /api/v1/put
    - /api/v1/get

  이 저장소는 만들어질 아이폰 앱과는 완전히 별개의 코드베이스이므로 독립적인 git 저장소를 생성한다. dgoon's key value storage -> dkv -> 도깨비 -> tokebi 로 한다. 난 부끄러움이 많으니까 github에 공개 저장소를 만들진 않는다. 하지만 비공개 저장소도 싫으니까 개인서버에 조용히 판다. git.dgoon.net

django 프로젝트(tokebi)를 생성하고 기본 세팅. RDB는 사용하지 않을 예정이므로 DATABASES는 깔끔하게 날린다.
나중에 관리 페이지라던가 다른게 생길 수 있으니 api 라는 애플리케이션을 생성해서 거기에 코드를 넣는다.
위에서 정의한대로 필요한 콜은 put, get 두개이다. 이 각각을 받아줄 endpoint 를 설정한다. 정의되지 않은 URL에 대해서는 일단 404를 알아서 만들도록 둔다. secret key 따위 알게뭐야 흥.

----- api/views.py -----
from django.http import HttpResponse

def api_get(request):
    return HttpResponse('OK', status=200)

def api_put(request):
    return HttpResponse('OK', status=200)


----- tokebi/urls.py -----
...
from api.views import api_get, api_put

urlpatterns = patterns('',
    url(r'^api/v1/get/', api_get),
    url(r'^api/v1/put/', api_put),

…)


이렇게 하고 테스트 서버를 띄워서 접속하면 /api/v1/get, /api/v2/put 에 대해서 OK 를 얻을 수 있다. 일단 여기서 Initial commit 을 해 둔다.


2. Test request

필요한 정보가 모두 있는 경우 OK를, 부족한 경우 500 에러를 내도록 한다. 이게 되어야 개발에 사용할 더미로써 가치가 있다.
그러기 위해선 쿼리를 보낼 수 있어야 한다.

put.py, get.py 를 만든다.

  - put.py: 명령행에서 HOST PORT CONTENT TAG_LIST 를 입력받는다. 메타정보는 일단 {} 를 넣는다.
  - get.py: 명령행에서 HOST PORT 를 입력받는다. 조건에 {} 를 넣는다.

두 경우 모두 app_key 는 'deadbeef' 를 하드코딩한다. 요청은 파이썬으로 작성한다. httplib.HTTPConnection(http://docs.python.org/library/httplib.html#httpconnection-objects) 을 사용하면 되겠지.

----- put.py -----
import sys, httplib, urllib

APP_KEY = 'deadbeef'

if '__main__'==__name__:
    if len(sys.argv)<5:
        print('Usage: %s host port content tag_list' % sys.argv[0])
        sys.exit(0)

    host = sys.argv[1]
    port = int(sys.argv[2])
    content = sys.argv[3]
    tag_list = sys.argv[4:]

    conn = httplib.HTTPConnection(host, port)
    body = {
        'app_key': APP_KEY,
        'content': content,
        'tag_list': tag_list,
        'meta': {},
    }
    header = {
        'Content-type': 'application/x-www-form-urlencoded',
        'Accept': 'text/plain',
    }
    conn.request("POST", "/api/v1/put/", urllib.urlencode(body), header)

    res = conn.getresponse()
    res_body = res.read()
    assert(res.status==200 and res_body=='OK')


그런데 python put.py localhost 2223 HAHAHA tag1 tag2 tag3 를 실행해더니 assertion error가 떳다.

[12/Jul/2012 21:06:55] "POST /api/v1/put/ HTTP/1.1" 403 2282
[12/Jul/2012 21:07:07] "GET /api/v1/put/ HTTP/1.1" 200 2

403이 put.py 로 날린 요청, 200 이 브라우저에서 날린 요청이다. 500도 아니고 403 ?? put.py 에서 res_body 를 찍게 해 봤더니,
csrf관련된 내용이 보인다. 말인 즉슨, cross-site request forgery를 방지하기 위한 미들웨어가 있는데 그녀석을 위한 토큰이 포함되어야 한다나 어쩐다나.
나는 템플릿을 쓸 생각이 없고, 요청에 그런걸 만들어 보내는것도 귀찮으므로 csrf 관련 옵션을 비활성화 해버리겠다. settings.py 에서 csrf 로 검색하면 바로 나온다. MIDDLEWARE_CLASSES 에서 django.middleware.csrf.CsrfViewMiddleware 를 주석처리하고 나니 잘 된다.

api_put 을 고쳐서 들어온 body 를 확인하도록 하자. 콘솔에 그냥 print 를 해보면 볼 수 있다.

----- api_put @ views.py -----
def api_put(request):    method = request.META['REQUEST_METHOD']
    print method
    print request.GET
    print request.POST
    return HttpResponse('OK', status=200)

이렇게 하고 put.py 로 한번, 브라우저로 리프레시 한번 하면 콘솔에 아래와 같이 찍힌다.

POST
<QueryDict: {}>
<QueryDict: {u'content': [u'THIS IS CONTENT'], u'tag_list': [u"['tag1', 'tag2', 'tag3']"], u'meta': [u'{}'], u'app_key': [u'deadbeef']}>
[12/Jul/2012 21:27:37] "POST /api/v1/put/ HTTP/1.1" 200 2
GET
<QueryDict: {}>
<QueryDict: {}>
[12/Jul/2012 21:27:40] "GET /api/v1/put/ HTTP/1.1" 200 2

귀찮으니

  a. content, tag_list, meta, app_key 가 모두 있지 않은 경우
  b. method=POST 가 아닌 경우

에 모두 예외를 던져버리자. … 코드를 만들고 나서 생각해보니 method=POST 강제하는건 왠지 데코레이터 있을 것 같다. 검색 ㄱㄱ

https://docs.djangoproject.com/en/dev/topics/http/decorators/

빙고. 그러면 최종적으로 api_put 의 모양은 아래와 같게 된다.

----- api_put @ views.py -----
from django.views.decorators.http import require_http_methods
class MissingRequiredField(BaseException): pass                                    

PUT_REQUIRED_FIELDS = ['app_key', 'content', 'tag_list', 'meta']

@require_http_methods(["POST"])
def api_put(request):                                                             
    try:                                                                          
        params = request.POST
            if (set(PUT_REQUIRED_FIELDS) - set(params.keys())):
                raise MissingRequiredField('MissingRequiredField')                                                                                                        
        content = params['content']                                               
        app_key = params['app_key']                                               
        tag_list = params['tag_list']                                             
        meta = params['meta']                                                     
                                                                                  
        print(app_key, content, tag_list, meta)                                   
                                                                                  
        return HttpResponse('OK', status=200)                                     
    except BaseException, msg:                                                    
        print('Exception raised: %s' % str(msg))                                  
        return HttpResponse(str(msg), status=500)          

그런데, 콘솔 출력을 보면

(u'deadbeef', u'THIS IS CONTENT', u"['tag1', 'tag2', 'tag3']", u'{}')
                       
이렇게 보이는게, tag_list, meta 가 직렬화된 상태로 넘어온 것 같다. … 음 이거 귀찮은데 …
그냥 요청을 json 으로 받을까. 일단 get.py 도 만들고 나서 고민하자. get.py 는 put.py 의 copy&paste로 뚝딱.
api_get 도 api_put 을 복사붙이기로 작성한다.

views.py: http://git.dgoon.net/?p=tokebi.git;a=blob;f=tokebi/api/views.py;h=09dd4ab585b3be18654fd51356f1ccd1d7f50fdc;hb=c4a018b479157c9e27a6a67c912079e3ebe1be6d
get.py: http://git.dgoon.net/?p=tokebi.git;a=blob;f=sample_query/get.py;h=4d10dabf8d1097464fad6d15bed582366480a2ca;hb=c4a018b479157c9e27a6a67c912079e3ebe1be6d
put.py: http://git.dgoon.net/?p=tokebi.git;a=blob;f=sample_query/put.py;h=1f2f5ef3aef9be70e6758094b3fcdd238ec33619;hb=c4a018b479157c9e27a6a67c912079e3ebe1be6d

오늘은 일단 여기까지. 추후에 요청을 json 으로 받도록 해보자. … 는 나중에 하고, 간단한 persistent layer를 붙여서 아이폰에서 put/get 동작시키는걸 먼저 해야겠다.


tags : Django, REST, tokebi, web
Trackbacks 0 : Comments 5

Ruby on Rails - Controller의 단위

Tech 2007.08.17 02:45
연관된 이전 글

이전에 모델(테이블?)에 대한 CRUD인터페이스를 기반으로 하는 Model-Wrapper스러운 컨트롤러에 대해 이건 아니야! 라면서 툴툴거린 적이 있다. 컨트롤러는 어떤 단위로 만들어져야 하는가. user라는 모델과 user 라는 컨트롤러가 있어서 가입/로그인/정보수정/개인화페이지 등 user 모델이 주가 되는 페이지는 모두 user 컨트롤러에 붙는 것인가? 왠지 이건 아닌 것 같다... 컨트롤러는 서비스의 구조다.

만들려는 웹 서비스의 사이트맵을 한번 그려보자. 트리 구조로 그리면서 가능한한 모든 페이지를 다 포함시키자. 웹 페이지가 될 녀석들은 가능한 한 Leaf node로 내린다. 그려놓고 보면 흐름이 있거나, 밀접하게 연관되어 있는 페이지들을 묶어 서브 트리를 구성할 수 있다. 이 서브트리의 루트는 자기 아래쪽에 있는 있는 페이지들에 대해 일종의 초기화면 역할을 할 수 있는 녀석이니 적당한 녀석을 골라 올리거나 아니면 새로 만든다. 자, 이런 식으로 트리 구조가 다 그려졌으면 초기화면인 Root node와 액션과 1:1 로 연결될 Leaf node를 제외하고 나서 나머지 node를 가지고 컨트롤러를 찍자. 찍은 녀석이 웹 페이지를 가진다면 그것이 컨트롤러의 index가 되고, 웹 페이지를 가지지 않아도 Leaf가 아닌 이상 상관은 없다. 어느 정도 Depth에 있는 노드를 컨트롤러로 정할지는 만들 웹 서비스에 따라 그때그때 다를 수 있다. 나름대로 정한 규칙이 있다면,

컨트롤러는 다른 컨트롤러를 부모나 자식으로 가지지 않는다.
컨트롤러는 자신을 루트로 하는 서브트리의 노드들(만)을 액션으로 가진다.
컨트롤러와 Leaf node 사이에 있는 Node는 서브트리에 있는 액션들의 이름에 Prefix가 된다.

정도가 되겠다. 꽤 쓸만한 방법인듯 하다. 너무 직관에만 의존하면 위험하니 적절한 참고나 가이드라인 정도로 삼으면 괜찮을 듯 하다.

실례로 사용할 만한 그림을 그려놓고 싶지만, 너무 귀찮으므로 나중에 포스팅하고 링크로 연결시켜 놓겠다.

'Tech' 카테고리의 다른 글

sena, the most powerful machine in the universe!  (6) 2007.08.31
svn relocate/tunneling  (0) 2007.08.31
Ruby on Rails - Controller의 단위  (5) 2007.08.17
실명인증  (5) 2007.07.02
지름: Ferret short cuts (O'reilly), PDF  (0) 2007.06.08
Web - 데이터를 어디에 저장하지?  (2) 2007.05.02
Trackbacks 0 : Comments 5

바람직한 웹?

Thoughts 2007.05.11 02:31

사람마다 바라는것, 좋다고 생각하는 것은 다르다. ... 마치 Emacs vs VI 같이 끝없는 논쟁거리가 수두룩한 세상. 웹 개발을 할때 지향해야 하는 점, 사람을 모으기 위해 필요한 것이 무엇일까. 역시 사람들마다 중요하다고 생각하는 점이 다르겠지. 내가 생각하는 좋은 웹 페이지, 혹은 웹 서비스의 View 는 이런 것이다 - (정리)

1. 기다림이 없다. 빠르다.
 => 웹 페이지의 로딩 뿐 아니라, 원하는 컨텐츠에 접근할때까지의 클릭/액션 수 역시 포함한다. 요는, 내가 보고싶은걸 빨리 볼 수 있게 해달라는 것이다.

2. 중요한 것에 집중
 => "의미"를 따라 "장식"이 들어가야 한다. 사람들이 모이는 사이트는 무엇보다도 "의미 전달" 이 명확한 곳이다. 멋진 웹과 사람이 모이는 웹은 다를 수 있다. 다음 카페, 네이버 블로그, 지식인, 디씨인사이드, 케이벤치 - 하고싶은걸 어떻게 해야 하는지, 보고싶은걸 어떻게 보아야 하는지 바로 알수 있는 구성이 중요.

3. 일관성 있는 디자인
 => 하나의 웹 서비스는 전체를 아우르는 Look & Feel 이 있어야 한다. 하나의 페이지가 아닌, 서비스로 각인되기 위해서 일관성을 유지할 필요가 있다.

그리고, View와는 좀 다른 문제이지만 - 존경할 만한, 박수쳐줄만한, 엄지손가락을 치켜세워주고 싶은 곳들은

4. 크로스 브라우징

5. 화면 크기나 폰트 크기에 따른 유연함

6. 텍스트는 텍스트로, 이미지는 이미지로 - 크게는 접근성과 의미 중심의 문서에 대한 고려

7. 흐름을 끊는 요소가 없음 (특히 팝업-_-)

등의 문제에 대해서 깔끔하다.

... 개인적으로 미국전자정부, 야후초기화면, 르몽드뉴욕타임즈, 슬래시닷, 구글 같은 스타일의 웹 페이지(혹은 서비스)를 좋게 생각한다. 다 외국거로군...



P.S. 위 내용은 <Logic, Interaction, Updates>가 중요하지 않은 곳에는 해당되지 않습니다. 다시말해 대기업 홈페이지(http://samsung.com, http://www.nike.com)같은곳은 논외라는 것.

'Thoughts' 카테고리의 다른 글

23명  (6) 2007.07.29
김승연, 입원!  (1) 2007.07.17
바람직한 웹?  (1) 2007.05.11
나의 리더는 나?  (4) 2007.04.30
의도치 않은 뉴런활동  (3) 2007.04.29
난 삼권분립을 배웠다.  (12) 2007.04.28
Trackbacks 0 : Comments 1

Web - 데이터를 어디에 저장하지?

Tech 2007.05.02 01:13

세션이나 쿠키에 대해 알게 되면서 시작되는 초보적인 고민 - 이라고 생각한다 - 은 "그래서 둘중 뭘 쓰지?" 가 아닐까 한다. ... 왜냐하면, 나는 지금 웹 개발의 초보이고 그 고민을 가지고 있기 때문에 ... 함께 프로젝트를 하고 있는 후배와 이야기를 하다가 간혹 나오는 주제인데, 주제의 기술적 난이도나 난해함에 비해 중요도가 매우 높다고 생각된다. 조금이나마 시간을 내서 정리해 보는건 유익할 것 같다.

웹 서비스를 제공하기 위해서는 로그인 정보나, 현재 보고 있는 글의 분류 정보, 에러 메시지, 페이지간 주고받는 데이터 등 기억해 둘 것이 많다. 정보의 갱신 주기에 따라 데이터를 분류해 보자면 사용자의 액션에 따라 계속해서 변하거나 생성/소멸되는 동적인 데이터, 로그인 정보처럼 한번 만들어지면 자주 바뀔 필요가 없는 정적인 데이터가 있다. 정보의 노출 범위, 유효시간 등에 의해서 나눌 수도 있는데, 지금 화면에 뿌려지고 있는 글의 카테고리처럼 페이지-View 마다 존재하는 데이터나, 사용자 인증 정보처럼 여러 페이지가 공유하는 - Session - 스타일의 데이터가 있다. 그 외에도 여러가지 기준이 있을 수 있다. Post, Get등의 방식을 통해 페이지를 넘나드는 데이터도 있으며, DB, Session 혹은 RoR의 Flash같은 객체를 통하여 다른 페이지에 넘어가는 데이터도 있다. 그 외에도 무언가를 저장하는 곳 - 으로 쿠키, 파일, 소스코드 등을 생각할 수 있다. 참 많기도 해라...!

그럼 어떤 상황에서 어떤 데이터 저장공간을 사용해야 하는가? 아무거나 편한걸 쓰면 되나? 라는 물음이 나오는데 잘 생각해보면 몇몇 위험한(?), 또는 좋지 않아보이는 선택이 있을 수 있다. 나는 안되는 것이 아니면 된다, 정도의 포용주의를 펴고 있으니 쓰면 안될 것 같은 경우를 정리하고 그것만 피해서 쓰고싶은걸 쓰자 라는 정책을 세웠다. 자, 이게 최소한의 원칙이다.

1. 링크는 웹 서비스의 내부 상태(DB라던가...)를 변경시켜선 안된다. => GET method로 중요한 정보를 넘기지 않는다
2. 세션은 커넥션 단위로 유지되는 정보를 담는다 => 서버쪽에 저장
3. 뷰(페이지?)에 대한 정보는 뷰에 담는다 => 클라이언트쪽에 저장 (URL encoded...)
4. 3번의 경우라도, 중요한 정보(보안? 개인정보? 상태변화가능성 등?)는 삽질이 되더라도 뷰에서 뺀다

 1번에 대해서는 여기에 대강의 설명이 되어 있다. GET은 side-effect가 없도록 하는게 안전, 혹은 권장사항이다.

 2,3번의 차이에 대해서는... 예를 들어, 글 목록을 보는 링크는 페이지에 대한 정보다. 로그인 한 후 여러 탭을 띄워 여러 게시판을 볼 수 있는데, 이 경우 현재 보고 있는 게시판이 뭔가에 대한 정보는 커넥션이 아니라 뷰 단위 관리가 맞다. 그러므로, 세션은 안됨. 뷰쪽에서 가지고 있는게 맞는것 같다. (물론 세션으로 구현할 수는 있다) 로그인 정보는 커넥션 단위로 관리되는 정보이므로 클라이언트보다는 서버쪽에 - 세션에 저장되는게 더 그럴싸해 보인다. (물론 쿠키에 때려넣을수도 있겠다)

 4번은 당연.

 그 외의 경우라면, 그냥 맘 가는대로 해보자.


P.S. Difference between GET and POST - 라는 주제는 여기저기서 꽤나 많이 언급되었던 것인가 보다. 내가 무지했던게로군...

'Tech' 카테고리의 다른 글

실명인증  (5) 2007.07.02
지름: Ferret short cuts (O'reilly), PDF  (0) 2007.06.08
Web - 데이터를 어디에 저장하지?  (2) 2007.05.02
Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
tags : GET, POST, session, web
Trackbacks 0 : Comments 2

Ruby On Rails - Scaffold의 함정

Tech 2007.04.18 09:36

RoR을 공부하며 "얼라? 꽤 편하네?" 라고 생각하게 되는 scaffold. 사실 이게 독이다 ... 까진 아니어도 독이 될 수 있다. scaffold가 본연의 목적을 넘어가는 용도로 사용되기 시작할때 그 아픔이 시작된다.

Scaffold를 사용해보면 dynamic scaffold/static scaffold 모두 Model-Controller가 1:1 관계로 가기 좋다. 아니 1:1 관계다. 왜냐하면 scaffold는 특정 모델을 웹에서 접근 가능하게 하는 인터페이스이기 때문이다. 컨트롤러는 URL, 즉 페이지와 직접적으로 닿아있고 웹 페이지가 바로 모델의 인터페이스가 되는 구조인 scaffold에서는 이런 일대일 관계가 자연스럽다. 하지만 ? ... 만들려는 서비스가 조금 복잡해지기 시작하면 문제가 시작된다.

일반적인 웹 서비스의 경우, 모델이 웹을 통한 직접적인 인터페이스를 가지지 않는 것이 더 상식적이지 않은가? 관리자가 아니라면 말이다. 개발 단계에서야 모를까 하나의 페이지에 여러 모델에서 가져온 정보가 이곳저곳에 서로 다른 형태로 등장하게 되는데, 이렇게 되면 scaffold를 베이스로 만들어진 코드들은 뭔가 난감하게 된다. 꼭 scaffold가 아니라 모델-Wrapper 스타일의 컨트롤러의 경우. 레일즈가 유연하기 때문에 어느정도 규모가 될 때까지는 무리 없이 작업이 가능하고 잘못되어가고 있다는 점도 모를 수 있다는게 안습이라면 안습. Model-Controller의 일대일 대응관계는 튜토리얼 성격의 간단한 프로그램에서나 볼 수 있는(그게 아니라도 일반적인건 아닐는) 것이라는게 지금까지의 결론.

그렇다면 Model, View, Controller는 레일즈에서 어떤 역할을 해야 하는가? 사실 모든 코드를 Model, Controller, View 어느 한곳에만 때려넣어도 동작은 한다. 모든것을 View에 때려넣으면 PHP와 거의 같은(하지만 Embedded Ruby가 더 강력할것 같다) 동작을 하게 된다. 코드가 Controller, Model중 어느 한곳에만 모여도 웹 서비스를 구성하는 것은 가능하다. 요는 이 세가지에 어떻게 적절하게 서비스를 분산시킬 것인지, 이 세가지에 속하지 않는 것을 어떻게 따로 뺄 것인지를 정하는 것인데 지금까지 레일즈를 보며 세운 기준은 이렇다.

1. View는 가능한한 로직을 배제. Display를 위한 조각 템플릿과, 조각 템플릿이 모여 구성되는 레이아웃 정도. 단계별 구조화가 중요하다.
2. Model은 군더더기 없이 유지한다. OOP적인 시각에서 보면 Model은 넣을 수 있는 것은 다 넣고 뺄 수 있는 것은 다 빼두는 하나의 응집된 클래스로 유지해야 한다.
3. Controller는 URL과 View사이를 Model을 개입시켜 연결해 주는 역할을 한다. 즉 웹 페이지와 직접 살을 맞대는 일을 한다.
4. 복잡한 로직은 가능하면 Helper나 Library의 모듈로 뺀다.

...

튜토리얼은 그 플랫폼에서의 사고방식의 베이스를 구축하는데 중요한 역할을 한다. Scaffold는 Agile이라는 키워드에 맞는 쉽고 강력한 툴이다. 하지만 위험하다. 개발의 도구가 아니라 개발의 과정(주로 Static으로 뿌려놓고 고쳐나가는?)으로 사용한다면 나중에 자신을 옥죄게 될지도 모른다.



P.S. RoR은 유연한 프레임웍인것 같다. 사실 모델과 컨트롤러가 1:1 대응이 되어도 지저분하지 않게 다룰 수 있는 장치들이 있다. ... 위에도 밝혔듯이, 어떻게 해도 할 수 있다, 라는 데에서 왠지 Perl느낌이 든다.

'Tech' 카테고리의 다른 글

지름: Ferret short cuts (O'reilly), PDF  (0) 2007.06.08
Web - 데이터를 어디에 저장하지?  (2) 2007.05.02
Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
지름: AgileWebDevelopmentWithRails, PDF Ver  (0) 2007.04.01
tags : MVC, Rails, RoR, Ruby, Scaffold, web
Trackbacks 0 : Comments 2

책 제본했다! 아자~

Tech 2007.04.07 14:02
역시 책은 손으로 넘겨가며, 낙서도 좀 하고 형광펜으로 줄도 긋고 가금 구겨서 코도 풀고 하는게 제맛이다. 아직은 아날로그적 감수성이 기분을 좌우하는 듯.

Agile Web Development With Rails 지름! 연결

PDF로 샀다가, 그냥 제본 고고해버렸다. ... 음, 그냥 책까지 사버리는게 더 나은 선택이었을지도 모르지만, 일단 배송 시간때문에 ... 여튼, 아래쪽에 Prepared exclusively for Kangsan Lee 하고 쓰인게 맘에 드는걸? 으흐흐흐~

지금까지 단편적인 부분이나마 RoR의 장점 몇가지를 보면,

1. DB Scheme 의 버전관리가 된다.
2. SQL Query 를 직접 작성할 필요가 없다.
3. 개발하면서 당장 필요없는 인터페이스는 Scaffold 로 대체할 수 있다.
4. MVC 모델이 기반이어서 View쪽에 대해서만 디자인 쪽과 이야기하면 된다. 즉 -> 디자인쪽과 협업이 쉽다.
5. Code - Test - Debug/Adapt 의 개발 사이클이 빠르게 돌아갈 수 있다.

빨리 스윽 다 읽어보고 심화시켜 장/단을 정리, 검증 및 사용 - 해 볼 필요가 있겠다.

'Tech' 카테고리의 다른 글

Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
지름: AgileWebDevelopmentWithRails, PDF Ver  (0) 2007.04.01
Ruby on Rails 공부(?)중  (0) 2007.03.30
개발이란 것은,  (2) 2007.03.25
tags : Agile, Rails, RoR, Ruby, web, 제본
Trackbacks 0 : Comments 4

지름: AgileWebDevelopmentWithRails, PDF Ver

Tech 2007.04.01 12:19
신용카드는 이런데 쓰기 위해 만든 것이다! 두둥~ 재밌는 것은 결제할때 비밀번호를 물어보지 않는다는거... -0- 그냥 이것저것 묻고 땡이다. 우린나라와는 좀 다른 인식인건가?

사용자 삽입 이미지


'Tech' 카테고리의 다른 글

Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
지름: AgileWebDevelopmentWithRails, PDF Ver  (0) 2007.04.01
Ruby on Rails 공부(?)중  (0) 2007.03.30
개발이란 것은,  (2) 2007.03.25
tags : Agile, PDF, Rails, RoR, Ruby, web, 지름
Trackbacks 0 : Comments 0

Ruby on Rails 공부(?)중

Tech 2007.03.30 12:30
필요한 일이 있어서 RoR을 공부하는 중이다. 일단 루비는 좀 익혀 두었기 때문에, 언어의 Feature 보다는 Design/Architecture 쪽에 집중해서 보고 있다. 아직 갈 길이 멀지만 지금까지의 느낌은

1. 철저한 Data-driven 설계 (ORM + 웹 서비스-OOP 의 맵핑)
2. Model - View - Controller 패턴
3. Practical development

이정도의 화두가 녹아있는 것 같다.

문득 떠오르는 생각: 요즘 AJAX가 뜨고 있다지? 클라이언트쪽에 로직을 넣어 서버 부하를 줄일 수 있고, 보다 역동적인 UI 구성도 가능... RoR은 기본적으로 비지니스 로직은 서버사이드에 있는 것 같은데, AJAX와 붙으면 어떻게 될까? 몇몇 DHTML 스크립트 엔진들과는 잘 붙는다고 하던데, 상상이 잘 안되고 있음.

일단 책을 좀 보고, 삽질을 좀 해보고, 현업에 써본 다음( -_-; 무책임 ) 정리해볼 필요가 있겠다.


'Tech' 카테고리의 다른 글

Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
지름: AgileWebDevelopmentWithRails, PDF Ver  (0) 2007.04.01
Ruby on Rails 공부(?)중  (0) 2007.03.30
개발이란 것은,  (2) 2007.03.25
tags : ajax, MVC, ORM, Rails, RoR, Ruby, web
Trackbacks 0 : Comments 0