您在這裡

首頁 » Forums » 綜合討論 » 閒話家常討論

hemidemi by drupal or RoR?

drakeguan's 的頭像
由 drakeguan 在 2006-11-13 (週一) 16:39 發表

剛剛想到一件事。

前一陣子得知 HemiDemi 背後只有兩到三人，並不是一個公司在推的，感覺有點意外，也挺興奮的。同時，又得知他們是使用 Ruby on Rails 來開發的（徵人啟事上寫的 XD），讓我開始在想「如果要開發一個 del.icio.us, digg, flickr, hemidemi like 的 web 2.0 service，倒底是使用 Drupal 來寫比較 ok，還是使用 RoR 比較好?」

然後我發現，這個問題問得太模糊也不精確，但也因此似乎怎麼樣的看法都可以討論和聊的樣子，就 po 上來，問問大家的看法 :)

ps. 我不會 Ruby，不會 Rails framework，所以更不會 Ruby on Rails :)

看你碰哪個比較熟吧....

我是覺得，ror太少人了... 東西是不錯，不過求助會無援～
drupal的缺點是js的支援不夠，就現有4.7版本，ajax還有點遜
5.0的關鍵是，納入了jquery~ 人少的情況，國外的社群倒是滿強壯的，什麼都有人幹，這是滿好的資源。

* * *

我是這麼想，ROR是一堆零組件，你可以自己隨意兜起來成為自己想要的東西，也因此他的彈性和效率或許都會比較好。

drupal不只是零組件，他雖然提供了一點零組件，但卻沒有ROR好，但是他提供了一些重點部位，像是汽車的「引擎」、輪胎，座椅... 所以要上路會快一些。

drupal缺點就是，要做到ROR那樣的彈性，可以說是不可能...但優點就是缺點。

如果自己設計不出一個很好很好的架構，讓站可以長久的經營和擴增（即使用ROR也可能會亂七八糟），如果站上很需要管理介面（那些是時間成本），如果ROR的學習成本不想花... 那就用drupal來做吧。

--
from open mind to open source~

拿這兩個來比好像怪怪的，因為 RoR 是程式/架構，Drupal 已經是個 CMS 了，一般不都是拿 RoR 和 Java/PHP 來比，或是拿 Drupal 跟 Joomla/Plone/XOOPS比？

其實會寫程式的人不應該這樣比較，而是像我這樣不會寫程式、但又想搞些東西出來的，才會動腦筋到 Drupal 上。不然一般要做能提供特定服務/功能的網站，都是從無到有打造起吧，好像沒看過會以某種 CMS 為基礎。

也是有例外，例如這個用 XOOPS 做的類豆瓣網站：
http://www.yumau.com

也不盡然... 用CMS來做service的還是大有人在。
其實系統評估的基準點，不是CMS還是架構，而是時間。

用什麼方式可以節省現階段的時間，也節省未來的時間，就是一個好的方式。

自己兜的好處，就是只有自己會... 從註解到文件都要清楚，才有可能交接傳承，不一定會是個好考量～

--
from open mind to open source~

忘了回應一下了

我和 jimmy 的看法一樣，很多大型的網站也是有用 opensource 的 CMS 改出來的喔。而且是一定有改，只是改的方式不同（可能是直接改 core，或是新增一些 module 來做到）。

像是推薦 firefox 的 spreadfirefox 就是用 drupal；放了滿滿的 opensource project 的 sourceforge 是用自家的 cms；愈來愈大的 bsp wordpress.com 也是用自家的 wordpress mu；還有據說樂多的 blog 系統是改自 plog（現在叫 LifeType）；或是之前美國大選時，其中一位侯選人的造勢網站也是用 drupal（應該是沒記錯吧XD）。

不過我也不是很清楚，對於不擅長寫程式的人來說，到底哪一家的 cms 比較好用，這問題實在很難回答。不過我確定的是，看得懂官方文件與討論的人（就是英文 ok 的），一定比只會中文的人來得吃香太多的了 XD

或者說用 Ruby on Rails 開發一套 CMS ，再跟 Drupal 比，看看是不是能在很短的時間內寫出類似 Drupal, Joomla, XOOPS 之類的 CMS...

或許即將看到利用 ROR 特性的 CMS 吧~

如果沒有比上述的 CMS 好，或是有大的創新... 那好像多此一舉哩！

我現在注意的是，RoR 的「快速開發」與「高維護性」，似乎是它最厲害的兩把刀，所以如果分析的結果，覺得一個 web service 的這兩點是重點時，那似乎就得考慮它了?

btw, 其實我私下覺得，它不過就是一套在 web 上跑的，像 mfc, vsl 的 framework? 哈，當我亂說…

jimmy 說到一個重點，RoR 有的是彈性，代價是入手的學習曲線，所以這取決於你要做的事情的價值與經營時間的長短。

我最近要做的，是一個類似 hemedemi，但 content 不是 bookmark，而是一篇一篇推薦生活精品的文章，內文應該就是一張圖和簡短文字，然後呈現有美編可以幫忙設計，唯一少的，就是讓註冊的人可以有收藏（推薦?）的功能，和更重要的 web2.0 api，好讓他們能用在其它用途（ex, 他們自己的 blog 上頭的 wishlist）。

前半部可以透過 drupal 搞定，可能缺的，且不擅長的就 ajax 這一塊（當然，這是指技術的部分）。

charlesc 說得也挺有道理的，RoR 和 drupal 地位不太相等就是了，呵~~

ps. 我最近一直在想，怎麼都沒有美術背景出身，那種有良好的設計美感與創作能力的，同時也寫得出還算 ok 的 html+css 的…不然到頭來，programmer 要做的事，多且雜到一個不行，哈 ^^;;

架構還是重點吧....
就算用ROR弄一個CMS，也不一定會有像drupal一樣好的架構
資料結構、程式結構、模組擴展的結構..

不過開發drupal的經驗是，有些時候會綁手綁腳，不知道該不該修改核心的程式碼，或是有些既有的drupal方式，會考慮要不要重寫或是複寫～ 我想這就是有架構之後的缺點，有維護更新的問題。

不過比起其他CMS，drupal的核心/模組分層切割算是非常好的了。

ROR，在第一次開發階段，應該可以說是完全沒這種問題，但是當用ROR長程大到一個CMS的時候，也會面臨相同的問題。

* * *

缺AJAX的確是一個很大的問題，因為AJAX目前還很難搞，無論在開發、debug、還是後續的維護上，用AJAX而沒有適合library，一定會搞死人...
所以有想過如果有可能，是否可以backport 5.0裡頭的jsquery到4.7來用用看，或直接include jsquery進來寫了（反正他這麼lite...）。

* * *
DrakeGuan, 我也一直疑惑這樣的問題.... 後來我的答案是... 因為html、css是程式開發人員設計的... XD

--
from open mind to open source~

對於架構，我一直以來都以「盡量配合原有架構」的方式來做事，就是說，以不更動 core modules 的程式碼為原則，因為我過去多次經驗（加上打工時接的 case），都會因為動到 core modules 太多，導致事後的維護很可怕…

不過我對 RoR 還挺興致高昂的，有不少證據指出它的彈性（基於 Rails 的架構）與維護非常的好，不過這是建立在一個假設上：打一開始，所有的東西都是由 RoR 打造出來的，連資料庫也是，所以如果有現成的 database schema or even database records，要用 RoR 加上去有點難度。不過目前也僅止於觀望程度，畢竟 web service/ap programming 不是我的主業，呵~

ajax 的話，我正在查 drupal + dojo 的可能性。

看到最後一句，突然笑了出來 ^^;;

我現在正在研究怎麼栽培一位懂 html & css 的美工人員出來，這樣合作才比較有趣。

說到這，Mr.6 上頭的兩人創業中的兩人，指的是「創 意/業 家」與「程式設計師」，也許應該改成三人創業，多一位「美 術/編 with html/css skills」，哈~

剛剛花了點時間看ruby和ror，覺得還挺不錯，適合玩一玩～

不過我覺得你要做的事情，在drupal上面倒沒這麼複雜，可以花個幾天調整看看，就知道該不該用drupal，還是自己重新弄一套吧...

現階段drupal的form api或是一些部份要把ajax整合進去，也還沒這麼困難～只是需要時間就是了...

（關鍵好像就是，這段時間開發新的ajax，跟直接用ror的時間比起來，哪個比較快？）

--
from open mind to open source~