2008年1月14日 星期一

程式設計的「德、智、體、群、美」

近來實做過幾個看起來很難成功的專案後，我深深感到
在台灣賣「程式技術」是一點用也沒有的

台灣有多少人會寫程式，現在大學各個系都開始冠上「資訊」
程式語言的門檻越來越低，從php到ruby的發展及差異清晰可見
程式設計師們個個只要稍加訓練，一定都具備相當的能力能夠「寫」出成果來
然而，這些成果是什麼？些成果「該」是什麼？一個能賣的產品嗎？
這些問題總是也沒人去探討。
以往台灣的軟體產業，公司需要的多半還是Coding Machine，也就是「工程師」
資深的工程師或需求人員「想出」設計，搭配美工或是資料庫設計，然後由年輕的工程師們變出來
卻沒有多少人注意到這個產業慢慢需要的不是機器，而是完善的設計流程，及腦袋清楚，身體健康的開發人員
我相信，程式設計有所謂「五育」
台灣的軟體人員，似乎總是有點五育不全

閱讀更多 »
張貼者： 於 4 則留言 :
標籤：

[2007/08/19 - 2008/01/14] Hemidemi書籤摘要


張貼者： 於 沒有留言 :
標籤：

2007年12月9日 星期日

You are a dog ! (Ultrasonic ringtone)














Or maybe you are a mosquito, you certainly can't be human.


The highest pitched ultrasonic mosquito ringtone that I can hear is 21.1kHz
Find out which ringtones you can hear!

啊？這是真的嗎？
是我家的喇叭太爛還是太好？
不過真的最後一個是聽不見了...
張貼者： 於 沒有留言 :
標籤：

2007年11月1日 星期四

SRB與Data Grid

啥是Data Grid，啥又是SRB？ 這個問題其實也在我的心中困擾很久，由於我自己差不多到了這個階段，該是時候弄清楚並且真正提出解決問題的方案了。有一個前提必須提醒大家瞭解一個想法，Grid這件東西，我個人認為比起研究或是虛幻的夢想或者要解決100％的問題，實際地解決60～80％的人認為的問題，就能夠有貢獻了。而過去的經驗裡，很多事情都讓我體認到，眾多的計畫裡，提出眾多的想法，僅只能夠被歸類在「研究」，就像我聽許多老師說，「這就是做研究嘛」一樣。實際上一個東西是不是能夠被拿來做量產，終究還是該關心的問題。這並不是否定各位前輩們的辛苦研究精神，在不可能裡尋找可能是很累人的。只是對我個人而言，我希望經研究作為是一個過程，而不是做了三四年都還在研究階段。 很可惜的是，在我這幾年參與的計畫裡，「研究」還是佔了最主要的目的，而並不是「使用」。這是讓我深感SRB就是一個這樣研究型的middleware，許多的設計是在告訴大家「可能」，但並不是為了要拿來使用而設計。卻實在看過一些文獻後，對於SRB在Machanism Abstraction上的貢獻我覺得相當佩服，對於眾多的儲存媒體，要能夠囊括不是一件簡單的事。但仔細思考，究竟Data Grid希望為大家解決啥問題，會發現路更是長遠。光是metadata abstraction或是machanism abstarction，也不見得能夠解決幾個重要的問題。 以下我透過一些問題來帶入Data Grid的需要：
閱讀更多 »
張貼者： 於 1 則留言 :
標籤：

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。

閱讀更多 »
張貼者： 於 1 則留言 :
標籤：

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，才能讓解答的人知道是啥狀況。

張貼者： 於 1 則留言 :
標籤：
訂閱： 文章 ( Atom )