ruby on rails가 20분만에 블로그만들면 1주일 또는 1개월안에 프로젝트를 끝내게 할 수 있는가

ggokka의 이미지

ruby on rails가 20분만에 블로그 만들기를 캐치플레이즈로 작년이후로 반향을 일으키고 있다

하지만 자바의 하이버네이트의 연장선상에 있는 DB Table당 1:1 웹페이지 맵핑(정확히는 3개 즉 list , update , insert)은 근본적으로 한계가 있다. 테스트 페이지말고 Table당 1:1로 맵핑되는 웹페이지가 유용한데가 얼마나 있을까?

당장 이 kldp 페이지만 보더라도 얼마나 많은 part들로 구성되어있는지 알 수 있다.
기업의 인트라넷내부에서 쓰는 업무용 웹어플리케이션들도 포탈처럼 데이타소스가 복잡한 마당에 Table당 1:1모델이라니 심히 의심되지 않을수 없다.

게다가 mdb로 커버되는 간단한 구조말고 sql에 조인이 쓰이지 않는 경우가 있는지 모르겠다. ror가 조인을 지원하던가? 이부분은 더 공부해보지 않아서 모르겠지만 조금이라도 복잡한 방식으로 지원한다던가 하면 20분만에 **만들기 모델은 물건너가는거다.

ror도 ruby언어로 만들어진 웹페이지가 제작용 프레임웍의 하나 인데 모든 프레임웍에는 조심해야 될게 하나 있다. 그 프레임웍이 제시하는 패턴이상을 넘어서는 기능을 적용하고자 한다면 아예 그 프레임웍을 버리는게 더 좋을것이라는 점이다.

닷넷으로 만들어진 웹페이지 제작용 프로레임웍이 바로 ASP.NET이다. 자바의 JSF와 동일한 이 기능은 빠른 웹페이지 제작을 위한 나왔다. 하지만 내가 보기에 ASP.NET의 상태유지모델(viewstate=true)과 스마트네비게이션(자동 iframe생성후 웹페이지의 일부만 reflash해서 속도를 향샹)은 실패한 케이스다. 왜냐하면 이것들을 도입해서 당장얻는 빠른 개발이나 빠른 속도보다 그 후에 발생하는 관리상의 문제 즉 빠른 유지보수와 소스 가독성 등등에서는 아주 치명적이기 때문이다.

모든 IT관련 프로젝트가 마찬가지이지만 사이트 개발 프로젝트는 지나치게 비효율적이다. 요즘 웹프로젝트를 빠르게 끝내면서도 유지보수가 쉬운 방법을 찾고 있다. 이미 CSS와 웹서비스는 확정적인데 ROR는 자꾸만 회의적으로 기울고 있다.

여러분들의 생각은 어떠하신지요

ed.netdiver의 이미지

저는 별로 개념이 없습니다만, 여기 연관된 글이 있어 적어봅니다. :)
http://agile.egloos.com/1543742

\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

1day1의 이미지

프레임웍이란것이 모든 사항을 완벽하게 처리하기에는 2%부족한 부분이 있기 마련이죠.
그런것들을 해결하면서 프레임웍이 진화(?)하는 것이겠죠.

ROR 을 자세히 살펴보지는 않았지만, 말씀하신 부분에 대한 해결책을 마련하고 있지 않을까요?

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

이한길의 이미지

동감하는 이야기입니다...만...
아직 제대로 된 경험이 없어서 적극적으로..
이렇다 저렇다고 말할 처지가 못되서 ... 뭐라는 못하겠습니다.

경험 있으신 분들의 이야기가 듣고 싶은데요...

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

직접 SQL 쿼리를 날릴 수 있는데요?
그리고 한 페이지에서 여러개의 모델에 접근하는 것도 가능하구요.

ggokka의 이미지

아직 제가 내공이 부족해서요.

익명사용자의 이미지

class Artist < ActiveRecord::Base
has_many :songs, :order => "song_title", :dependent => true
has_many :albums, :order => "album_name", :dependent => true

def self.find_by_first_letter(letter = “A”)
find_by_sql [”select * from artists where ucase(left(artist_name, 1)) = ?”, letter]
end
end

조윤배의 이미지

ASP.NET 1.1의 SmartNavigation이야 버그가 있어서 어느 누구도 안쓰고 있을겁니다. 반면에 ViewState는 데이터를 주거니 받거니, Postback이 여러차레 일어나는 Application 경향의 웹페이지에서 아주 편리하게 사용하고 있는 기능입니다.

DataGrid 와 같은 rich control에서 뱉어내는 ViewState의 양이 너무나 많아서 골치아프시다고요?
postback 할 일이 없다면 DataGrid의 ViewState를 꺼버리는게 올바른 사용법이죠.. :)

'올바른 사용법' 이라는 ViewState의 용도와 한계를 알고나면, 상당히 편리한 프레임워크의 일부라고 생각합니다.
(저는 2002년부터 계속해서 ASP.NET 으로 개발을 하고 있습니다)

creativeidler의 이미지

80/20 법칙으로 생각하면 될 듯 합니다. 프로젝트를 하다보면 80%의 일은 거의 프레임웍 하나로 완전히 커버가 됩니다. 하지만 그 프레임웍으로 커버 안되는 20%가 꼭 있죠. 그렇다고 전체를 커버할 수 있는 프레임웍을 만들면 프레임웍이 너무 복잡하고 커지고 또 그렇다고 프레임웍 없이 하면 80%에서 얻을 수 있는 이득이 아쉽죠.

이럴 땐 Perl의 방식이 좋은 것 같습니다. 쉬운 일은 쉽게, 어려운 일도 그럭저럭 할만하게. 프레임웍으로 쉽게 할 수 있는 일은 그냥 쉽게 하고 프레임웍으로 안되는 일은 수작업 좀 하고.

RoR로 할 수 있는 일은 그냥 RoR로 하고 안되는 일은 그냥 직접 만들고. 일관성 때문에 정작 중요한 생산성을 희생할 필요는 없겠죠.

근데 사실 RoR의 생산성은 RoR보다도 Ruby에서 오는 것입니다. RoR 자체만 보면 Hibernate에다가 프레임웍 잘 갖다 붙인 자바만도 못합니다만 Ruby 자체의 생산성이 워낙 자바를 압도하기 때문에 RoR의 생산성이 높은 것이죠.

나부군의 이미지

제가 ror을 처음보고 가장 놀랐던게

"DB와 이렇게 엘레강스하게 연동할 수 있다니!!!

였습니다.

has_one
has_many
belongs_to_many
has_and_belongs_to_many

모두 지원하는 것으로 알고있습니다.

herblover의 이미지

Agile Web Development with Rails라는 책을 한번 보시는 것을 추천합니다.
일단 저 부터도, RoR쪽에 회의적인 생각을 가지고 있다가, 저 책을 옆에 끼고 개인적으로 프로젝트를 하나 진행해 보고 있습니다.

일단 말씀하신 부분은 주로 ActiveRecord쪽에 관련된 이야기가 많은듯 한데요.
http://wiki.rubyonrails.org 에 관련 부분이 설명되어 있을 겁니다.
내부적 구현이 아닌, RoR 사용자 입장에서 어떻게 쓸 수 있는지에 관한 이야기라면 http://wiki.rubyonrails.org/rails/pages/HowtosDatabase 이 부분을 한번 보시면 되겠네요.

has_one, has_many... 등과 같은 기본적인 관계와, 단일 테이블 내에서 Tree를 표현하기 위한 acts_as_tree등의 좀 복잡한 관계까지 지원하고 있습니다.

사실, RoR에 대한 제 입장은 간단합니다.

"당신의 프로젝트를 RoR을 이용해서 만든 것 보다 빨리 만들 수 있다면 굳이 RoR을 보실 필요 없습니다."

RoR보다 "잘"만든다는 의미가 아니죠. 사실 코드의 질에 대해서는 좀 더 들여다 봐야 할 듯 해서요. 코드가 질이 좋은지는.. 아직 크게 와 닿지는 않습니다.
다만, "빨리"만든다는 것 자체만으로도 큰 의미가 있다고 생각하기에, 대체 뭐가 다르기에 "빨리"만들 수 있는지, 그렇다면 그걸 다른 부분에 적용해 볼 수 없는지(다른 언어, 다른 환경, 기타 모든 것을 의미합니다.)를 고민해 보기 위해서 이것저것 해 보고 있습니다.

RoR이 주류가 될 수 있는지 없는지에 대해서는 해외에서도 말이 많더군요. 그 논의에 나왔던 이야기들 중에 저와 비슷한 견해가 꽤 있었습니다.

"굳이 주류가 될 필요가 있는가?"

라는 부분이죠. 굳이 주류가 될 필요가 있을지.. 저는 잘 모르겠습니다. RoR로 충분하면 RoR을 쓰면 그만. 그걸로 안된다고 판단한다면 다른 것을 쓰면 그만이니까요.

다만, 개인적으로 믿고 있는 부분은, RoR을 본 사람과 보지 않은 사람간에는 분명한 차이가 존재할 것이라는 점입니다. RoR은 최소한 그정도의 가치는 있다고 생각합니다.

kkj의 이미지

실력이 안되는데 연장만 탓하는걸로 보이네요

maddie의 이미지

초기 개발 당시에 분석과 구조를 잡는 것이 가장 중요한 것 같습니다.
프레임워크를 이용해야 한다면 프레임 워크에 맞추어 구조와 서비스를 구성하면 되겠죠.

초기에 분석이나 구조를 잘못 잡으면.. 프레임워크에 벗어나는 것이 필요하게 되고... 결국 짬뽕이 되어 버리는 것 아닌가요?

뭐 그런 생각이 듭니다.

힘없는자의 슬픔

힘없는자의 슬픔

anarcher의 이미지

RoR이나 Django나의 FW에서의 20~10분만에 블로그,위키 만들기는
사실... 사기이긴 합니다... 메소드와 디비를 이미 다 외어서 치는 거니까.
그렇긴 하죠..
RDB에서 join없는 건 사실 생각할수 없고,Ormap이 퀴리보다 표현력이 좋을수는 없겠죠..갠적인 생각입니다.
SQL이 30년이 넘은 역사를 가진거 보면.. oracle이 처음 79년도에 첫 버젼을 출시했다고 하더군요...

종종 추상화는 유연성이 떨어지는게 당연한거 아닌가 하는 생각이 듭니다..
좋은 FW는 좋은 추상화와 그 하위 레벨도 프레임워크 디자인이 틀어지지 않게 사용할수 있도록 해주는 걸 말하는거 아닐까 싶습니다.

lazycoder의 이미지


요즘 트렌드는;; 코딩은 더 적게하고 미리 정해진 컨벤션을 따르면 무언가 뚝딱 나오는게끔 해야하는게 아닌가 싶으네요.
ror이 거기에 딱 들어맞아서 인기를 끄는게 아닌가 합니다.

어떤 프레임워크을 도입하던지간에 사용하려는 프레임워크가 적합한지 안한지를 판단할수있어야 하는데
그런 능력이 부족해서 프로젝트 진행중에 큰 벽에 부딪쳐버리는게 아닐까 하는 걱정 큽니다.
mvc, mvp 모델이 만능키는 아닐테고 분명 어떤 부분에선 비효율적임에도 컨벤션을 따르기위해
끼워맞추기식 코딩을 해야 할꺼라 보거든요.

전 지금은 CAB(Microsoft CompositeUI Application Block) 이라고하는 이름도 허벌나게 긴
프레임워크를 보고있는데 웹개발 프레임워크와 유사하지만 스마트클라이언트(윈폼)를 개발하는데 괜찮아 보입니다.
지금까지 본 프레임워크중에(몇개되지도 않는다만-_-) 가장 어렵군요.
외국 포럼에 올라온 글을 봐도 몇주가 걸렸다느니 영어권 사람도 어렵다고 할 정도니 엄살은 아닌겝니다.

현재 프로젝트에 ror을 사용할 수 있다는것은 게으른 개발자에겐 어쩌면 기회이자 복일지도 모릅니다.
ror은 제가 잘 몰라도 그런 패턴을 가지는 프레임워크는 코딩 과정이라 할수있는 컨벤션만 잘 따라준다면
가끔은 틀이 답답하고 비효율적이라고 느껴질지언정 코딩은 노가다야 라는 생각은 줄어들것 같습니다.
이건 생산성과도 밀접한 관련이 있지요.
코딩 한줄한줄 할때마다 어떻게짜야할까 고민하게 되지 않던가요?
이제 그런 고민하지말고 시키는대로 정해진 패턴에따라 코드를 작성하면 원하는 프로그램이 뚝딱 나오게
해주겠다하니 얼마나 좋은겁니까.. 저도 배우고 싶어요.

keizie의 이미지

http://developer.yahoo.com/yui/ 는 자바스크립트로 사이트에 필요한 각종 모양과 기능을 처리하는 라이브러리입니다. 요즘 이걸 써서 일을 하고 있는데 GTK+ 쓰는 기분이라 꽤 익숙합니다.

이걸 굳이 쓰게 된 이유는 자바스크립트로 일일이 뭘 짜는 게 귀찮아서이기도 하고, 제가 없을 때에도 여기서 제시하는 구조를 따라가면 누구라도 코드를 이해하고 결과를 도출할 수 있게 하기 위해서입니다. 고수분들이야 자기가 직접 소규모 프레임워크를 만들고 그 안에서 룰을 정해서 개발팀과 공유할 수 있겠지만 저처럼 얼렁뚱땅 하는 사람은 직접 뭘 해봐야 기성품 쓰는만큼의 효율을 낼 수가 없거든요.

그런 맥락에서, 전에는 레일즈니 장고니 하는 것을 그냥 풍문으로만 듣고 별 판단을 하지 않았는데 점점 호감이 갑니다.

시렌의 이미지

아, 이런 곳도 있었군요.
또 다른 곳은 없나요? 국내 포털은 이런게 없나요?

my blog: http://www.siren99.net

spyrogira256의 이미지

http://www.methodchain.com/
이 있습니다.
포럼은 아니지만 국내에서 만든 yui 와 같은 javascript framework 입니다.

wooil의 이미지

ror을 이용해 한 달 만에 만들어진 사이트 - http://wellee.com/ - 가 있습니다. 물론 개발자가 프레임워크에 얼마나 숙련되어 있는지도 중요한 것 같습니다.

ydhoney의 이미지

개발자 입장에서는 만드는게 빠르고 빠르게 적용할수 있는게 좋기야 하겠습니다만, SE입장에서 보면 성급하게 만들어 질 수록 고쳐야 할 점 역시 많아진다는 점이 걸리더군요. 물론 빨리 만들고 역시나 빨리 수정하면 좋기야 하겠습니다만 그것은 이상에 지나지 않는 경우가 많구요. 오히려 천천히 심사숙고해서 오랜 기간동안 만들어진, 그렇게 만들어질 수 밖에 없는 녀석들이 실제로 시스템 운영상에 있어서는 충분한 안정성과 성능을 보이는 경우가 많았습니다.

아직 실제로 국내외적으로 루비로 이루어 진 사이트들을 운영해 본 엔지니어들이 없으니 실제 상용 서비스에 적용한다는 생각을 가지고 한다면..예기치 못한 상황에 대해서 루비 사용자분들은 어떻게 대처하게 될 지 궁금하군요. 실제로 마땅한 사례도 그리 많지 않을테고 말이지요.

그래도 짧은 스크립트는 빠르게 bash/python으로 간단하게..=3=33

아 그리고 주류성이요? 글쎄요? 그럴 필요도 없고 그러지도 못할것 같은데 말이지요. 적어도 10년 이내로 지금의 파이썬 자리까지 오르기는 힘들 거라고 예상하고 있습니다.

==
아 씨끄러 씨끄러~ 조용해!!
레드햇 9 이하 사용금지!

hey의 이미지

음. 지금 네오위즈(여긴 JRuby), 오픈마루에서 RoR을 이용한 상업용 코드가 작성되고 있습니다. 작은 회사쪽에선 더 되는거 같은데 잘 모르겠고요. http://wellee.com/ 같은 곳은 한달만에 만들어졌다고 하더군요.

천천히 심사숙고해서 오랜 기간 동안 만들어진 놈들은 물론 안정성은 좋겠지만 기획 변경에 대응할 수 없을 정도만이 아니라, 기획 변경을 불가능하도록 한다는 데에 문제가 있습니다. 요즘같은 세상에 그렇게 일하기는 점점 힘들어지지요. :]

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


ydhoney의 이미지

집에서 좋은것(?)만 쏙쏙 골라서 다 보았답니다.

좋은 사이트를 알려주셔서 감사합니다. :-)

근데 좀 사이트가 느린 것 같아요? =_=;;

==
아 씨끄러 씨끄러~ 조용해!!
레드햇 9 이하 사용금지!

hey의 이미지

그러실 것 같았습니다. 낚시 말고 진짜 좋은 것 있던가요? ^_^

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


죠커의 이미지

저는 적어도 한국에서는 파이썬 보다는 루비가 더 가능성 있다고 생각합니다. 쟝고는 다들 몰라도 루비 온 레일스는 누구나 아니깐요.

- CN의 낙서장 / HanIRC:#CN

마잇의 이미지

실제 레일즈가 어떤 프레임웍인지 간단한 자료나 따라하기 정도의 내용도 안보시고 그냥 들리는 소문과 추측으로 작성하신 것 같습니다.

http://rubyonrails.org/docs

이곳에 간단한 튜터리얼이 링크되어 있습니다. 20분, 30분 이런 얘기는 '레일즈가 좋다 써봐라'라는 이야기를 살짝 과장해서 광고로 만든거라고 생각하시면 됩니다. 레일즈에 대해서 이해했고 만들려는 것 자체가 20분 동영상에 나오는 것 처럼 간단하다면 실제 20분만에 만들어집니다. 테이블 늘어나고 보여줄거 많아지고 그러면 당연히 20분안에 끝날수가 없겠죠.

비평을 하기전에 먼저 읽는 것은 기본입니다. 레일즈로 프로젝트 몇 개 해보고 이야기하자는 의도는 아닙니다. 가장 기초적인 특징은 알아보고 이야기하자는 취지입니다.

좀 과격하게 이야기하면 그냥 낚시글이거나 너무 잘못된 정보를 들으신 것 같습니다.

프레임웍이 제시하는 패턴 이상을 구현해야하는 경우라면 안쓰는 것이 좋다라는 의견은 공감합니다. 프레임웍이 제시하는 패턴과 설계가 적합한지, 현재 요구와 많은 공통점을 가지고 있는지 생각하고 사용해야겠죠.

--
마잇


--
마잇

Scarecrow의 이미지

비슷한 예를 생각해 보면 비주얼스투디오에 있는 마법사 같은 기능이라고 생각합니다.
비주얼스투디오에 보면 hello world같은 건 코드한 줄 안쓰고
마우스로 딸깍딸깍 선택만 해주면 탁 나옵니다.

백지에서 시작하는 것보다 매번 반복되는 수준의 그런건 자동화로 해결하자는 얘기이지
그것만 하면 프로그램이 완성된다라고 하진 않겠죠.

그 예제들은 자동화기능만으로도 많은 코드를
그러니까 바로 사용가능한 수준으로까지 만들어준다는 것을 보여주는 것이 아닐지요.

그걸 "사기"라고 하긴 뭐합니다.
그런 자동화 기능이 없는 것 보단 있는게 더 좋지 않을까요? ^^

시그너쳐: ./configure --prefix=/usr; make; sudo checkinstall

h4z3dic의 이미지

RoR에서 제공하는 메소드의 옵션들 만으로는 sql문을 대체할수 없기에
find_by_sql란 메소드를 제공해서 개발자가 직접 sql구문을 입력할 수 있게 해놓았습니다.

hal9k의 이미지

고객이 Scope를 건드리려고 하지 않나요? 소프트웨어 개발을 우습게 보는 사람들이 너무 많습니다. 닌텐도같은것 만들어 봐라, 트위터를 200자로 늘리자 라고 하는 분과 같은 고객들이 많습니다.

bookgekgom의 이미지

제가 이번에 레일즈로 웹사이트를 만들면서 느낀건데...

sql? 알필요 없죠.
ajax? 너무 쉬워서 웃음이...

여튼, 모든것이 다 구현이 쉬워도

디자인을 못만들면 말짱 헛거라는거...

-_- php 나 jsp 나 asp 나 rails 나

그 놈들이 멀할수있는가를 따지고 고르는것은

일단 홈페이지의 모든 디자인이 완성된후 인것입니다.

일단은 드림위버를 잘쓸줄 알아야하는것 같음...

제가 웹 디자이너 였다면 일주일에 아주 멋진 사이트를 만들었을것 같네요.

결론은 멀로 만들어도 저처럼 디자인을 모르면 허접한 사이트가 탄생함 ㅇㅇ
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다. 와서 받으삼.

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

free21k의 이미지

ruby on rails가 20분만에 블로그만들면 1주일 또는 1개월안에 프로젝트를 끝내게 할 수 있는가?
=> 결론부터 이야기 하자면 'No'입니다.

제가 다니는 회사에서 이미 제가 담당한 루비, 레일즈 프로젝트는 모두 3개입니다. 제가 참여한 프로젝트가 4개이니, 75%가 되네요.

모든 부분을 루비만으로는 진행이 불가능합니다.

다만, 코어부분이나, 속도에서 민감한 부분을 C, C++로 구현해 놓으면 나머지 부분은 루비로 그냥 끄적이면 됩니다.

정말 간단하죠.

언급하신 DB 관련 부분은 액티브 레코드를 사용하는 걸 말씀하시나 본데, 제가 진행했던 프로젝트 중 1개는 액티브 레코드일부만 사용하고, 루비에서 제공하는 기본 라이브러리를 이용하여 커스텀으로 db접근을 하였습니다.

이부분은 커스텀으로 db접근을 하는 부분은 속도에 민감한 부분에만 적용을 했습니다.

제가 진행했던 3개의 프로젝트 모두 프로젝트 진행기간을 C, C++, java로 책정했던 기간보다 개발기간을 30~40%정도 단축했습니다.

프로젝트를 1주일, 1달만에 끝낼 수는 없지만, 개발기간을 단축하는데는 문제가 없던 것 같군요.

==================================
루비 개발자.

==================================
당신은 당신의 꿈을 위해 무엇을 희생하였나요?