2007年10月24日 星期三

更新至Wordpress 2.3

似乎終於願意開放tinymce的功能了,原本就有,不知道為啥一直不給用,得自己改。加上這次啟用了多個加速功能,包括mysql query cache,eaccelarator,wordpress 內建快取等,有些頁面的回應速度終於降到了1秒以下,連另一個站的wiki也快很多。老是在寫追求高效能的web application,連自己對秒速的感覺也變得遲鈍。現在都會希望要求東西在1秒內就要出來,1秒以上的也不要在連續的操作裡出現太多次。

加上了Challenge,雖然有點不方便,不過spam真的太猖獗,沒辦法。本來就有裝akismet,後來還換了domain name也沒啥用,一下子又變成一天幾十個。本來是想要換布景主題的,不過看來看去怎麼還是這個最好看。

目前還是持續在寫有關SRB與DataGrid的文章,越來越多學校的同學們(被迫)加入研究datagrid,這是一種趨勢嗎?不過說真的的我是很相信整合是一種趨勢沒錯。但問題還是在於

  • 太少Unix技術訓練,大學以上的教授大多都認為會用這是理所當然的,實際上他們自己都不會用,更何況會教或引導學生?

  • 應用範圍的研究方向偏多。其實這本來就反映出DataGrid的本質,只是在台灣大家不管做啥論文都還是會希望有個演算法,才能「看起來」有點料,所以很多人都還是做Replica問題的,卻又因為這跟datagrid相關而又得乖乖地來接觸SRB。

  • 沒有真正有商業價值的應用。SRB賣給Nirvana之後,這家公司便出了很多「企業」專用方案,乍看之下確實功能強大,而且符合可擴充的需求,實際呢?究竟有多少企業真的選擇SRB做為整體性的解決方案?而其他Grid計畫,某些層面不見得是要拿來賺錢用的,不能夠相提並論。

  • 有資料典藏的方案,可是尚未顯示其價值。很多地方都在做資料典藏,著名的internet archive,收集了自從創立以來網路上所有能夠找到的網頁。這些計畫一定需要大容量可擴充可容錯的儲存,但存了一堆東西,也沒有一個人感受到這與自己生活有啥關係。


這幾點,對我個人看見的現象相當地明顯。有的人希望DataGrid是一個超大FTP,有的人希望他是anywhere access,有的人希望這可以超越世界上任何一種儲存的速度。但沒有一個人真的瞭解DataGrid在做啥,目的又是什麼。正如同很多人也不瞭解Grid是要幹嘛。對Grid來說,整合這件事應該是要同時帶來方便性和速度。但實際上我們也看見很多例子說明,整合只會更慢。

對於長久做Grid計畫的我而言,整合是一種痛苦,代表各校各自表述卻又不得不聚在一起凹出一個東西。整合只會讓權力更大的人握有更多的東西,而並不見得會對民生或是一般人常用帶來啥益處。為什麼整合會成這個樣子?也充分地表現出社會的運作。我想真正的整合是大家一起尋找出眾人都能得到利益,卻能夠維持原本特定型態網路運作的途徑。

舉例說,以前驢子出了很多Mod,有的是為了有趣,有的是為了站方(或站務群)的個人利益。實際上一直到今年,我所看到的還是維持大眾利益的站活了下來。像我常去的m-team這種型態的就是例子,儘管不多,我也依然在用自己的方式貢獻流量或是發個文章。確實,站方說自己辛不辛苦我們不會知道,不過如果正確地找到方向,不輕易違背諾言,不輕易放棄使用者,那又有什麼站會因為人數太少而倒?辛蒂關站的時候,包括我在內不知道有多少人嚷著要捐錢。對很多人來說,使用者便利,習慣是讓他們貢獻自己手上金錢的主因,因為這對他們來說是價值,最後當然還是得稱讚長期努力的站務群。

做了幾年計畫,雖然也沒啥貢獻,也不敢說做了什麼好東西,可是真的還讓我覺得滿無聊的。問題並沒有得到好的解決,可是講的人卻可以講的口沫橫飛,聽的人則多半是在台下說「這也不怎樣」,但也未見其提出好或不好在哪。帶頭的人總是有著太多的理想,底下的學生總是做的半死。直到我開始在軟體公司工作了,雖然以上情境沒啥不同,才發現其實心境有很大的不同。至少我的想法比較接近雙贏,不再是做一個要求使用者改變習慣的東西了,也不會不顧自己總是做白工,而無法思考獲利的方式。

不過套一句我的老師說的話,「研究就是這樣」,可能現在的我也是在夢想與現實中尋找一些路吧。

2007年9月26日 星期三

Single Page Application - 下一代的Web應用程式

在Web Service, Ajax, Web 2.0, REST等Web應用與技術話題熱潮,帶動許多第二代的Web開發技術成長之後,這些話題也漸漸地消退。不過許多人可能不曾發現,其實這些技術名詞,是在慢慢地顯露一點:Web應用程式逐漸從Server Side轉移到Client Side,也就是瀏覽器身上。

本篇文章要從以往的Server Side Web應用程式,其開發方式與演進來介紹Single Page Application(SPA) 與現今所有主流Web技術。

我在Web 2.0過去,現在與未來及介紹Ruby On Rails都有提到一些Web技術的演進,比較明顯的趨勢就是從靜態到動態頁面,而設計的方式也更程式化。而在http://atedev.wordpress.com/2007/01/09/Web2.0:過去,現在及未來也有讀者在前言提到,技術並不是將一個名詞安上去就好。我相當贊同這句話,因此也在這篇文章中希望來做個總整理,以技術及歷史來看看Web是怎樣成長的。

Web應用程式的演進


動態網頁


儘管Web並不是一個三言兩語能拿個版本號碼來解釋,但實際上Web技術確實有些明顯的分隔點。

最早期我們熟知的就是靜態網頁,這應該沒啥問題。儘管在2000前,php,asp就開始流行,坊間的書上也都稱之為動態網頁。而我在此提及的動態網頁程式,實際上卻是從php4釋出的那一年開始(註釋)。這邊要讓大家瞭解的分界點,其實是php4開始被許多商業公司所採用,而軟體的形式也更為套裝化,而不再像之前大家認定的「動態」網頁僅僅只是拿來完成一些簡單的區塊來與一般的靜態網頁整合。


在2004年的時候,Web Framework的產生,創造了Web應用程式另一個新的高峰。而在這個時候也開始有一些Rich Web Client概念的雛形了。我將Ruby On Rails定為一個分界點是因為,他顛覆了傳統動態網頁還在使用設計方式,而改用MVC。但要注意的是Ruby On Rails儘管整合了Ajax與進階Javascript函式庫,但還是沒有改變回傳完整或部分HTML的方式,意思便是HTML的產生始終在Server Side。

2007年9月2日 星期日

Ruby on Rails 與 ruby-postgres

ruby-postgres

有網友與我提出Rails與PostgreSQL的問題,我就順便寫一下有關PostgreSQL的問題好了。

安裝的方式請參考

http://postgresql-chinese.blogspot.com/2007/08/windowsrailspostgresql.html

不過我在這邊順便補充,其實當初會捨棄postgres-pr還是因為效能的問題,native binding終究是比較快的。

在此先對新手說明一個觀念,如果你想一步一步玩熟Rails,最好還是多善用ruby script/console來進入Console mode。而Console其實也只是呼叫irb去載入environments.rb,這個檔案會陸續載入plugin, model及你指定在environments.rb寫的所有require。Console有兩個用途,一個是測試是否你能正常啟動Rails,第二個是測試你的Model是否正常,例如測試association。而如果console都啟動失敗,或是Model.find出來的都不是想要的,那真正啟動mongrel去跑頁面是一定不可能是對的。

而許多在windows上面安裝的人一定會遇到函式庫載入失敗的問題。 要注意的是,安裝任何mswin32的gem都是有可能出現這樣的問題的。這個時候如果你是去看rails的development.log或是看到exception,通常都還是會說是driver有問題(可能會是xxx.so載入失敗之類的),這樣是看不出來的。此時使用console,一啟動的時候他就會告訴你是啥dll無法載入。

而大家使用ruby-postgres,如果不安裝PostgreSQL Server Win32,有幾個重要的dll是不會被載入到windows裡的。這個使用請先安裝PGAdmin III,然後將他的安裝目錄裡的libpq.dll,iconv.dll,krb5_32.dll,libiconv-2.dll,libintl-2.dll,comerr32.dll至你的ruby安裝目錄下的bin即可,還是一樣先試試console能不能開吧!

Ruby的很多Win32函式庫都是用這種binding的方式,而並非是使用ruby撰寫而成的。所以如果今天是發現gettext不能用,就應該要去尋找gettext win32,然後將缺的dll複製到bin下即可。

該如何發問?

最近在論壇觀察了一下,發現Rails新手的朋友們,應該要接受一些觀念建立,以免回答的人答非所問。既然我遇到人來問問題(還好不是來踢館),也免不了要提倡一下,這觀念在任何一種程式語言都適用。

  • 詳述問題:想要讓人瞭解問題,就是要說明你的目的,及你在發問之前曾經做了什麼。如果不是技術上的問題,例如是求函式庫,求解法,那更要說明清楚前因後果。

  • 有Exception訊息的要貼exception:Rails當發生任何錯誤的時候,就一定是大家所熟知的畫面,「{ErrorName} in {Controller#action}」。接著就是貼ErrorName,以及下面灰色區塊裡的描述。第二個灰色區塊就是trace,如果可以的話,請 複製5~10行,如果是寄信,或發文可以不受篇幅影響,全部貼上來也無所謂。不然可是沒有人知道你在問啥的喔~

  • 有畫面的請貼畫面:如果是ajax,html等其他UI上的疑難雜症,就一定要貼畫面了。然而是複雜難以解的問題,就要請你去用用fiddler了。例如有看過google maps不能用的問題,其實後來深入一看其實就是referer被擋的問題,這種狀況應該要詳細貼出http request及response,才能讓解答的人知道是啥狀況。

2007年8月29日 星期三

我使用過的Ruby Library或Rails Plugin

Ruby Library:

  • REXML。寫XML的話也沒有別的更好用了 http://www.germane-software.com/software/rexml/

  • ROXML。這個可能對我自己的特殊應用比較有意義吧,如果是撰寫standalone rails app而又不想用sqlite的話,其實另一個選擇就是效能更好的XML Database。但是在這個技術尚未真正成熟的情況下,XQuery + ROXML也是不錯的選擇。http://roxml.rubyforge.org/

  • Gettext。這個真是牌子老信用好的東西,不過我或許還會想要選擇用更簡單語法撰寫語系檔的函式庫。http://manuals.rubyonrails.com/read/chapter/105

  • Ruport。一剛開始接觸Rails的時候還以為會像php一樣報表函式庫一直都沒有高度整合性的,心裡最想用的大概會是有點像crystal report吧。不過好在有這個,已經相當完整了,pdf,cvs該有的都有,使用上也很方便。http://rubyreports.org/

  • Chart Director。這個雖然是商業的,圖的顏色也不是挺漂亮的,不過因為想要畫的圖比較複雜只好勉為其難。

  • UUIDTools。這個也是特殊應用,有可能你對一筆資料所對應的URL想要複雜到讓使用者無法猜,或是想要試試看分散式資料庫,或許你會需要這個。http://www.cnblogs.com/funjackyone/archive/2007/06/01/768275.html

  • RJB。雖然jruby內建連結java的語法相當直接,不過jmongrel+rails的效能可不敢想像,我看我還是耐心的等到明年好了。可是我的專案還是得整合Java...唉,這個時候還是乖乖靠這個老牌子吧。http://rjb.rubyforge.org/


Rails Plugin:

2007年8月27日 星期一

Heartbeat 2.0



在商業服務的Rails HTTP Cluster觀念及測試中,我提到了failover也是cluster的其中一個觀念。幾年前我用heartbeat,只是單純架設pgcluster的load balancer,那個時候也是簡單的active / standby。在那個時候,有這樣的架構已經減輕大部分人所遇到的問題:有一台掛掉另一台可以馬上取代其服務,讓維護者有時間可以救,使用者不會罵,已經是很偷笑的事情了。不然一般的維護者可能要急得像熱鍋上的螞蟻,拼命地輸入指令試著想要拯救資料或服務,而在數小時的工作後,服務還是救不起來,使用者罵聲四起。但是其實對我而言,這些比起硬體的方案,還是多多少少嫌不方便。

參考這個網頁,可以瞭解有那些failover的方式。
http://www.ukingdom.com.tw/pro/lifekeeper/lifekeeper.htm

先不管後面的階層化或是多方向failover,其中提到的active/active及active/standby,為啥要有這些分別呢?我來一個一個介紹。


這一個月來的Google Analytics

好吧,我承認我有發現,其實大家想要看unix的東西有比rails的還要多。這個呢 ....孤狗大神的分析器有告訴我:

blog-keyword.JPG

我只能夠說我感謝大家的抬愛,不過很可惜的是,我可能不會再寫有關php的文章了。
讓我驚訝的是,centos及heartbeat竟然是這樣熱門的話題!
最近才剛完成了full-failover的heartbeat 2.0+rails cluster架設,或許趁記憶還新的時候,趕快再來寫一篇吧。

不過其實只要還有人願意看我的文章我就很高興了啦~^^

2007年8月19日 星期日

商業服務的Ruby on Rails HTTP Cluster觀念及測試

Rails如果運用在正式上線的服務,便是相當需要配置為Cluster(叢集)服務。不過大部分使用Rails來建立Cluster通常都是藉著Apache mod_proxy,但在一些情況之下,他只有好設定的優點而已。另一種方式是利用一些Plugin及設定去模擬Cluster的行為,不過這樣便是消耗CPU的時間。

網路上可以看見許多Cluster的文章,但多半都是介紹單方面的功能,或是許多實做的細節牽扯在一起。這篇文章用商業服務的整體規劃來看Cluster及Rails之間的種種問題與解決方法。文章後面附帶了一節是要解釋如何解讀apache menchmark的數據。而各位如果想要瞭解的是效能,數據上的差異,已經有一篇相當棒的可以參考:
http://blog.kovyrin.net/2006/08/28/ruby-performance-results/