2011年4月30日

Proposal: Web Design Index Search Engine

Web Design Index》從2000年開始發行,至今已經邁入第九版,內容是收錄許多不同風格的網站畫面,提供相簿式的瀏覽,讓網頁設計師在構思版面時,可以快速找到一些參考資源。例如想製作一個美食的網站,想要一種讓人看了有「新鮮、美味、豐富」的感覺,就可以翻一下書,找些跟構想比較接近的站。

找到一些可以參考的網站,並不是要抄襲別人的作品,直接把HTML和CSS代碼照抄下來,是很不道德的做法;整理出一份清單,可以有許多幫助:
  • 如果是接案,把現有的網站畫面,挑選一些不錯的風格,給客戶參考,比較容易有效溝通,避免重複設計造成的成本。
  • 多看別人的作品,不管優缺點都可以幫助自己成長,看到好的設計,想想看自己是不是也能做到?能不能做得更好?具體該如何做?如果有做不到,需要想想是不是該花些時間學習。
  • 「設計樣式」是專業工作者必須花時間累積的資源,有許多設計,如果沒有歸納別人的經驗,自己重蹈覆轍可能會平白浪費許多年,才明白原來這樣做才對。當別人已經花了好幾年驗證怎麼做才對,趕快學起來就對了。
  • 網頁設計有很多「眉角」,不是看書或上課就能學會,而且網頁技術的變化很快速,很多東西根本來不及被寫成有條理的文件,必須找出好的實踐加以學習。
  • 由於開發時間不僅影響成本,也可能攸關產品成敗,專業的工作者必須節省時間,例如網頁設計需要的「字型、配色、樣式表」等,平時就要不斷擴充、整理一份口袋清單,讓產品雛形可以快速建立好,並且看起來不會太遜色。如果每次建立雛形都要從零開始,就會一直浪費時間在微調那些無關緊要、但又不能不做的細節。
不過Web Design Index這本書有個大問題,就是它是一本書,而不是一個互動能力更佳的Web,在講求效率的時代,翻書、尋找、輸入網址、分析設計,其實也要花掉不少時間。在Google帶來各種便利的網路服務之後,也許Web Design Index不能再像過去的傳統入口網站,只是提供索引,而是必須有更進階、即時的服務。理想中的Web Design Index Search Engine,應該有以下的功能。
  • 用關鍵字快速找到相關設計風格的網站畫面,用平滑捲動的相簿瀏覽方式,快速找到對眼的網站。
  • 可以訂閱某個搜尋結果,當有新的相關網站被加入索引,主動通知。
  • 網站的縮圖,可以標記某個區塊,產生該區塊的色碼註記,並提供一些輸入文字註解功能,透過眾人的力量讓網站索引更有用。
  • 除了建立Tag,也能把網站某些區塊的設計,關聯到某個網站設計樣式,例如「純CSS跨瀏覽器圓角設計」是一個設計樣式,連結到一些實作這種樣式的網站。
  • 提供一個客觀的評比機制,篩選符合某些觀點的好網站。
  • 分析出一些趨勢,例如有多少比例的好網站,已經開始用CSS3或HTML5。
由於網頁設計講求「有圖有真相」,擷取網站畫面並不難實作,但是分析圖片產生的結果,並不見得有實際得效用,也許機器能完成的部份有限,但如果有這樣的搜尋平台,提供方便的界面讓「人」來完成整理工作,或許就能產出一份更好的Index。

隨著各種網站前端技術的發展,使用者對互動界面設計的要求肯定會愈來愈多、愈來愈高,設計本身好與壞很難論定,但使用者覺得不習慣,就等於把顧客拒絕於門外,「不好做」並不能每次都拿來當擋箭牌。即使現在很多Web UI Library用起來很容易上手,但實作方式百百種,剛開始方向做錯了,修改經常幾乎等同重新做。也許該有Web Design Pattern,讓開發者減少浪費寶貴的青春,也讓「好的設計」得以普及,讓使用者不必一直學習不同的操作介面,只為了做同樣的事。

2011年4月26日

開放源碼的Cloud Foundry打造PaaS

「平台即服務」(PaaS, Platform as a Service),是雲端的一種發展型態。

先從過去的軟體發行方式演變談起吧!舉例來說,若公司需要一套「線上協作」軟體。最傳統軟體發行方式,就是去買伺服器、套裝軟體,上線之後,開放給員工或客戶使用。

這樣做產生了一些不必要的浪費,例如內部的維護人力,伺服器硬體和電力的消耗,後續的軟體升級更新費用。以伺服器硬體的採購來說,不可能買得剛剛好,初期可能只有30個人上線使用,但考量後續可能會有更多人,所以只好買了效能更好的機器。在使用率成長到恰恰好之前,硬體大多時候是閒置的,但仍然在消耗電力、折舊,而使用率超過預期之後,不管水平擴充或垂直擴充,都還要再花一筆錢。

所以之後有些軟體廠商不賣套裝軟體,而是把一些合適的軟體變成線上服務。例如協作平台,只要找到一家提供WIKI服務的供應商,依照需求人數、功能付費。由於軟體服務供應商,具有規模經濟效益,建設的軟硬體可以同時提供給許多家客戶,對客戶來說費用通常比自建較划算。這種軟體發行方式,就稱為「軟體即服務」(SaaS, Software as a Service)。

如果是一套軟體就可以服務所有客戶,架構上的問題就是怎麼達到水平擴充(scale out)。例如在3台機器可以提供3000位使用者同時上線,當需求增加到5000人時,可能只要擴充成5部機器,理論上一個適合水平擴充的架構,面對不斷成長的使用者,只要適時增家機器數量。

對使用者來說,只要購買「線上服務」形式的軟體,就不用理會前面說的維護及IT資源浪費問題。但是對於提供軟體服務的應用服務供應商(ASP, Application Service Provider),勢必還是要著手解決這些問題,而且是更棘手的問題,因為熱門的服務需要應付大量的使用需求,但萬一某些階段出現大批使用者退出使用,浪費的軟硬體資源就更可觀;對於突然增加大批新使用者,設備也可能趕不及擴充。

所以軟體服務的供應商,必須向「基礎設施即服務」(IaaS, Infrastructure as a Service),購買依照需求和使用量計費的虛擬化解決方案。提供IT基礎設施服務的廠商,可以建置好一櫃又一櫃的硬體,透過虛擬化技術,讓執行軟體服務的作業系統,可以在虛擬化的硬體平台運行。這些廠商本身可能就是電腦硬體的製造商或租賃商,可以運用高效能低耗能的硬體,透過虛擬化技術執行作業系統,減少硬體閒置的浪費,讓處理器效能、記憶體容量用得更徹底。

使用者並不在意他買的服務,背後是怎麼個運作,他只管付了錢,就能取用軟體服務。

有些使用者需要的軟體,必須由專業的資訊服務廠商,為其客製化量身打造專屬功能。

對於開發很多軟體,並把軟體變成一種服務來販售的廠商,租用虛擬化的IT基礎設施,其實只解決了一半問題。因為軟體開發者,仍必須在虛擬作業系統中,安裝軟體所需的網頁伺服器、資料庫等。

我們都知道一台網頁伺服器,可以同時運作多個網站;一台資料庫伺服器,可以同時運作多份資料庫。我們在一部虛擬化作業系統中,安裝一套網頁伺服器、一套資料庫,可以不用管背後的硬體設施怎麼配置。但仍未解決軟體部署的問題,一部虛擬作業系統的負載已滿時,我們必須再建立一部新的虛擬作業系統,之後的軟體必須部署到新作業系統;但各個軟體對系統消耗並不平均,我們不可能不斷在這些虛擬作業系統之間搬移網站、資料庫,只為了達到對系統消耗的均衡最佳化。

「平台即服務」(PaaS, Platform as a Service)為上述的問題提供解決方案,PaaS利用IaaS配置虛擬化系統,在上面提供網頁伺服器、資料庫的服務,並規範了應用軟體開發的架構。因此SaaS供應商開發的軟體,只要符合某個平台規範的架構,把軟體部署到這個平台,就不用管後端的網頁伺服器、資料庫伺服器怎麼運作。

PaaS的服務供應商,通常是大廠,如Google App Engine、Windows Azure。到底要靠哪邊站?應該讓不少人躊躇。

其實現在有了新的選擇,虛擬化技術的大廠VMWare,在這個月發佈一則消息,就是旗下的PaaS平台「Cloud Foundry」即將公開,目前可以開放測試帳號註冊,等待啟用通知的邀請。和其他家PaaS平台不同的地方,是Cloud Foundry為業界第一個「開放源碼(Open Source)」的PaaS平台。

Cloud Foundry允許軟體服務採用更多種開發框架(它主要是以Ruby語言開發),包括Spring(之前被VMWare收購)、Grails(隸屬於SpringSource)、Node.jsRuby on Rails,目前是VMWare自家的Spring/Grails比較推薦,未來的發展可以期待。以及支援多種儲存技術,例如關聯式資料庫MySQL、NOSQL資料庫RedisMongoDB、訊息佇列服務RabbitMQ等。

體驗Cloud Foundry應用軟體的開發,採用Grails可能會是一條捷徑,因為Grails本身有良好的測試及部署機制,不管用command-line或整合開發工具都很方便。Grails已有Cloud Foundry Plugin可使用,參考「Cloud Foundry Plugin Reference Documentation」。

開放源碼的PaaS,其靠山又是虛擬化技術的領導廠商VMWare,加上被VMWare併購的Spring是目前主流的Java開發框架之一,還有旗下的Grails是個優秀的輕量、敏捷開發框架,這些跡象似乎顯示Cloud Foundry可能走紅、佔有一席之地的機會。

Cloud Foundry的開放源碼授權採用Apache License 2.0,對於其他有意進軍PaaS市場的服務供應商,可以運用現成的Cloud Foundry提供PaaS服務;意謂著對軟體開發商而言,可能有更多不同廠商提供的Cloud Foundry服務可租用,服務品質和收費標準也有機會因競爭而變得更合理。

如果架構規畫得宜,用Grails開發的軟體,可以方便地在開發階段,部署到公司內的JavaEE伺服器,方便內部測試或給客戶預覽,待正式上線再部署到租用的Cloud Foundry平台,只要選擇不同計費方案,就可以擴充系統的負載量。

對於資源充足的軟體開發公司或客戶,也可以利用Cloud Foundry建立私有的PaaS平台。以學校的資訊中心來說,若能透過Cloud Foundry建立專屬PaaS,那麼學校各單位的資訊化需求,就可以直接向中心申請一組帳號,把軟體部署到PaaS平台上,就節省各單位自行維護網頁伺服器、資料庫的麻煩,中心機房集中控管的軟硬體資源可以更有效運用。

2011年4月25日

台中人體工學椅試坐的門市 Ergohuman 111、Enjoy 121、Nefil;Herman Miller Aeron、Embody、Mirra

Ergohuman 111是網路上知名度頗高的一款人體工學椅,因為是台灣廠商的自有品牌,所以價格比較親民。另外有幾款類似的人體工學椅,如Enjoy 121、Brant 131、Vapor、Nefil、Carlos、Lily,提供不同的功能及定價。網路商店及實體賣場可能只提供其中幾款,且中部的朋友比較難在一般家俱賣場找到,但椅子好不好坐絕對要親自體驗,可不能靠著口碑和別人的開箱文判斷,因為每個人的身材都會有些許差異;經過一番搜尋,找到了台中展售的地點。這些款式的人體工學椅,製造商是第一博士成長桌椅,台中直營展售門市在「台中市北區青島路三段36號」,現場有陳列三款網椅提供試坐;其他縣市則可以找鄰近門市
如果你曾經在百貨公司或連鎖居加裝修賣場,試坐過人體工學椅,但又覺得動輒兩、三萬的定價太高,實在買不下手,可以考慮看看「工廠直營」的Ergohuman 111、Nefil。第一博士除了這幾款熱銷的「時尚網椅」,另有獨家、外面很少見的「工學椅」,價格比網椅更親民,但「記憶棉款」的實際效果並不輸給網椅,是可以列入比較的另一項選擇。
第一博士台中門市街景圖。

檢視較大的地圖

對於長時間需要坐著工作,且預算充足的消費者,首選當然是「Herman Miller」,坐過之後身體自然會告訴你什麼才是好椅子,不管在材質用料、設計感、最重要的舒適度,都有很明顯的差異。Herman Miller的經典款,是紐約現代藝術博物館(NYC MoMA)永久典藏的「Aeron Chair」,有不少網友開箱文可以參考。可是在現場試坐之後,我覺得現代改良款的Embody在功能性有明顯的勝出,但也反映在更高一階價格上。
Herman Miller的台灣總代理是「雅浩家具」,台中門市地址為「台中市文心路三段51號1樓」,現場陳列非常多款式。

檢視較大的地圖

NetBeans 7.0發表,支援JDK7、Oracle資料庫

NetBeans最新版本7.0發表,這個版本對應Java SE 7,包括Project Coin對Java語言的一些小改變。在Java易主Oracle後,改由Oracle做為NetBeans開發贊助者,所以在這次發行的新版本,也對Oracle資料庫改善了內建的支援;其他還有對專案自動化工具Maven 3以及HTML5編輯功能的支援等。官方提供的語言包僅有簡體中文,但目前也已經有社群貢獻的正體中文版。

這段來自YouTube的影片,可以讓您快速體驗新版的功能。


以下轉載自 NetBeans IDE 7.0 Release Information


JDK 7 
  • Project Coin support
  • Editor enhancements: Code completion, hints
WebLogic Server
  • Streamlined and faster deployment to WebLogic
  • New server runtime node displaying deployed applications and resources
  • JSF integration with server libraries
Oracle Database
  • Simplified connection wizard
  • Guided installation to JDBC driver
  • Editing and deployment of stored procedures
JDK 7 switch

WebLogic

Oracle DB
GlassFish
  • GlassFish 3.1 support
  • Domain restart and log viewer for remote GlassFish
  • Enable and disable deployed applications
Java
  • Maven 3 support
  • JUnit 4.8.2 integration and various JUnit improvements
  • Remote HTTP URLs supported for Javadoc in libraries and Java platforms
  • New improved visual customizer for GridBagLayout
Java EE
  • Improved support for CDI, REST services and Java Persistence
  • New support for Bean Validation
  • Support for JSF component libraries, including bundled PrimeFaces library
  • Improved editing for Expression Language in JSF, including code completion, refactoring and hints
GlassFish remote view

GridBag designer

JavaEE code completion
Web Languages
  • HTML5 editing support
  • JSON formatter
PHP
  • Generate PhpDoc
  • Rename refactoring, Safe Delete Refactoring
  • PHP 5.3 - Support for aliases
C/C++
  • Easy import of project from user's existing binary
  • New Project type where user's source files are located on remote system
NetBeans Platform
General
  • Word wrap in Editor
  • Enhanced Profiler integration
  • Less intrusive checking for external changes when switching between the IDE and other programs.
HTML5 code completion

php

C/C++

Platform annotation action

2011年4月22日

如果買書也能做公益?

不久前,我寫信向某線上書店的廣告策略聯盟提出一個合作案。因為我們經營的一項網路服務,使用了學術網路資源,自然不可能選擇有「回饋金」的廣告。但我的想法是,對於一個服務學生的網站,例如一般學校都會有的圖書館網站,如果跟廠商合作,放置了一個「購書」連結,那麼回饋金直接變成購書優惠,讓那些經過網站驗證的學生身分使用者,可以用訂單再折扣2~4%的金額,取得學習需要的特定書籍(以教科書、教師指定延伸閱讀的書本),那不是件兩全齊美的事嗎?

當然,得到的回應,跟預想的一樣,就是目前沒這種服務啦!

對於喜歡看書、買書的學生來說,書錢有可能是一筆龐大的花費,因為教科書本來就不便宜,加上授課老師或教科書上會推薦一些延伸閱讀的書,如果圖書館借不到書、排隊等太久、不想看盜版書,那每個學期要花在購書的金額肯定不小。記得念研究所時,曾經有一個學期,開學時買了幾本原文教科書、幾本相關課外讀物,加一加將近1/3的學費,那可是要用不少打工時數去換啊。

還記得有幾次跟著全班團體訂書,可是問到的價格,卻比我自己上網買還貴!

當然書商也是有苦衷的,畢竟一本書可能學生買了之後就會流傳好幾年,而且不少人還是用影印的,加上國內市場就是這麼小,就算賣貴一點說不定還是沒賺頭。

這真不是一個好現象,書愈來愈貴,最後想買的買不起,想賣的賣不出去,作者也愈來愈不想寫需要耗費心力的書。難道,以後我們都只能靠著那些網路短文,還有從網路翻拍的新聞媒體,來擴充我們的視野和知識庫嗎?

在我開始邁入社會工作以後,要每個月維持買入一定數量的書已不是問題!但也經常想到,對許多貧苦弱勢人來說,買書可能是件相當奢侈的事。

每次有機會參觀別人的書房,我都會特別留意一下。有不少在經濟上較富有人,不僅擁有一個獨特品味的閱讀空間,整面牆的書櫃及滿桌的書報雜誌,都透露這個人平常的持續閱讀習慣。這真是M型社會的不公平,對於經濟富裕的人而言,書實在太廉價,只要花點零頭就能把別人辛苦的結晶買回來。

買書這件事,應該變得更有價值!把一本書買回來,不僅只是充實自己,在過程中應該可以創造出更多的價值。
  1. 認真挑本好書,對認真寫作的作者,給予一種實質的鼓勵,讓我們以後有更多好書可以看。
  2. 結帳的時候,順手捐出發票,讓弱勢團體多一分希望。
  3. 看完一本書,把好的內容與別人分享,讓有興趣的人也買一本。
其中第3點,走入網路時代,能創造的價值比過去多上許多。

網路,已經是一種人們很自然用來分享的管道,你可以分享在一間餐廳用餐的照片,炫耀自己的品味;但你也可以深度分享對一本書的見解,透過心靈的交流讓別人認識你的品味。

網路廣告,已經行之有年,別人看了你的推薦,買了一本書,產生的收益可以換算成回饋金。

對於有良好閱讀習慣、喜愛分享的人來說,有沒有這筆回饋金,對生活其實一點影響都沒有。

那麼,何不由通路商發起,把這些網路行銷創造的回饋金,變成「捐書」的公益活動呢?對於一般讀者來說,往往只能把舊書、不再需要的書拿去捐贈,因為買新書來捐這件事要有錢人才辦得到!

但是對於書商來說,書的取得成本比大眾低得多,也許只要300元的回饋金,就能捐出一本原價450元的書。只要平台提供好的機制,讓回饋金透明化、捐書的記錄公開,如此一來,愈多人買書,就能幫助愈多真正買不起書的人。

舉例來說,《正義:一場思辨之旅》(贊助連結),價格是320元,以回饋金2%計算,每賣出一本產生6.4元回饋金,只要透過網友的推薦及分享,每賣出100本,產生的640元回饋金就可以由書商捐贈2本以上新書,也就是我們正在閱讀這本新書的時候,某些偏遠地區的弱勢團體,很快就能一起加入閱讀,而不必等待某個富商出錢、或幾年後變成舊書才能取得。

2011年4月20日

Ubuntu 11.04: Overlay Scrollbars in Unity

Overlay Scrollbars是Ubuntu Unity全新操作介面的一項新功能,讓視窗捲軸只有在滑鼠游標移過去才出現,讓這個平常很佔位、但又不能沒有它的捲軸,可以自動躲起來!


Overlay Scrollbars in Unity from Canonical Design on Vimeo.

最新Ubuntu 11.04(代號Natty)即將發行,歡迎一起加入beta搶先測試行列。下載最新 Ubuntu 11.04 beta2

閱讀更多

用 Groovy + tesseract-ocr 破解很遜的驗證碼圖片

驗證碼(Captcha)是網站用來阻擋惡意程式的一種解決方案,可以保護網站不受到SPAM攻擊。但是,真的有用嗎?

網友kellyrob99分享的一段Groovy程式碼(同時也提供Python版本),示範了太過簡單的圖片驗證碼怎麼破解,需要的程式碼可以說比迷你裙還短!

很遜的驗證碼圖片,可能長得像這樣:

第一個步驟是去除背景雜訊,處理完就變成下面這張文字比較清楚的圖片。

下一步就是用OCR(文字辨識)軟體,把圖片中的文字轉出來。

剛好有一套開放源碼的 tesseract-ocr 軟體,可以用command-line方式執行,跨平台支援Linux/Mac OSX/Windows等作業系統,又恰好可以正確辨識此範例圖片的文字。

原始碼在 kellyrob99 的 github 網址 https://github.com/kellyrob99/catcha-breaker 可以找到。

原文出處為 http://www.kellyrob99.com/blog/2010/03/14/breaking-weak-captcha-in-slightly-more-than-26-lines-of-groovy-code/ ,簡體版翻譯請看 http://www.groovyq.net/node/133

雖然這種簡單的方法只能破解很遜的驗證碼,但萬一網站開發者偷懶,剛好用了很遜的驗證碼,就只是平白無故增加使用者的不便了!

2011年4月17日

改變未來生活的現在進行式,Facebook臉書效應

The Facebook Effect (中譯「Facebook臉書效應:從0到7億的串連」),作者David Kirkpatrick是Fortune(財星)雜誌的資深編輯。

在台灣生活,你一定聽過「臉書」「Facebook」「非使不可」,因為它幾乎無所不在,成為你我iPhone、Android手機的一部份,更是許多人社交的一種重要管道。不管你願意或不願意,Facebook用盡各種方法,找出與你有一點點關連的人,你可能突然發現ㄧ位十年沒連絡的老同學,而且最近打算結婚成家,也可能發現兩個不同圈子的朋友原來也彼此認識。

不管你願意或不願意,不管你對隱私的看法如何,Facebook的影響力,早就已經侵入你的生活。

在這本書中,有一部份談論大家可能早已知道的Facebook故事,那些Zuckerberg的傳奇故事早就在「社群網戰」上映後,變得眾所皆知。但更重要的部份,是透過Facebook的發展,揭露我們未來生活的一種形態。

看完這本書,你也可以開始想像未來的生活會因為Facebook(或比它更好的類似服務),而帶來多少有趣的變化。
Facebook在這一波網路的發展中,找到一個不易被動搖的立足點,致力於發展「平台」。這個平台擁有一項寶貴的資產,稱為「社交圖譜(Social Graph)」。社交圖譜反映出真實世界中,人與人之間的關聯性,比如A和B互相加入為好友,A被標記在C的相簿中,C曾經參與過B發起的活動,這些人際互動可以透過社交圖譜記錄。
Social Graph (來源為Google code labs)
六度分隔理論,嘗試證明平均只需要六個人,就可以聯繫兩個互相不認識的美國人。

社交生活本來就是人類的一項重要活動,每個人都無時無刻,都會透過各種方式,和別人建立起彼此之間的關聯性。只是我們的記憶以及能注意的人事物有限,在真實生活中,有許多關聯在建立後,就被我們自己給忽略,並隨著時間流逝。

資訊科技步步改變人類的社交方式,網路不僅僅是透過電子訊號傳輸把機器串聯起來,在使用電腦及網路的人們,才是真正有意義的「終端」。

因此我們生活的現代世界,除了在真實世界中繼續與其它人建立關聯,在虛擬世界中,不管有意無意,其實也不斷增加新的關聯。

Facebook從虛擬世界開始,把人們之間建立的關聯,透過資訊科技保存下來,讓你更容易看見,不容易消失,也難以抹除,形成一個龐大的社交網。即使你並不想參與,你還是可能透過別人,而置身其中。

圖譜(Graph)是一種資料的抽象呈現方式,通常用圓圈表示節點(node),連結兩個節點的線條,代表節點之間的關連。在社交圖譜中,節點代表的不僅有「人」,真實或虛擬的事物也都可以是一個節點,而連結就代表著「人」與其它「人」或「事物」的關係。

例如甲發起了一項旅遊活動,甲就是發起人,自然會跟這個活動產生關連,而甲和乙是朋友,之間本來就有關連。甲首先邀請乙參加活動,乙答應了,乙這時也跟活動建立起關連。而乙再邀請丙參加活動,原本甲不認識丙,但藉由參與相同活動的關聯,甲和丙已經有了關聯。

Facebook不僅存在虛擬世界,因為它連結的是在真實世界中的「人」「事」「物」,所以往真實世界拓展並非難事。由於智慧型手機的普及,許多人手上的通訊裝置,可能就是一個Facebook的入口。

Facebook專注在發展一個平台,並盡可能擴展到各種裝置上。它帶來了新的經濟,在Facebook建立的平台上,每個人都有機會建立新的應用,運用它提供的社交圖譜為基礎,建立可以創造價值的新服務。

若有一天,Facebook完成了它的使命,那麼有沒有Facebook這個網站?你會不會上Facebook去貼照片?你和朋友是不是透過Facebook噓寒問暖?這些都不再重要。因為,它已經成為你每天生活的一部份。

就像你拿起手機看網路影片,你不會在意手機裡面的網路晶片怎麼運作?由哪家廠商製造?也不會關心TCP/IP(一種網際網路的通訊協定)怎麼幫你傳輸資料?怎麼確保資料傳送成功?

在Facebook真正成功後,你不需要在意有或沒有Facebook,因為它會是你生活中的一部份,即使你沒發現它的存在,也不需要知道它的存在。

或許,現在Facebook只是一個讓你和朋友更容易保持聯繫,更容易知道朋友最近再幹麻,更容易把相簿分享給朋友,更容易揪團辦活動的一個「網站」而已。

但未來,社交圖譜成為各種電子裝置的基本功能時,將會有無限可能的應用,想像一下!

你開始玩一套新的線上遊戲,你根本還沒來得及告訴朋友這款遊戲有多好玩,但你已經在遊戲中發現你的朋友也正在玩。而你的朋友在賣場尋找新遊戲軟體時,也因為你們正在玩這款遊戲,而推薦系統自動將這款遊戲顯示在最醒目的位置,你的朋友很清楚只要買了這款遊戲,就可以有許多已經認識的朋友可以一起同樂。

你和朋友在客廳,正要打開電視機,此時電視已經知道你們平時喜歡哪些類型的影片,知道你們正好要一起看電視,也知道其中一位朋友年紀小不能看限制級節目,因此在推薦影片清單的前三項,都是普遍級到輔導級,正好有你們之中多數人還沒看過,也是最近最想看的一部片。

由於你們選擇免費看影片,所以每二十分鐘,就要被迫看一分半鐘的廣告,但更巧的是,廣告內容正好是你們最近在談論的新產品,也是其中一位朋友已經決定最近要買。這段廣告知道你們已經瞭解產品內容,所以沒有太多浪費時間的介紹,而是依照你們的收入及平時消費方式,幫你計算好轉帳扣款及刷卡分期的不同方案,贈品剛好是你們最近都有興趣的一個小玩具。如果你想買,你不用打開錢包,只要拿起手機,完成幾個簡單的確認,明天宅配就會把產品送到你家。

你正準備出去渡假,但只知到要去花東,沒規劃好行程。但是當你打開汽車引擎之後,導航系統已經知道你要去哪個地區玩兩天一夜,而且還沒規劃旅遊行程。幾秒之後,畫面出現三個旅遊建議行程,系統知道你過去的喜好,知道你是帶家人,知道你不喜歡廉價品質差的旅館,但也知道你不可能花大錢去住高級飯店,價格合理品質佳而且朋友推薦過的民宿,才是讓你動心的選擇;不僅如此,系統還知道你和家人喜歡牛排,但已經有一段時間沒去吃;你平常喜歡散步當運動,老婆喜歡逛街,小孩很愛去玩具店,天氣冷的週末會去泡溫泉。最後,你選了方案二,因為那家民宿願意給曾住宿的顧客的朋友打九折,而且離鬧區不遠,只要散步就能去吃牛排,吃完還有時間逛街,剛好其中一條街開了不少家玩具店,到了九點,民宿送的闔家溫泉優惠券正巧派上用場。還沒抵達目的地的時候,在高速公路上,導航系統出現了一個訊息,你的朋友明天安排的行程正巧跟你在同一個地點。

然而,這一切的發展,並不一定如想像中的順利因為現實中;人們對於隱私的擔憂,是社群圖譜應用發展的一項問題,畢竟誰能保證這些追求商業利益的公司,一定能做到「Don't be evil」呢?


加入《Facebook臉書效應》的粉絲團:http://www.facebook.com/thefacebookeffect

2011年4月15日

解決CSS3文字陰影效果(text-shadow)在Google Chrome瀏覽器中文字型模糊問題

CSS3的 text-shadow 屬性可提供網頁文字陰影效果,在Firefox、Google Chrome瀏覽器皆有實作(IE? I don't care.)。

使用範例如下:

text-shadow: 0 1px 1px rgba(0, 0, 0, 0.5);

不過遇到中文點陣字型,例如在Windows下預設的(新)細明體,用Google Chrome瀏覽器打開,會看讓中文字變得很模糊,嚴重影響閱讀舒適度,特別是16px大小以下的字型,幾乎難以辨識。

電腦族視力大考驗?

用Google找到一個css hack方法,只要將設定如下修改,就可以解決問題。

text-shadow: 0 0 0, 0 1px 1px rgba(0, 0, 0, 0.5);

字體不模糊的陰影效果!

使用Gradle快速建立Jetty網站開發測試環境

開發Java網站最讓人畏懼的就是癡肥的開發環境,回想過去每次砸重金升級記憶體,幾乎都是為了要讓電腦負荷JavaEE的開發。最可怕的莫過於幾年前用Eclipse+JBoss+SQL Server再外掛虛擬機器,光啟動開發環境就得花上數分鐘,一下子就耗掉數GB記憶體,而之後每次寫完一小段程式碼,要Deploy到Server上進行測試,等待時間更是曠日費時。特別是在本來就不怎麼夠力的筆電上,這些噩夢到了後來把Groovy和一些lightweight的開發框架玩上手才開始好轉。

最近打造的輕量化開發環境,編輯器以輕巧的jEdit取代Eclipse,因為Eclipse對Groovy並沒有良好的支援,反而jEdit在客製化之後更能完全符合專案需求;而JavaEE容器一直以來都是用Tomcat為主,其實Tomcat一直是個穩定好用、速度也不賴的Container,但是在使用Grails一段時間後,發現其實更好的作法是在專案裏面內嵌一個Container,這樣一個Java的網站專案,就可以不必依賴其他伺服器軟體,只要用SVN或GIT取出網站目錄,下個build指令就可以獨立運作,不管遷移到任何一台開發機器,都可以不必重新安裝、設定Container,節省了開發階段測試所需的時間,更可以方便透過持續整合(CI)系統進行自動化測試。

簡單說明一下這種差異,傳統在開發JavaEE網站專案時,不管是Production或Development、Test環境,都需要建構三個項目。
  1. Container(即Java的網頁伺服器,如Tomcat等)
  2. WebApp(網站專案的程式碼及資源檔案)
  3. Database(MySQL或SQL Server等)
以上三個項目各自有不同需要維護的設定檔,而且經常要將函式庫(.jar檔)等放到合適的位置。而這三個項目,只有WebApp才是適合用版本控制系統管理檔案的部份。
對於不同的開發者在不同的機器上做開發時,可以透過版本控制系統,取得WebApp最新的異動,因此WebApp的部份算是很容易就可以遷移到不同台電腦上。

但是對於一個開發架構不良的JavaEE專案,開發人員除了維護專案自己專屬的程式碼外,還需要維護網路下載來的函式庫(.jar檔案等),並且要正確配置其他兩項Container、Database,才能使WebApp能夠正確進行開發及測試。因此這部份參雜了不少人工作業,每次遷移或建立新的開發環境,很多事情必須重新來過,過程還可能會出錯。

最重要的是,這種無法完善進行自動化的開發過程,會造成導入持續整合的困難。因為持續整合系統,是必須做到定時從版本控制系統取得最新的WebApp,並且自動完成編譯、打包、部屬、測試、產生文件及彙整報告等工作。但是當我們的專案需要加入某些新的東西,而除了改變WebApp,也同時需要改變Container或Database時,就造成持續整合系統很難自動化處理這些事情,所以必須由人工在將持續整合系統的環境進行調整。

更完善的持續整合,將能夠自動依照不同配置設定,產生新的虛擬機器,並且在虛擬機器中自動建置測試環境,取得版本控制系統上的程式碼,再進行一連串編譯及測試等動作。這種時候,若WebApp所需要的測試環境,無法藉由它自己的定義進行配置,而需要額外的人工作業,就更加難以完成持續整合的建置了。

也許我們的專案尚未需要導入持續整合,但簡化開發環境仍是一個要盡早努力的目標,特別是在專案規模還沒長大前,把自動化的良好開發架構先做好,這麼一來,未來專案變得龐大且複雜時,自動化帶來的好處就會非常明顯,也不會有太多架構轉換的痛苦。
所以一個良好的JavaEE專案架構,應該是一個專案只包含一個項目,也就是只有WebApp。
  1. WebApp
Database要內嵌在專案中,可以考慮在開發及測試階段使用HSQLDB等資料庫引擎,配合Hibernate實作O/RM。這樣在開發及測試階段,就可以有獨立、內嵌的資料庫,可以簡化、自動化處理一些工作。只有在正式上線(Production)時,才使用真正提供服務的資料庫(如MySQL、Oracle或SQL Server)。即使不打算實作O/RM,也可以自行將資料存取層抽離,搭配可以透過script自動建立schema的內嵌資料庫。

但Database並非本文要講述的重點,我們先針對內嵌Container提供一些整理,也就是在網站專案內嵌一個測試專用的網頁伺服器(embeddable web server)。

目前最適合內嵌的JavaEE Container,我推薦的是Jetty,它具有以下的features。
  • Full-featured and standards-based
  • Open source and commercially usable
  • Flexible and extensible
  • Small footprint
  • Embeddable
  • Asynchronous
  • Enterprise scalable
  • Dual licensed under Apache and Eclipse
Jetty剛開始並非想打造全功能的JavaEE Container,而是以輕量化為目標,體積小巧,功能都以高度彈性的模組形式提供,開發者可以自己決定什麼模組要載入,什麼要捨棄,例如有些網站用不到Session功能,就可以不要把Session功能加入處理鏈(chain)。Jetty盡可能不要產生新的物件,所以可以節省記憶體;它提供的非同步(asynchronous)機制,使得高流量的網站(如社群網站),可以大幅降低request/response對系統的消耗。

如果因為Jetty的輕巧,就認為它只是測試用的Container,這個想法就不正確了。Jetty除了在開發、測試階段,是個很好的嵌入式Container,用來應付正式上線、大型企業的需求,也是絕對能夠勝任。它已經內嵌在許多開發環境(如Eclipse)、開發框架(如Grails、GWT、Lift),或許您也已經不知不覺在使用它。

在2009年,Jetty從第7版的發佈開始,遷移到Eclipse基金會。Google在此時也宣佈,旗下的雲端應用開發平台(App Engine),伺服器將從Tomcat改為Jetty(請參考「Google Chose Jetty for App Engine」)。而Yahoo! Hadoop Cluster、VMWare Zimbra,也都是Jetty實際應用的案例。

即使Jetty在大型應用中仍足以勝任,這不代表它變得複雜,在網站專案中加入內嵌的Jetty伺服器,只要以下介紹的簡單步驟。

首先,需要安裝Gradle這個工具,它改良了Ant、Maven等專案自動化工具,只要使用簡單的Groovy語法,就可以把專案所需的編譯、部署及測試等工作自動化,最重要的是能夠自動化處理Java套件的相依性,可以不用麻煩地到處尋找需要的JAR檔。

只要將下載好的Gradle檔案解壓縮,並設定好GRADLE_HOME、PATH等環境變數,在終端機下輸入gradle就可以使用。

對於許多Java專案,幾乎只要裝好JDK+Gradle,就可以不用再裝其他套件,例如Groovy、Scala等,Gradle也都有提供對應的Plugin可以處理。儘管Gradle還是一個很新的專案,未來還有漫長的路要走,但目前用來簡化我們的JavaEE專案開發,已經是是很棒的選擇。

在原有的專案目錄下,假設是一般Eclipse建立的網站專案結構,例如:
/src 放Java原始碼
/WebContent 放網站資料
/WebContent/WEB-INF 放網站設定
/WebContent/classes 放編譯好的類別

這時候我們可以在專案根目錄下,放置一個 build.gradle 設定檔案。

這個Gradle的設定範例,使用jetty plugin,設定了編譯期對servlet-api、jsp-api的相依性,在執行期則需要mysql-connector-java、commons-dbcp(資料庫連接池),並且自訂了srcDirs(原始碼路徑)、classesDir(編譯過的類別路徑),並且設定了Jetty的Context路徑、webAppSourceDirectory(網站資料路徑)以及連接埠8000。

在終端機下,切換到網站根目錄,使用以下的指令就可以完成編譯及啟動測試伺服器。
gradle compileJava
gradle jettyRun

第一次執行的時候,Gradle會依照套件相依性設定,自動下載所需的JAR檔,時間需要久一些,之後除非有修改相依性,否則就會沿用已下載的檔案。

若啟動過程沒有出現錯誤,那就可以用瀏覽器打開「http://localhost:8000/」檢視網站。

結論是,只要裝好JDK及Gradle,透過版本控制系統取得我們的網站專案資料,開發環境不需要再另外安裝維護一個網頁伺服器,就可以透過內嵌的Jetty進行開發及測試,甚至未來也應用在正式上線。由於Gradle本身並非XML設定檔的結構,而是使用Groovy程式語言編寫,這也給我們的專案自動化帶來極大的彈性,可以將自己寫的程式與Gradle提供的任務、Plugin相互搭配。

本文提供的範例,僅是Gradle一個小小的應用,因為Gradle目前能找到的資料有限,希望能拋磚引玉,使更多被繁雜Java開發環境困擾的朋友一同研究。持續改善開發架構,讓Java軟體開發除了熱血、也能多一分輕鬆悠閒。

2011年4月14日

跨瀏覽器的CSS3圓角(rounded corner)、陰影(shadow)

最近很懶得再用Photoshop繪製網頁需要的圓角和陰影效果,因為每次改版就要改圖還真麻煩,所以嘗試著採用CSS3加快網站版面雛型的製作。

CSS3已經定義了 border-radius (圓角)及 box-shadow (陰影)兩種屬性。
  border-radius: 15px;
  box-shadow: 10px 10px 20px #000;

Firefox、Safari、Chrome也有自己的特殊語法,但新版軟體已經支元CSS3提供的上述語法。
  -moz-border-radius: 15px;
  -webkit-border-radius: 15px;
  -moz-box-shadow: 10px 10px 20px #000;
  -webkit-box-shadow: 10px 10px 20px #000;

IE的部分還是一樣麻煩,即使到了IE8仍不支援CSS3,雖然我可以當作沒看到,因為I DON'T CARE,可是統計數字還是顯示高達60%的瀏覽者是用IE。更糟糕的是即使IE9已經改進了,但WinXP不能升級,而且相信還是會有很多人不會幫Win7升級到IE9。

IE其實有針對陰影效果提供filter,但把這一長串寫在CSS定義裡面,實在看了很礙眼。更好一點的辦法是用IE-CSS3,它用VML補強IE對border-radius、box-shadow的支援。

IE使用filter實現陰影效果。
filter: progid:DXImageTransform.Microsoft.Shadow(color='#969696', Direction=135, Strength=3);

使用IE-CSS3實現圓角和陰影。
  border-radius: 15px;
  box-shadow: 10px 10px 20px #000;
  behavior: url(ie-css3.htc);

在Google Chrome瀏覽器,直接用CSS3的語法,測試沒問題。


Firefox4瀏覽器的效果也沒問題。

該死的IE搭配IE-CSS3,載入頁面時會先顯示方角,頁面載入後才會處理成圓角,還算可以接受,但按鈕的部分套用behavior仍有BUG。

2011年4月13日

Groovlets出現404 error錯誤訊息

測試的環境是:
Groovy 1.7.10
Tomcat 6.0.32

Groovlets是Groovy內建的Servlet功能,可以用Groovy Script直接開發動態網頁程式。

但目前的版本有個致命的陷阱,發生的情況是:

在 index.groovy 網頁程式(Groovlet)使用以下的語法
import my.webapp.utils.Helper
def helper = new Helper()

其中 my.webapp.utils.Helper 是 Groovy 撰寫的類別(檔名為Helper.groovy),但已經透過groovyc編譯成.class放在WEB-INF/classes 目錄下。

在大多數情況下,這樣用是沒問題的,因為Helper本身已經是經過編譯的class檔,所以不管用Groovy或Java寫應該都要一樣才對。所以當我的Helper程式碼已經改用Groovy撰寫,也累積超過500行,結果就掉入了這個陷阱,必須重新以Java改寫才能順利解決。

第一次用瀏覽器打開 index.groovy 是沒問題的,但重新整理之後,就開始不斷出現 404 error。

追蹤Groovy的程式碼,發現問題就在其中 AbstractHttpServlet 類別的 getResourceConnection() 函式,這個函式的定義是給 GroovyScriptEngine 呼叫使用。所以當網頁被打開,需要解析 index.groovy 的時候,GroovyServlet會透過Servlet Context取得網頁程式的路徑,再產生Groovy程式檔案的路徑,但其妙的是 Helper.groovy 也會被 getResourceConnection() 拿去解析,由於這是一個已經編譯、放在classes目錄下的類別,所以就會造成無法正確找到檔案,拋出ResourceException,最後就形成404 error。

已將這個問題丟到Groovy論壇,希望能順利解決,暫時解決的方法就是自己開發的library盡量用Java寫。

如果要用Groovy開發網站,看來Grails才是最好的選擇,因為在Grails下,幾乎各種程式(Controller/View/Model/Script/TagLib/Class)都能用Groovy打造,Grails在整合的部分應該下了不少工夫。只是目前手邊的專案,仍有停留在傳統J2EE架構,只能搭配Groovy簡化開發工作,但遇到的問題其實還不少。

2011年4月12日

為什麼要寫網誌?

架個部落格開始寫網誌,其實就是在網路上寫日記,所以寫網誌的好處,可以參考寫日記的好處

在這個社會生活,我們每天要接觸的東西實在太多,不管打開報紙、電視、收音機,還是逛街、聊天、逛Facebook,或者工作、工作、不斷地工作,都會持續塞東西進我們大腦裡。然而大腦的工作方式很特別,不是把東西放進去,它就會自動幫你永久、有架構地記住,沒那麼好的事,除非你的腦子和別人不一樣。

即使只是將生活中的小事記錄下來,在睡前寫個網誌,有助於整理一整天下來的思緒,就算大多數都不適合寫成網誌,但至少想過就更容易讓有用的訊息成為記憶一部分。同樣的道理,早上起床,如果時間充足,寫一篇網誌也讓自己提早想清楚一天的規劃。

有很多主題都可以寫成吸引人的網誌,而且往往都是意想不到的那些,不管你當天聽到什麼?看到什麼?做了什麼?只要有一點點值得與別人分享,就可以試著把它寫下來。由於網誌平台可以幫你追蹤多少人對那篇文章有興趣?那些人回應了些什麼?所以,長久累積下來,你將會發現自己其實無意中幫助了不少人。

這是一種好習慣的培養,就像運動、晨起這些習慣,只要連續一百天(或是三個月)每天都去做,就會很自然地變成生活的一部分。這種習慣的養成,也讓你慢慢體會聚沙成塔的道理,有很多理想或未來的夢想,都是必須當下就一點一點去執行,要持續得夠長久,才有機會發現自己已經很接近想要的目標,否則只能一直在「想」而已。

在商業的應用方面。

即使部落格已經不再像前那樣流行,寫網誌的人變少了。但每次有朋友問我,想幫自己公司架個網站,該怎麼開始?

如果是十年前,我會說,架個自己專屬的公司網站。

在五年前,我說,開始考慮用部落格吧。

現在,遇到同樣問題,我的回答是,除了經營時下熱門的社群網站粉絲團,還是要有自己的部落格。

在今天,有自己的公司網站,只是讓別人知道你認真地花了一筆錢做了一個網站,可以找到商品和連絡資訊。但是,網站那麼多,一個擺在那邊不會自己動的公司網站,如果沒放什麼能夠吸引人的正妹圖,除非別人知道、很肯定要搜尋你的公司,否則要不小心掉進這個網站的機率簡直微乎其微。架自己的專屬網站就算找到很便宜的方案,但還是必須花錢。對於一家需要維持網路形象的公司來說,擁有公司網站就像門口裝了招牌一樣,是必要的投資,但顧客除非路過又剛好有興趣,不然不會因為這張招牌而自己找上門。

相較之下,部落格是一個化被動為主動的方式,而開設部落格的成本相當低,除了網址註冊費用外,其他幾乎都能找到免費好用的方案,最重要的是能將整理好的文章,或許是一篇新產品發表文、特價優惠訊息文,或者是施工、試用後心得等,都可以透過部落格更輕鬆地讓資訊傳送到更多人眼前。如果你有一組拍攝精美的宣傳影片或產品圖片,放在自己的公司網站,除非網站具備部落格該有的功能,否則不小心看到的人,通常也不會將它轉發給別人,但是在部落格,有非常多人樂意將自己看到喜歡的圖文以各種方式轉送出去,不管是點個「讚」、貼到自己的部落格、用E-Mail寄給朋友等。

而這些效果,將在有心、有計劃地經營一段長時間之後,會開始慢慢發揮加乘的效果。

只要擁有好的產品,再加上認真寫網誌,就不用怕沒人知道,因為網友會以各種可能超乎你想像範圍的方法,發現你的文章或將文章轉送給別人。

為什麼持續做就會有效果?原因很簡單,網站的曝光主要靠得是搜尋引擎、轉介(網址被貼到其他網站)等方式,其中最重要的來源是搜尋引擎,而對大部分的搜尋引擎來說,長時間用心、持續經營維護的網站,得到的「積分(Google搜尋引擎稱為PageRank)」就愈高。因此在同一個關鍵字進行檢索時,積分高的網站自然就會排在比較前面,效果跟花大錢買關鍵字廣告是差不多的。

比起一般的公司網站,部落格擁有更好維護、張貼新資料的特性,也更容易被訂閱,資料通常也很容易被搜尋引擎找到。

當部落格一天有超過一千人次來訪時,就表示將有超過一千人次,透過瀏覽器看到「你」或「你的公司」或「你的產品」,而且可能還是對你寫的東西感興趣才點進來。

所以,如果你是一位室內設計師,將每天完成的一些設計作品、施工照片,搭配文字介紹,讓看的人知道你「注重品質」、「不放過每個小細節」以及「對顧客滿意的堅持」等,也熱心地回答網友提出的問題。那麼,你將有機會一直知道好的乳酪在哪裡,而不會哪一天發現乳酪不見了[]!

經營部落格,也讓你比較容易發現網路上的人潮在哪裡,例如時下流行的社群網站和微網誌,對於擁有部落格的人來說,很容易就能知道這些新服務,並且將這類服務所提供的「小工具」內嵌整合到自己的部落格,這個時候就會多了更多管道,讓部落格發揚光大。

例如Facebook的粉絲團,就是一項有用的服務,幫自己的公司或部落格成立一個粉絲團,那麼網友將有機會透過部落格加入粉絲團,同時吸引其他朋友一起加入這個粉絲團,而其他人也可能看到粉絲團加入後也來參觀部落格。這種相輔相成的關係,可以帶來額外的流量,讓部落格的成長加速。

但是這些新服務,往往不會取代部落格,因為比較起來,即使把部落格架設在免費的平台上,但自己還是擁有一系列的網頁文章內容,算是有一個自己的網站,可以註冊自己的專屬網址。但是許多新的當紅網路服務,只能算是在別人的網站上面開設一個帳號,或許可以在上面經營出一定數量的人氣,但自始至終都是在「別人的網站上」。

一個剛買來的網址,即使名稱取得再好,通常也不會有太多價值(除非像網路蟑螂那樣侵佔別人的商標),必須要花時間去經營這個網址,才能讓網址變成對搜尋引擎來說是重要的。所以擁有自己的網站、使用自己註冊的網址,長時間累積的努力才會有成果。可以善用那些新的服務來加速自己網站的成長,例如一個賣產品的公司,可以用商店街服務快速建立一個購物網,讓顧客可以下單,但同時也要經營一個部落格,才能讓那些需要產品諮詢、售後服務的顧客,來到你自己的網站進行互動,這樣才能幫自己的事業累積人氣,而不是幫別人的「平台」衝人氣和買氣。

那,如果現在沒自己的事業也還沒打算創業呢?

那就要恭喜你!因為你當下正是最有時間寫網誌的時候,不管正在做什麼、未來打算做什麼,開始寫、不斷寫,將有機會幫你發現自我、找到同好;至少,也比較容易知道曾經做了什麼蠢事,有個記錄可以避免再次重蹈覆轍。

試想,當你有一天決定辭職不幹,決定要在自己家門口賣香雞排,你是要去地方小報紙上花錢打個小到需要拿放大鏡來看的廣告,然後每天被人拿去包便當,但你還是要付錢;還是,你要在一個每天都會冒出幾千人點閱的部落格上,放上大大張的香噴噴雞排照、數百則吃過都點「讚」的回應(雖然可能有99%是樁腳),然後加入粉絲團還可以免費兌換紅茶一杯,而且最重要的是不用花一毛錢,甚至你的部落格還能幫你賺零用錢。

延伸閱讀:

報名2011全球華文部落格大獎

中時主辦的2011年全球華文部落格大獎,即日起到4/29前開放報名。從部落格服務在國內爆紅以來,這項活動已經邁入第六屆,有許多朋友在接觸社群網路、微網誌(對岸稱微博)之後,可能就很少再寫網誌文章,所以這活動還能延續多久?就讓我們期待了,邀請還有繼續寫網誌的朋友共同參與。

以下這段蔡阿嘎影片,就是這次的宣傳(呃!)!


Install Subersion(SVN) support for Eclipse Helios SR2 (3.6.2)

2008年曾分享過Eclipse 3.4安裝Suversion(SVN)的方法,在舊版本的Eclipse開發工具中,要支援SVN必須增加第三方的Update site(Eclipse的套件來源位址),過程比較繁瑣。

新版的Eclipse(最新發行代號為Helios SR2 3.6.2)雖然也未把SVN列入內建的功能,但是在預設內建的Helios Update site就已經包含SVN功能(該專案名稱為Subversive),只要經過兩個步驟就可以完成安裝。

*最近Eclipse官方套件下載經常很慢,所以下載動作一段時間都沒回應屬正常,耐心等。

首先打開上方選單的「Help / Install New Software...」新套件安裝功能,在「Work with」下拉清單選擇「Helios - http://download.eclipse.org/releases/helios」,等候讀取套件清單資料(Pending...),這通常會需要等上幾分鐘時間,然後輸入「SVN」進行篩選。將「Collaboration / Subversive SVN Team Provider (Incubation)」選項打勾(參考下圖),然後完成安裝、重新啟動Eclipse。
重新啟動Eclipse後,打開上方選單的「Window / Open Perspective / Other...」(畫面如下),選擇「SVN Repository Exploring」,按下OK。
接著會跳出「Install Connectors」視窗,因為Eclipse的SVN Team Provider只是提供SVN功能的整合,而SVN Connector則是實際用來操作SVN Repository的連結元件,讓開發者可以自己選擇最合適的版本。預設提供的四組Connector,分別有SVN Kit及JavaHL兩類,依照SVN版本的不同(SVN 1.5.x或1.6.x)提供對應的Connector版本(如下圖)。通常我會選擇SVN Kit,因為它是純Java開發的Connector,同時將SVN Kit所有版本都打勾,這樣就能處理不同版本的SVN Repository。
按下Finish之後,繼續將安裝步驟完成,完成後再重新啟動Eclipse。

上述步驟成功之後,就可以開始使用SVN。

相信仍有不少Java專案選擇SVN作為版本控制系統,所以再次寫一篇文章希望能幫助剛接觸Eclipse的朋友,畢竟Eclipse是一套客製之後很強大,但一開始用起來不怎麼友善的開發工具,不像近期NetBeansIntelliJ IDEA等有顯著的親和力改善。

而尚未選擇版本控制系統的軟體專案,除了SVN,還可以考慮更先進的Git。開發Git的Linus Torvalds就是知名的Linux之父,Git是一套分散式的版本管理系統,功能比起SVN可算是不同代的產物。Eclipse也提供Git的支援,其專案名稱為EGit。剛開始接觸Git,可以先從GitHub網站開始研究起,也可以參考這篇「寫給大家的Git教學」,相信很快就能上手。

延伸閱讀:

2011年4月11日

UrlRewriteFilter 讓JavaEE Web Application也有漂亮的短網址

漂亮的短網址可是現代網站必備的一項功能,特別是使用MVC Framework打造的Web Application,幾乎清一色採用Controller/Action的網址格式。
http://yourhost/controller/action/id

於是以前那種長串的網址格式,像是:
http://yourhost/blog/article.php?id=1234

就可以縮短成簡潔的:
http://yourhost/blog/article/1234

雖然這不影響瀏覽者對網站的操作功能,但簡潔的網址,對使用者和搜尋引擎更友善。

在AMP(Apache+MySQL+PHP)平台, 實現這種短網址最常用的方法就是設定Apache的mod_rewrite。優秀的PHP開發框架,例如CodeIgniter,就可以簡單地設定mod_rewrite(只要設定在網站目錄的.htaccess檔案),就能讓漂亮的短網址可以運作。

雖然使用mod_rewrite讓網址格式更好看的做法,早已行之有年,但是在Ruby on Rails等MVC框架提倡CoC(convention over configuration)的概念後,讓預設的網址能夠對應到Controller設計的架構,變成採用普遍的一種網址架構方式。例如 blog/article/123 這段網址,CoC讓我們很直覺就知道網站存在 blog 這個控制器(controller,通常以class實現),並提供處理 article 這個動作的方法(method)或函式(function),以及123是id這個參數的值。

所以短網址不僅對使用者和搜尋引擎更友善,在開發階段,預設格式的短網址也讓開發更方便,少了許多設定的麻煩。

可是在傳統的JavaEE應用程式中,雖然最常用的Tomcat伺服器也是Apache出品,但它可不提供mod_rewrite的功能。

為什麼Tomcat不需要提供mod_rewrite呢?

JavaEE應用程式本身除了能寫類似PHP的JSP網頁程式,還可以實作Servlet、Filter。一般來說Servlet就可以扮演控制器的角色,而建立Filter可以幫其他Servlet進行網址格式的轉換。所以,並不需要由Tomcat提供這項功能。

在Java的開發框架,例如Struts,就是以*.do作為網址格式,只要URL以.do結尾,就會自動對映到某個Struts Action類別(它扮演的其實是controller角色)。

只是JavaEE過去一直沒有輕巧好用的框架,那些功能強大的開發框架,如果拿來開發小應用,可能設定的數量都比實際程式碼還要多!

所以,很多JavaEE專案, 並沒有套用網址格式受到良好定義的框架。有很多JavaEE網站為了方便開發,可能也捨棄用Servlet當Controller、JSP當View的邏輯介面分離架構,直接以JSP Scriptlets打造網站。

因此有大量JavaEE網站的網址格式,都是以下這種不友善網址格式。
http://yourhost/blog/article.jsp?id=1234

對於既有的專案,其實可以透過 UrlRewriteFilter 這個已經寫好的Filter,將網址進行簡化。目前最新穩定版本為3.2,可以在這邊下載

官方提供的這份說明很簡短,但也足夠瞭解安裝與設定方式,因為UrlRewriteFilter很簡單易用。

將下載的檔案解壓縮到網站專案的WEB-INF目錄下,會建立 lib/urlrewrite-3.2.0.jar 及 urlrewrite.xml 兩個檔案。接著要自己打開 web.xml 設定檔,加入 Filter 設定。

接下來,打開 urlrewrite.xml 增加自己定義的網址規則。

上面的範例,兩個rule其實定義是一樣的,只是一個採用regex(regular expression)方式解析來源網址,可以定義比較複雜的格式;另一種則是比較簡單的wildcard,則是可以用於簡單的格式。在to的設定中,type可以是forward(在伺服器端轉址)、redirect(在瀏覽器端轉址)等。

定義rule之後,打開from定義格式的網址,就會自動轉址到to定義的目標網址。但網頁應用程是本身產生的連結,也要配合做修改才行。但是若我們將.jsp變成.g、.do或沒有副檔名的網址格式,以後又要修改成其他的格式,網頁程式是不是也要配合再改呢?其實UrlRewriteFilter早已考慮到這一點,所以除了設定rule外,還可以用outbound-rule設定網頁程式產生的連結格式。

有了上面的outbound-rule定義之後,以下在Servlet或JSP程式中,採用encodeURL方法進行編碼的網址,就會透過UrlRewriteFilter重新改寫。

UrlRewriteFilter很簡單也很管用,對於舊的JavaEE網站系統,可以透過這種方式把網址改頭換面一下,好變成現代網站應該有的樣子。

如果是正要開始規畫的新網站,其實有更好的選擇:
Grails具備類似RoR等MVC框架應有的特色,除了預設就採用簡潔的網址格式,還可以自訂彈性的網址路由,而底層採用Spring/Hibernate等穩固、廣泛採用的基礎,寫Groovy程式碼和Java並不會差太多,也讓Java程式設計師不太會有轉換期的痛苦。
而對於願意接受新程式語言的開發團隊,Lift將會是一個更棒的選擇,它採用的Scala程式語言,是個在Java世界很有潛力的新語言,而Lift本身對Comet的完善支援,更讓它有機會成為明日之星。

2011年4月10日

從「老貓學出版」電子書免費下載發現新閱讀時代

相信常逛部落格的朋友都認識「老貓」,他的新站是「內容推進實驗室」,近期分享許多對於數位內容出版的思考。我們正處在一個紙本書籍式微、實體書店逐漸消失的時代轉變,人們的閱讀習慣和以往大不同,特別是年輕一代,閱讀的主要來源是網路媒體,而電子書順應新閱讀時代的需求,試圖要取代印刷書籍。

但是數位內容的出版,可不是把內容變成可以在電子裝置上閱讀那麼容易;即使內容的呈現方式、電子墨水顯示技術,近幾年已經改善不少,但消費者付費、閱讀的習慣,還需要有足夠時間磨合。

老貓最近作出了一個令人期待結果的實驗,「書渴望自由」將《老貓學出版》這本書以免費EPUB格式公開,而且沒有任何保護措施。但這可不代表老貓放棄「作者應享有的實質報酬」,書的每個章節都提供一組超連結,讓數位內容的讀者可以選擇「付費給作者」或「分享這本書給朋友」。對於真正有多少讀者會付費,我想多數人應該都不看好吧!不過這真是數位出版改革跨出的一大步,一位作者願意放棄比較有保障的版稅收入,先將內容送給讀者再說。

在LovelyReader網站,可以線上試閱或下載《老貓學出版》的電子書,下載的格式為EPUB,是一般電子閱讀器都支援的格式。

現在的出版業,跟幾年前的唱片業一樣,還找不到轉型的出路。建立DRM(數位著作權管理)是現行許多廠商採用的方式,這也跟之前許多數位唱片發行的方式一樣,目的是要讓「拷貝」變得跟實體商品一樣有門檻。

假使DRM真讓電子書真正受到保護,無法隨意複製,那就意謂著要使用封閉式的閱讀器。但這是一件多數消費者都很難接受的事情;以往買一本實體書,只要帶著不管到哪都能看,但受保護的電子書,卻只能使用限定的閱讀器,在廠商訂出的各種限制下才能閱讀。

實體書只要保存得妥當,可以存放很久,甚至放到書已絕版、連出版社都消失不見的N年後,還能拿出來閱讀。但被限制特定閱讀器才能看的電子書,在目前競爭激烈的局勢下,即使閱讀器買來可以耐用好幾年,提供這些閱讀機制的廠商自己能存活多久都還要打上個問號。當有更新更好的閱讀器出現時,可能還無法用新閱讀器打開自己買的書。

於是,要把「實體書」變成「虛擬化」的想法,往「保護內容不會被盜版」的方向走,似乎很難有解套的措施。

可是換個角度想,「容易複製」不正是數位內容的一大優勢嗎?傳統書籍要讓一本書給1000位讀者閱讀,需要印刷1000份,還要經過包裝、運送,時間就在出版的過程中浪費了。對於期待早一點看到內容的讀者,需要漫漫長等待,也沒辦法在出版後的第一時間透過網路「下載」。而喜歡書的內容想要推薦給朋友的讀者,可沒辦法點個「讚」就讓朋友也看到書的內容。

在資訊爆炸的時代,若是沒有名氣的作者,不太可能寫了一本書,就出現大批的讀者願意掏腰包。不管在實體書店或網路書店,大多暢銷書要靠著高成本的廣告、行銷,才能夠賣得出去,可不是每位用心的作者,都能幸運得到市場的青睞。透過現有的社交網路,其實有機會創造一個基於人際信任的行銷系統,當某位朋友跟自己一樣是某類書籍的愛好者,這位朋友確實看了一本書也推薦那本書,就表示自己花時間去看看那本書的內容應該會值得。

數位內容可以用很低的成本散播到廣大的讀者眼前,再來需要思考的問題,是讀者為什麼付費?怎麼付費?的問題。

實體書的世界,「書」被當作一項商品實際交易,所以作者靠著把書印出來賣掉,才實際得到收入。但新時代的作者,其實有機會得到更多的收入來源,演講、辦課程、翻拍電影、製作成遊戲、銷售包裝精美及高品質印刷的書籍和週邊商品…等,不過,要先打響自己的名氣、擁有一群真正願意買單的粉絲。

但一位有潛力、沒名氣的菜鳥作者,要怎麼讓內容被讀者發掘呢?電子書或許是個可行的管道,因為傳統通路很難支付大筆預算幫菜鳥作者大打廣告,只要作者願意將內容公開、無限制分享,透過現今網路的資訊傳遞速度,好東西是絕對不會被藏起來。當十位朋友裏面有八位都說某本書讚,而且內容只要點進去就能看光光,這時候還不願意去看看作者寫些什麼的人,恐怕已經是相當少數了。

如果把電子書當成是一種行銷,那電子書本身就不應該跟實體書賣一樣貴,因為電子書不用印也不用包裝、運送,個人認為實體書售價20%以內算是個合理範圍。在電子書發行平台、閱讀器整合得很好的情況下,我喜歡的某位作者、某一類新書或是很多朋友最近都在看的書,能夠主動通知我購買,而且透過行動網路,就能立即在我的閱讀器自動完成下載、擺放到虛擬書櫃,那麼一本不受保護的電子書付出30~90元代價,可以省下等別人買完才能複製的麻煩,之後也能方便複製到自己的其他閱讀裝置,其實就跟花錢打電話、買iPhone/Android小程式同樣能接受,畢竟對於本來就願意付錢買書的人來說並不算貴。

但這麼一來不就肥了消費者苦了作者嗎?其實這也不見得,在可預期的幾年內,電子書要完全百分之百取代實體書是絕對不可能的,但變成「只有好書才能出版實體書」卻是樂觀其成。

電子閱讀器近期的發展,要有印刷書籍那種可以拿在手上、隨意畫記號貼便條紙,長時間閱讀不會太傷眼、也不怕沒電,擺在書櫃可以呈現得到「收藏喜愛的書」的感覺,都是電子書無法替代。

能夠低成本取得的電子書,對愛書的人來講有很多好處,因為隨時可以把大量的書帶著走,需要查詢的時候,可以快速檢索,想要推薦給別人的時候,又可以馬上點個讚。

對於真正喜歡的書、或喜歡的作者寫的書,再花點錢去把實體書買回來,享受精美的印刷、更好的閱讀品質,相信有很多讀者都願意,如果實體書有作者簽名、出版社願意折扣優惠給已經購買過電子書的讀者,那應該就有更多意願了。

已經擁有電子書的讀者,對於內容已經大概Preview過,對於擁有這本書值不值得,已經有了自己的答案。雖然每個月都有一堆新書上市,但是多數人自己真正會想讀、想買的其實並不多,尤其是在內容都大概View過之後,就會得到一份願意付錢購買的「正港好書」清單。少花那些買到地雷書的錢,要買真正有用的好書就更加容易。

要把整本電子書用電子閱讀器看完,相信有經驗的人都知道那有多辛苦。而自己拿去印一份,不但看起來很沒質感,而且也同樣要花錢,還不如買出版社印刷裝訂好的實體書,再完整把內容詳細Review。

如果我買的電子書,用閱讀器打開之後,上面不是出現一條「贊助作者」的連結,而是「立即預訂實體書,附作者親筆簽名,早鳥優惠79折,再附贈作者巡迴講座優惠券乙張」。售價的部份,還能扣除之前購買電子書的金額,而且直接使用和購買電子書相同的「電話帳單繳費」或「信用卡繳費」,在實體書上市三天內就會宅配到便利商店或信箱。一本已經透過電子書確認是好書的實體書,我想點這個連結完成付款,對於有閱讀嗜好的人來說,並不是什麼太大的困難(畢竟書中自有黃金屋嘛)。

由於電子書讓出版社能更直接與讀者接觸,一個整合得好的通路平台,應該能讓作者或出版社直接掌握哪些讀者是真正願意付費購買,並且一直以來都是有實際購買行動,透過數位化的發行平台,掌握了讀者的消費記錄和喜好,就能把新書訊息直接傳遞給這些讀者群,並且給予長期以來比較支持的讀者實質的「老客戶折扣優惠」,甚至老讀者把書推薦給其他人購買,也可以獲得些許的回饋。這些是以往傳統書籍發行很難做到的事,畢竟消費者不會留太多資料給書店,出版社也很難整合各方的資料,作者更不可能取得這些;而不同消費者在同一地方同一時間用不同價位買到同一本書,怎麼聽怎麼怪。但是數位平台「一定、遲早」能解決這些問題,只是看這個市場機制怎麼去改變結構、進行整合。

若是這些都能成真,我想電子書和實體書就沒有互相競爭、取代的問題,畢竟買實體書附電子書在國外早行之有年。實體書後面的Index做得在好,都沒有使用「字串搜尋」來得方便,實體書前面的目錄做得在好,都沒有「超連結到該章節」來得迅速;但實體書那種拿在手上享受閱讀的感覺,能把一本書看到破看到爛、筆記做到密密麻麻,一個飲料滴到的污漬可以回憶起在咖啡館的陳年往事,或是一份來自長輩親手贈與一本書籍的感動,都不是電子書能夠輕易取代。

很期待科技在幾年內能為閱讀帶來的革命,但同時也希望出版業別劃地自限,畢竟走向蕭條的行業將會供養不起用心的創作者,只會造成惡性循環的後果。

身為一個只知道怎麼買書、看書的消費者,其實我們想要的很簡單,就是輕鬆付完錢,就能得到一個享受閱讀的服務,然後覺得錢花得很值得。

2011年4月8日

淺談Linux普通使用者權限安裝軟體,以node.js為例

通常在Linux作業系統安裝新軟體,需要root權限,因為系統目錄都只有root可以讀寫。而普通user則只能讀寫家目錄「/home/*」下自己專屬的資料夾。這種嚴格的權限控管機制,可以讓一台Linux伺服器,開放給很多使用者共用。而沒有root權限的使用者,即使做了不該做的傻事,也不會影響到整個系統,頂多把自己的家目錄給毀了(但熟悉linux的黑客級使用者,還是可以鑽漏洞幹壞事,所以租用多人共享的虛擬主機並不安全就是這樣)。

現代的Linux發行版,會提供很好用的套件管理工具,例如Debian/Ubuntu的apt、Fedora/Suse的yum,一般常用的軟體,只要被收錄到發行版的套件庫,就可以用這些套件管理工具進行安裝/移除。

使用套件管理的好處很多,我們只要確定系統設定的套件來源(repository)是可信任的,就可以比較放心地自動完成新軟體安裝,而不需要這個軟體時,它也會幫我們移除乾淨。而軟體因功能更新或修補漏洞,釋出新版本時,只要簡單下個指令就可以幫我們升級所有已安裝的套件。

以apt來說,常用到的功能有:
  • 更新本地套件清單:apt-get update
  • 尋找某個軟體: apt-cache search 軟體名稱
  • 安裝: apt-get install 軟體名稱
  • 移除: apt-get remove 軟體名稱
  • 升級: apt-get upgrade
有些軟體不存在套件庫,這時候我們就要去抓source或binary的版本,由於安裝過程可能會去更改系統目錄及設定。不透過套件管理工具,自行以其他方式安裝新軟體,具有潛在的風險,因為不同Linux系統的目錄格式可能不同,而網路下載的軟體也可能藏在惡意或疏忽造成的程式碼,會讓系統產生不可預期的影響。

即使軟體本身沒問題,也可以正確安裝到系統目錄下,但需要移除時又會是另一個問題,因為有很多軟體本身並不提供移除功能,系統管理者必須要自己判斷,哪些檔案該刪除、哪些設定該修改成安裝前的樣子。即使軟體有提供移除功能,通常還要使用和安裝時同一個版本,才能正確移除。

就算安裝和移除都不是問題,還要由系統管理者自行解決更新升級的問題。首先,自行安裝的軟體,通常有新版時不會通知,可能因此忽略了安全問題所需要的更新。而到底要先移除在安裝新版,還是可以直接覆蓋成新版,以及新版裝好是不是還要執行什麼程式,才能修正新舊版之間的差異(migration),這些都有賴系統管理者自己熟讀文件。

而套件管理工具,就是由熟悉這些軟體的開發者,幫我們寫好安裝移除所需的script,並依照特定系統版本將編譯好的程式打包,也會考慮到版本升級的問題。所以我們只要用簡單的指令,就可以完成軟體新增移除的工作。

所以即使Linux系統本身有良好的權限控管機制,也以高效能、安全且穩定著稱,最後還是會因為操作者本身不熟悉或疏忽,造成系統使用一段時間後,存在太多混亂的問題,只能以重灌收場。

有許多操作Windows的習慣,不適合用在Linux作業系統。因為一般人使用的Windows,通常為「個人用途」設計,所以網路下載一個免費軟體,就直接裝上去,是很自然的事;雖然近來的Windows也開始有些權限控管機制,但畢竟多數人還是以自己方便為主,會選擇比較鬆散的權限控制,即使是自己和家人共用同一部Windows電腦,也不太會去限制其他人怎麼存取。

但Linux系統一開始的設計就是「多人多工」的伺服器用途,系統本身需要非常穩定,接觸比較久的使用者都會知道,root(超級使用者)權限是非常恐怖的,一不小心做了蠢事,就會難以挽回。所以一個安全的Linux伺服器,必定會限制root帳號不能使用TELNET、FTP甚至SSH直接登入,也不會給root密碼,只能限定特定帳號以sudo方式執行授權的root的工作。

普通使用者是在受到隔離的環境下操作系統,不能存取系統目錄,很多設定檔不只不能編輯,可能連內容都無法看到。但這樣的設計,對於把Linux拿來當作「個人用途」桌面系統的使用者,就會覺得很麻煩,畢竟是自己的電腦、不是伺服器,當然會需要隨時都有足夠的權限去做任何事。

所以現代的Linux作業系統,像是Ubuntu Desktop,當我們進行的一項操作,如果需要root權限,這時候系統就會自動以sudo方式,讓你只要輸入自己的密碼,就能得以root權限進行操作,並且驗證還可能維持一段時間都有效。

而習慣了權限不受限制的Linux使用者,使用學校的Linux伺服器、租用Linux虛擬主機,或是和別人共用Linux作業系統,可能就會覺得沒有root權限很礙手礙腳。但是對於一台需要長時間運作的Linux伺服器,別說要拿到root權限,即使要把軟體裝到系統目錄都是不可能的。

其實從網路下載的tarball(*.tar.gz)的軟體,並不一定要root權限才能安裝,例如常見的tarball安裝過程會包含3道指令。
./configure
make
make install

其中只有「make install」會需要root權限,原因是一些編譯好的程式,需要複製到系統目錄(例如 /usr)下。但是只要在./configure加上--prefix參數,就能把安裝路徑更改成自己的家目錄。
./configure --prefix=/home/xxx
make
make install

以下以node.js為例,說明如何在沒有root權限的Ubuntu Linux Server系統進行安裝。

由於在Server上,很可能連編譯工具都沒有,對極要求安全的伺服器,提供軟體開發工具,等於幫駭客開了方便之門。所以我們可以用虛擬機器,先建立一個和目標伺服器相同架構(x86或amd64)的Linux開發環境,最好能夠版本也相同。

由於是自己的Linux,所以可以用sudo安裝node.js需要的開發工具。
sudo apt-get install g++ curl libssl-dev apache2-utils git-core

接著按照安裝教學文件的方法,把node.js裝到自己的家目錄(請注意--prefix參數)。
git clone git://github.com/joyent/node
cd clone
./configure --prefix=~/pack
make
make install

因為「make install」沒有加sudo,所以使用普通使用者權限進行安裝,而檔案會複製到--prefix參數指定的「~/pack」資料夾下。

安裝完成後,看一下安裝好的檔案。
ls ~/pack

我們可以看到 bin、include、lib、share 這些子目錄被建立在pack目錄下,也就是原本應該裝到系統目錄下的結構,被放到pack目錄下。我們可以將pack打包,指令用tar即可。
cd ~
tar zcvf my-pack.tar.gz pack

接著,把my-pack.tar.gz上傳到Server,再用tar解開。
tar zxvf my-pack.tar.gz

然後,編輯 ~/.profile 再最後加上一行:
export PATH=~/pack/bin:$PATH

重新登入,或是直接在終端機執行上面的export指令,就可以下「node」指令。
node --version

等等,萬一出現LIBRARY找不到的錯誤訊息,怎麼辦?

上面的步驟,是假設Server已經有「node.js」需要的library,例如libssl等,因為我們並沒有自行編譯打包相依的library。所以這種方法,適合想安裝到Server的軟體,該有的基本library都已經存在,把編譯好的程式丟上去就能跑的情況。

如果Server缺東缺西,那麼也只有幾種選擇了...
  1. 請系統管理員裝上(如果是基本該有的library,這算合理要求吧)
  2. 每樣東西都自己編譯打包(但這也太累了吧)
  3. 架一台自己的Server
如果上述都沒問題,以普通使用者權限執行「node.js」會不會有其他問題呢?答案還是有的,因為Linux通常會限制1~1023這些port只能由root權限執行的程式listen,因為這個範圍包含很多常用的重要網路服務,所以要避免被心懷不軌的使用者程式冒用。普通使用者執行的程式,是無法使用這些port,而node.js的範例使用8124就沒問題。

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

是不是只要別用1~1023這些port就可以呢?答案是不一定,因為注重安全的伺服器還會設定防火牆,所以並不是程式開port成功,就一定能接受遠端的連線。對於多人共享的虛擬主機,即使有開放SSH,廠商當然也不會希望客戶自己跑自己的server程式,因為那會佔用CPU/RAM,使用者自己跑的server程式可能會有些無法控管的行為。

由於目前的虛擬化技術已經很成熟,所以真的有需要架設網路應用程式,除了自己架設伺服器的方案外,也可以向虛擬主機商租用VPS(虛擬專屬主機,行銷的講法叫作雲端伺服器),就能享有全部的管理權限。租用VPS雖然有完全專屬作業系統,可以自己架設需要的服務,但是記憶體、磁碟容量和處理器用量都會有所限制,這時對Linux系統管理的熟悉度,就會影響作業系統和伺服器的最佳化。

2011年4月7日

Monaco 適合程式碼的螢幕字型

寫程式經常要長時間盯著大量代碼,而等寬字型好看的並不多,看久了總是會膩。最近想換個新字型,看到這篇網誌之後,又找了些其他人推薦的字型,最後選定Monaco作為這陣子主要的字型。

在Ubuntu下,Monaco的顯示很清晰,除了文字編輯器,終端機畫面也很適用。
Ubuntu + jEdit
Ubuntu + VIM
在Mac OSX系統下,同樣使用Monaco作為編輯器及終端機字型,但預設的字體顯示效果,似乎邊緣部份有些模糊。
Mac OSX + jEdit
Mac OSX + VIM


延伸閱讀

使用QEMU快速測試LiveCD開機光碟

QEMU是個輕巧的虛擬機器,它雖然功能不及VirtualBox、VMWare等,但如果要在Ubuntu測試網路下載或自己建立的LiveCD ISO檔,絕對是個能勝任的好工具。這份文件的示範,以Ubuntu 10.10 Desktop為例。

使用apt-get安裝qemu只要一行指令。
sudo apt-get install qemu qemu-kvm kvm-pxe

以下的指令,可以建立記憶體配置1024MB的虛擬機器,並透過掛載ISO映像檔的虛擬光碟機開機。
qemu -m 1024 -boot d -cdrom ~/ubuntu-10.10-desktop-i386.iso

如果要執行64位元的LiveCD作業系統,則改用qemu-system-x86_64指令。
qemu-system-x86_64 -m 1024 -boot d -cdrom ~/ubuntu-10.10-desktop-amd64.iso

區網升級1000Mbps與Ubuntu查詢網路卡連線速度的方法

以前對區域網路的速度不太注意,只覺得網路線插上去能連線成功就好。日前手邊一台D-Link DIR-300故障,就利用這個機會一次把家裡的工作站和伺服器之間的區網升級。雖然手邊很多閒置的網路分享器,但清一色都是100Mbps/802.11G的舊款機種。

靠著在NOVA工作的阿政兄幫忙,物色到這台TP-LINK WR1043ND,是3T3R支援802.11N/1000Mbps的機種,算是便宜大碗的好物,所以就打消了原本想購買D-Link DIR-655的念頭。

無線網路的部份,這台分享器有3T3R MIMO,實際測試起來,三十多坪的公寓,從最角落的房間將訊號傳送到另一個角落的房間,大概有30-40%的訊號強度。
但我目前比較關心的是,區網速度的提升能有多少。因為家裡兩台主要的工作用的電腦,一台當Server,另一台當Workstation,但透過100Mbps的網路交換資料,仍要浪費不少時間在等待大檔傳輸。

雖然CAT.5e規格的網路線,理論上可以達到1000BASE-T的速率,但實際速度要看線材品質。這種5公尺以下長度的線,CAT.6和CAT.5e價格沒差多少,但CAT.7就比CAT.6貴很多,我最後決定買PowerSync的Cat.6線材。

兩台主機,一台配置的網路卡是INTEL 9130CT,另一台則是接到主機板內建的Realtek 8169,都最高支援1000Mbps的速率。

但是將Gigabits的網路卡,使用CAT.6網路線,接到Gigabits乙太網的分享器之後,怎麼確認作業系統有使用1000Mbps的速度呢?

在INTEL網卡的機器上,使用 dmesg | grep ethX 可以查到連線速率的LOG資料。
e1000e: ethX NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

但REALTEK網卡的機器,就沒這麼幸運了,除了link up沒顯示別的。
r8169 0000:03:00.0: eth0: link up

這時候就要使用ethtool這個軟體,因為Ubuntu並沒有內建,所以要先apt-get裝上。
sudo apt-get install ethtool

使用ethtool也要root權限,所以一樣用sudo執行。
sudo ethtool ethX

輸出訊息很詳細,但我們只需要看Speed及Duplex。
Settings for ethX:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes

連線速度顯示1000Mbps,而Full Duplex則表示已開啟全雙工模式,即Income/Outcome可雙向同時進行1000Mbps速率的傳輸。由bit換算成byte,1000Mbps是125MBps(b=bit;B=byte),但這只是理論值,網路卡、線路、TCP資料封包處理、電腦及交換器效能很多因素都會讓實際傳輸速度再低上許多。

在網路傳輸品質良好的情況下,1000Mbps通常有機會達到100MB/sec的實際傳輸速度,但由於硬碟的平均讀取可能沒有這麼快,所以用FTP測試的話,可以發現速度是取決於兩台主機各自硬碟的讀寫速度。

FTP的傳輸算是相當接近網路速度的上限,若是透過SFTP、SAMBA(網路芳鄰),就會再慢一些,尤其是SFTP的傳輸過程資料經過加密,速度就大打折扣。但FTP傳輸時,兩邊若是以傳統硬碟當作儲存媒體,就測不出1000Mbps網路傳輸的極限。

要解決這個問題,其實只要透過兩邊主機的ramdisk即可。但為了測試還要弄個ramdisk?聽起來有點麻煩,但是在Ubuntu上其實並不需要額外的設定,因為/tmp(暫存區)資料夾就是採用tmpfs這個檔案系統,也就是存放在/tmp資料夾底下的檔案,實際都是放在閒置記憶體空間。

預設的情況下,Ubuntu配置1GB的空間給/tmp,若要修改可以編輯/etc/fstab,將size改成需要的大小。
tmpfs /tmp tmpfs size=4096M 0 0

所以我們可以製造2-4G的檔案,用來進行FTP的傳輸測試。在Linux底下「快速」製造超大檔案,可是有撇步的,不需要真的去找一個好幾GB的檔案拷貝到/tmp,在/tmp容量足夠的情況下,可以使用dd指令,若/tmp容量不夠,可以使用qemu-img指令,dd和qemu-img在短短幾秒內產生指定大小的檔案。

使用dd(若/tmp的剩餘容量足夠建立)建立4GB的檔案。
dd if=/dev/zero of=test.img bs=1M count=4096

如果還未安裝qemu,可以先用apt-get裝上。
sudo apt-get install qemu

再來使用qemu-img快速建立一個4GB大小的檔案。
qemu-img create test.img 4G

使用這個檔案進行FTP傳輸,由本地端的/tmp資料夾傳到遠端的/tmp資料夾,由於兩端主機都是讀寫記憶體空間的暫存區,所以測得出1000Mbps的上限(使用LFTP進行傳輸,維持在每秒100M以上)。

結論是,升級到1000Mbps的區域網路,真的可以讓多台主機串起來用;但硬碟、網卡要夠力才能達到的極限的速度,所以升級小型區網用的網路設備,大約只要3000-10000元的預算,但之後就開始需要高價的RAID、SSD、NIC才能繼續提升效能,就會是個錢坑了。

新玩具實測 INTEL 320 Series SSD 40G (SSDSA2CT040G3)

INTEL新款的320系列SSD在3/29日發表,昨天逛NOVA發現有現貨,只要$3,000元有找,就立即入手一顆,替補那個使用率97%接近爆滿的系統碟。

在灌好系統後,使用Ubuntu的磁碟公用程式(disk utility)測試一下效能。

最小讀取率:182.5MB/s
最大讀取率:254.2MB/s
平均讀取率:234.9MB/s
平均存取時間:0.2ms

平均讀取比剛裝上去空碟的時候下降了一些,可能是桌面跑一些程式造成的loading。

磁碟效能的提升從開機就能明顯感受到,開機後第一次啟動應用程式需要的時間也有改善,這項投資很值得。

開放源碼的雲端企業IT架構軟體openQRM簡介

openQRM是一套面面俱到且相當有彈性的開放源碼基礎架構管理方案(infrastracture management solution),它提供完善的可擴充式架構,針對自動化、快速及以設備為基礎的部署、監控、高可用性(high-availability)、雲端運算,並且支援多種虛擬化(virtualization)技術。

openQRM提供IT基礎建設的單一管理窗口,並提供良好定義的API,可以用來整合擴充第三方工具,無論是小公司或全球規模的企業,都能高度彈性地整合不同作業系統的大型伺服器,並滿足高可用性的需求。

以下列出的需求,將適合使用openQRM達成:
  • High-Availability(高可用性):提供所有應用程式容錯機制(Fault-Tolerance)及故障切換(Fail-Over)。
  • Server Virtualization(伺服器虛擬化):將實體伺服器轉換成虛擬機器。
  • Storage Virtualization(儲存虛擬化):將標準伺服器轉換成資料中心的儲存伺服器。
  • Server Consolidation(伺服器整合規劃):將多部伺服器整合成單一實體主機,使用虛擬機器讓效能消耗及故障問題不會直接影響到實體機器。
  • Network Monitoring(網路監控):在整個架構網路中,電腦、裝置、伺服器軟體和應用程式可以即時監控(Real-Time-Monitoring)。
  • Hardware Independence(隔離硬體平台):讓舊有的應用程式和作業系統,也能享用新配置的硬體。
  • Vendor Independence(隔離硬體供應商):不再受到特殊規格硬體或特定供應商的限制。
  • Multiple OS configurations(多重作業系統配置):可以同時運作多種類的作業系統,不管是為了開發或測試的目的。
  • Kernel Development(核心開發):對修改作業系統核心的測試和除錯,不再需要獨立一台測試專用的機器,可以使用沙盒(sandbox,意指可隨意測試,壞了再復原或重建)虛擬機器。
對於企業資料中心的儲存需求,openQRM在4.1版本(最新版本是4.8)就提供以下的儲存伺服器類型支援:
  • NFS
  • Iscsi
  • Aoe/Coraid
  • NetApp
  • Local-disk (transferring server-images to the local-disk)
  • LVM-Nfs (NFS on top of LVM2 to allow fast-cloning)
  • LVM-Iscsi (Iscsi on top of LVM2 to allow fast-cloning)
  • LVM-Aoe (Aoe on top of LVM2 to allow fast-cloning)
在虛擬化技術上,openQRM支援企業常用的解決方案,例如VMware、Xen、KVM及Linux-VServer。內建的即時監控軟體,則是同樣開放源碼、業界廣泛採用的Nagios,提供企業在IT基礎建設發生的問題影響營運前,就能透過監控系統察覺。

這段影片用五分鐘時間,介紹openQRM如何提供雲端運算。

將 Ubuntu Linux 搬移到新硬碟

已經使用一段時間的Ubuntu,通常有相當多個人化的設定,但以硬碟容量倍增、價格下降的趨勢,大約兩年左右換上一顆新硬碟,把舊硬碟拿來養動物或備份資料,這樣不但可以一直保有充足的容量,也可以減少硬碟因老化故障造成資料毀損的機率。

日前INTEL推出新的320系列SSD,目前40GB版本的報價已經不到$3,000元,同樣的入門款等級,讀寫效能比起前一代提升了許多。雖然40GB並不夠一般儲存的需求,但安裝Ubuntu Linux的桌上型電腦,可以將根目錄磁區「/」設定在容量比較小但速度快的SSD硬碟,而家目錄「/home」則設定在大容量2TB以上的傳統硬碟。

在Ubuntu Linux Desktop的根目錄下,通常是 /usr 子目錄會佔用比較大的容量,因為應用程式主要的檔案都會放在這裡。但即使裝了大量的應用程式,大約30~40GB的分割區大小就已足夠應付大多需求。因為正常用途的作業系統不會每天都大量新增移除軟體,而應用程式在第一次執行,需要的檔案從硬碟讀出後,只要記憶體容量充足(目前的桌上型電腦裝滿16GB記憶體並不需要花費太多),系統就會在記憶體配置緩衝區,不會每次都從磁碟讀取。一般使用者編輯的圖片、文件,或網路下載的影片、音樂,都會保存在家目錄,所以家目錄的讀寫通常比根目錄頻繁。因此將根目錄存放在SSD硬碟,家目錄存放在傳統硬碟,對SSD讀寫次數有壽命限制的問題,就不用太操心了。

當然上面只將系統分配成根目錄及家目錄的作法,是適用一般個人電腦用途,對於伺服器就需要不同的配置,例如伺服器常將網頁、記錄檔及資料庫檔案放在/var,就要依照進階的使用需求去做規劃。

由於Ubuntu的APT套件庫做得相當好,每年4月、10月新版發行的時候,通常可以順利無痛升級,而不需要重灌,所以即使要安裝新硬碟,把速度比較快的新硬碟當作主要開機硬碟,以及儲存作業系統資料,這時候可以選擇用資料搬移的方式。

搬資料不是COPY過去就好了嗎?

其實只完成COPY磁碟資料的動作,並不夠完整,因為啟動Linux作業系統需要GRUB(或LILO)開機程式,所以需要把開機程式重新安裝一份到新硬碟的主要開機記錄區(MBR),這樣子才能讓新硬碟獨立完成開機作業。

由於Ubuntu Linux的LiveCD功能很強,所以我們並不需要藉助其他軟體,單靠LiveCD就能完成開機磁碟資料搬移的工作。

假設主機已經安裝好新硬碟,就可以開始以下搬移步驟。

首先,需要先製作一張LiveCD,建議使用和目前系統相同版本的ISO檔,例如ubuntu-10.10-desktop-amd64.iso。但由於做環保愛地球的訴求,我們並不鼓勵使用者真的把ISO燒成光碟,而是拿一支舊的USB隨身碟,製作成LiveUSB(目前大多數主機板可以使用USB隨身碟開機)。

以下的示範畫面,以Ubuntu 10.10 Desktop AMD64版本為例。

在Ubuntu系統製作LiveUSB的方式,可以使用內建的usb-creator,先看一下是否已安裝:
dpkg -l |grep usb-creator

如果還沒裝,則先使用apt-get立即裝上(usb-creator-gtk是GNOME使用的版本,KDE愛用者可以改成usb-creator-kde)。
sudo apt-get update && sudo apt-get install usb-creator-gtk

打開「系統 / 管理 / 製作開機碟」,選擇來源光碟映像檔及目標隨身碟,就可以點「製作開機碟」。

製作好的LiveUSB不用拔除,重新開機,在BIOS設定中,調整硬碟的開機順序,將USB隨身碟調為最優先。在Welcome畫面中,選擇語言「中文(繁體)」再點選「試用Ubuntu」。


使用磁碟公用程式「System / Administration / Disk Utility」,將新硬碟整個磁碟格式化成「Master Boot Record」,再建立分割區(partition),分割區的格式可以跟舊系統的根目錄「/」分割區一致,通常是ext4或ext3。


2012-08-24 Update

Use GParted (LiveUSB) with newer version and choose "MiB" for "Align to" option. It's better for SSD 4kb alignment.


再來需要把磁碟代碼記住,例如舊的硬碟的分割區是 /dev/sda1,新硬碟是 /dev/sdb1。

打開終端機程式「Applications / Accessories / Terminal」,依序執行以下指令,請自行依實際狀況修改分割區代碼。第一行「sudo su -」會切換成超級使用者root,所以後續的指令必須很小心操作,否則會造成系統毀損。
sudo su -
mkdir /media/old
mkdir /media/new
mount /dev/sda1 /media/old
mount /dev/sdb1 /media/new
rsync -ax /media/old/ /media/new/

最後的rsync是複製資料的指令,這會花上一些時間,可能要幾分鐘到幾十分鐘,視舊磁碟儲存的資料容量而定。如果想知道進度,可以再打開一個終端機程式,使用 df -h 指令,查看新硬碟已使用容量即可知道已完成複製多少。

資料複製完成後,再來是重新安裝GRUB開機程式。首先我們需要將目前的Linux運作環境,從LiveUSB開機後的系統,用chroot指令轉移到新硬碟上面的系統。依序執行以下的步驟。
sudo su -
mount -o bind /proc /media/new/proc
mount -o bind /dev /media/new/dev
chroot /media/new

接下來再執行的其他指令,就等同於在新硬碟的Linux系統上操作,首先重新安裝GRUB開機程式。
grub-install --root-directory=/ /dev/sdb --recheck
grub-mkdevicemap
update-grub2

上面的指令,會將GRUB開機程式安裝到/dev/sdb(新硬碟)的MBR。

有些文件只講到這裡,而忽略了分割區掛載的設定,這樣開機後仍會將舊硬碟的分割區掛載成根目錄「/」路徑。所以我們還要再修改 /etc/fstab 的設定才行。由於目前的Linux設定檔開始改用UUID取代分割區代碼(/dev/sdX),所以要先查詢分割區的UUID。
ls /dev/disk/by-uuid/ -al | grep sdb1

顯示結果的一長串英數字就是UUID,可能長這樣「55E14BD4473131DF」也可能是長這樣「9fdbd623-299c-45a7-9adb-6e07e82080a7」。

再來,打開 /etc/fstab 將根目錄分割區「/」的UUID設定成新硬碟分割區的UUID。
vim /etc/fstab

如果不習慣使用VIM,可以改成圖形介面的文字編輯器。
gedit /etc/fstab

儲存設定後,重新開機。

由於我們把GRUB開機程式安裝到新硬碟的MBR,而新硬碟對主機板的硬碟控制器,可能是位於第二顆以後的順序;在預設情況下,BIOS的開機硬碟會優先以位於第一顆順序的硬碟開始找MBR,如果不修改,還是會用舊硬碟開機。

所以重新開機時,除了移除剛才用來開機的LiveUSB隨身碟,還要再次調整開機硬碟順序,將新硬碟的優先順序移到舊硬碟前面,這樣BIOS開機程序在尋找MBR時,才會讀到新硬碟MBR安裝的GRUB開機程式。

我們將新的GRUB開機程式安裝到新硬碟的MBR,而不去覆蓋舊硬碟的MBR,所以即使前面的過程失敗,仍然可以讓BIOS設定優先以舊硬碟開機。
lyhcode by lyhcode
歡迎轉載,請務必註明出處!