본 포스트는 layout에 대해 간단히 얘기해보고자 한다. MVC패턴의 V, Viewer의 경우는 html을 생각했을때 충분히 복잡해지고 지저분해질 수 있는 여력이 다분하다. 나도 예전에 통프레임이냐, 아이프레임이냐 등 갑론을박하며 이와 관련하여 많은 고민들을 했던 것 같은데. 오랜만에 다시 이런 내용들을 접하게 된다. 그래서 header, footer를 만들어서 중복되거나 반복되는 코드들은 최대한 따로이 빼고 로직만을 넣는 코드들을 따로 만들고 했던 것 같은데, 지금의 layout도 그러한 고민들이 충분히 계속될 부분이다.

일단 3가지만 기억하면 될 것 같다.

1) layout은 viewer의 전체적인 레이아웃, 반복되는 viewer의 부분을 따로 빼두는 곳으로써 app/views/layouts에 그 파일들이 담기게 된다.

2) 전체 레이아웃을 관장하는 문서는 application.html.erb이고 여기에는 <%= yield %>라는 곳에 다른 viewer들의 내용이 담긴다.

3) 만약 특정 문서들은 다른 레이아웃으로 가고 싶으면 해당 컨트롤러 이름으로 XXXX.html.erb로 만들면 된다.

이에 대한 내용에 좀더 관심이 있으신 분은 아래 링크를 클릭할 것.

링크

사실 비즈니스적인 목적을 대는게 맞으나(사실 친구가 그런 프레임으로 물어보니 느꼈다.) 나는 사실 호기심으로 선택한 것이었다.
php 는 예전에 asp, jsp와 함께 다루어보기도 했고 나에겐 사실 신선도가 좀 떨어지는 그런 language였다. (물론 마크주커버그가 php로 만들어낸 facebook으로 php는 최근에 다시 각광을 받고 있는 것도 사실이지만.) 어제 개발좀 한다는 친구와 서비스에 대해 논의하면서 다시금 고민하고 있는 것이 이, 선택이유였다.

난 프로토타입까지는 개발자를 구하지 못하면 내손으로 어떻게든 해본다는 생각을 하고 있었고 모바일이 중점이 될지라도 네이티브 앱을 만들기전까지는 웹앱형태로 가든 어찌되든, 결국 웹을 먼저 시작해야 한다는 생각에 생산성이 높다던 파이썬(Python)과 루비온레일즈(Ruby on Rails, ROR) 중에 하나를 선택하는 것이 적절하다고 생각했다.

그래서 파이썬과 루비를 비교하는 여러 글들을 보면서 선택에 대하여 스타일의 차이로 인해 한쪽이 절대적으로 좋다는 글보다는 서로 장단점을 갖추고 있다는 결론을 얻었으며 그리고 이미 루비온레일즈로도 구현된 서비스가 운영되고 있기에(쿠폰모아) 루비로 일단은 시작을 해보자는 결론을 얻었던 것이었다.

그런데 어제 친구와 대화중에 친구는 다음과 같은 논리로 루비가 적정한지 다시한번 생각할 필요가 있다고 하였다. 그 이유인즉,
- 국내에 루비개발자 pool이 아직 그렇게 크지 않다.
- 아직은 루비는 hobby로써 개발자들의 새로운 언어에 대한 흥미를 가지고 스터디용도로는 많이 활용이 되고 있으나 비즈니스 서비스 시스템으루 구현되기에는 여러가지 문제가 있을 수 있다. (다른 시스템과의 연계, 개발자들의 작업 퀄러티,  인력 수급 문제 등)

프로토까지는 내가 구현한다는 가정을 하더라도 지금 나의 작업 양상을 보면 스터디를 하면서 진도가 그렇게 빠르지 않은 실정이다. 문제에 봉착하였을때 이것저것 자료를 찾고 혹은 강의 동영상을 보며 접근을 하고 있는데 차라리 프로토타입이 바뀌어질 가능성도 있다고 생각한다면 오히려 더 빨리 개발할 수 있는(즉, 내손에 익숙한) 언어를 쓰는건 어떨까?

그렇지만, 사실 난 보이지 않는 믿음을 가지고 있다.

근래에 나오는 뭔가 묘한 UI/UX의 서비스들은 루비로 만들어졌을꺼야 라는….-_-;;;

모든 것을 다 살펴보기는 어려울 것이고, MVC패턴에 입각, 개별 구성요소들이 어떤 클래스들과 특징들을 가지고 있는지 알아보기로 하자.

1. Model

- users(model) : database의 users의 테이블과 매칭되는 model, 각종 유저 로긴정보들을 담고 있음
id, email, password, when created, updated, signed etc

2. Controller & Viewer

- confirmations_controller.rb : sign in, out, up을 했을 떄 동작을 confirm하는 컨트롤
- omniauth_callbacks_controller.rb : omniauth와의 연결에 실패했을떄 사용되는 컨트롤
- passwords_controller.rb : password를 수정하고 리셋하는 컨트롤
- registrations_controller.rb : 유저 등록 및 삭제
- sessions_controller.rb : 로그인 및 아웃을 컨트롤
- unlocks_controller.rb : 이 컨트롤의 기능은 무엇인지 잘 모르겠다. To be defined..

그리고 최고의 반전. 두고보자.

## 2012.1.11 updated

이에 대한 해결 방법은…

1) db 연결 ->  user 테이블의 값을 삭제하고 users/sign_up, sign_in을 해보면 제대로 실행된다. 연결에는 문제 없음

2) 쿼리 결과를 못가져온다 – insert는 된다, 그 이후에 select 해오는 결과를 못가져와서 처리가 못되는 것  같다.

• 위에서 보면 select 의 결과가 있음에도 불구하고 localhost:3000으로 redirect 해버린다…why?

• 정상적인 결과는 위와 같다. 즉, route -> controller -> model -> db query -> model -> viewer

• 정상적인 sign_in 실행결과는 위와 같다.
• config/initializers/devise.rb의 config.sign_out_via 의 값을 get으로 변경했을떄 sign_up, sign_in이 동작하고 sign_out은 이전과 같이 redirect되었다

위의 결과로 유추해볼때,
http request와 sign in/out의 type의 방법이 무언가 충돌이 있어 보인다.  이와 관련해서는 좀더 찾아볼 필요가 있음. 이와 관련하여 Stackoverflow의 링크를 참고(클릭)

3) 라우트, 세션에 문제가 있다 -> 결국 2번의 문제 해결을 위하여 취한 방법들은 route의 문제는 아닌 것 같고 세션과 관련하여 처리가 되지 않아 home#index로 처리가 되는 것을 보임

추가적으로, 혹시 devise가 ruby, rails버젼에 문제가 있을 수도 있으니 이에 대해서도 확인할 필요가 있음
-> Ruby 1.9.2, Rails 3.1.3

그러나,,,,
생각보다 진행이 쉽지 않다보니 자꾸 갈팡질팡 하는 것 같다. 얼른 테스트를 마쳐야지.

새벽까지 지켜봤던 그의 인생과 삶에 대한 도전에… 정말 몸서리가 치는 것 같다.

http://bit.ly/aIhhnb

주변사람들과도 즐거운 관계를 유지하면서도 편협된 시각을 가지지 않고 한걸음 한걸음 내길을 가고 싶다.

I would like to say a resolution in 2012:

- I very hope that what I want to do would be achieved, keep wonderful relation with people around me, make balanced view of point, and go for those things as steping stones on my way.

소위말하는 IT 바즈니스는 위와 같은 세가지 모습을 띈다.
- contents oriented : partner leadership
- platform oriented : marketing&partner leadership
- funtion oriented : product leadership