個人經驗談現實中的 SOA, part 2 - 訊息、訊息、訊息
本系列文章–個人經驗談現實中的 SOA– 最初發佈在台灣PHP聯盟討論區,所以也有在討論區的網友們回應他們的看法。本文整理了我與網友的對談內容,並藉此做個結論。
謝謝 tokimeki, robmlee 兩位網友的回應。
本系列文章–個人經驗談現實中的 SOA– 最初發佈在台灣PHP聯盟討論區,所以也有在討論區的網友們回應他們的看法。本文整理了我與網友的對談內容,並藉此做個結論。
謝謝 tokimeki, robmlee 兩位網友的回應。
我目前任職於一間百貨流通業的資訊部門,在這裡資訊系統往往不能滿足業務單位,即採購、倉儲、物流、批發與門市零售等單位之需求。我注意到,儘管業務單位總是嚷著軟體不符需求,但企業資訊系統的真正問題並不是不夠,事實上是太多了。不敷業務工作需求的原因,在於資訊無法在這些資訊系統之間平順地移轉流動。每當我們試圖引入一套資訊系統以為這樣能滿足業務單位需求時,往往事與願違。現實狀況是每多一套資訊系統,業務人員就多一份電腦文書工作,這才是業務單位抱怨的事。
這幾天我和 HACGIS (トキメキ) 在討論 PHP 的參照 (reference) 特性。對於參照的功用,我想我們都很清楚了,還不了解的讀者可以先參閱《PHP Manual::Chapter 21. References Explained》以及 HACGIS 的《使用參照的幾個原則》,HACGIS 的文章是本文討論內容的起點。
在 PHP 中能否以「中文字」作為變數、常數、函數的符號名稱呢?當然可以,但現階段有些注意事項與使用障礙。本文是個人經驗,供各位參考 (對了,我個人不將程式語言視為「英文」。而那些以 a-z0-9 等字母組成的符號,我僅將其視為視覺識別符號。嘿嘿,畢竟我英語發音很差,那些字大多數是以字形識別其意的)。
紐約時報 (The New York Times) 2006/12/26 科學版有篇關於演化賽局的報導,這篇報導是生物學家針對生物的欺騙行為所作的演化賽局研究。報導中最引我注意之處在其指出社會化程度愈高的個體,愈會說謊。
Solitary animals may evolve to be more honest than animals that spend long lives in big societies. If that is true, then humans may be exquisitely primed to deceive.
Devious Butterflies, Full-Throated Frogs and Other Liars © 2007 The New York Times性喜獨行的動物可能演化成比在大團體裡度過一輩子的動物誠實。果真如此,人類極可能是隨時準備說謊的老手。
紐約時報科學版 - 聯合報 2007 年1 月 8 日精選中譯 © 2007 聯合報
無意中在自由時報看到一篇讀者留書,作者名為「白麟」,文中轉述著所謂「新知識份子 (Modern Intellectual)」是:
「全部為著人民,但不跟人民在一起」。此外,德國Tuebingen大學Kotchoubey教授也稱呼這些新知識份子「在沒有風險時展現勇氣,在沒有危機中冒險,並勇敢的朝向沒有敵人的地方戰鬥著。」 除此之外,他更嘲笑這些新知識份子,「相較於蘇格拉底他什麼都知道,相較於笛卡兒他卻永遠都不會懷疑」。
Kotchoubey 的形容非常好,我一看到就想把這些句子記起來,特別是「相較於蘇格拉底他什麼都知道,相較於笛卡兒他卻永遠都不會懷疑」這句,可以做為學術警語,提醒自己不要成為這種人。
此外,我也覺得自由時報會刊載這篇投書頗不可思議。因為 Kotchoubey 所形容者也可以套用在陳水扁俱樂部的會員身上。那一群人掌握著政府權力,有何風險有何危機,卻又在權力的傘下高喊著政治迫害、新聞迫害。雖然我一直懷疑自由時報的編輯是否只喜歡挑中意的內容報導,但從他們接受這篇投書來看,或許我該修正我對自由時報的觀感。
我前幾天心血來潮地跑到博碩士論文資訊網,本想看看我當年的碩士論文在哪裡,結果發現竟然沒有提供電子全文下載。這可怪了,我當時明明採用 GNU FDL 授權了,為何沒有提供電子全文。於是我寫信去問,國立圖書館也很快地答覆了。
tokimeki 在回應《動態語言關於參數宣告的寫作風格》時提到: 所以我只要在函數內設定一個預設陣列,然後把參數陣列以及預設陣列丟進去處理就行了,傳回來就得到過濾好的參數陣列,而且保證每個參數都有值。接下來就可以對每個參數作驗證、運算等動作。
這個作法還可以按所謂「Configuration Driven Development」的概念進一步改良。 Configuration Driven Development 是以中介資料描述軟體運作時的組態,我們藉由組態內容便得以調整與協調程式運作的內容。可以參考 Steve McDuff 的這篇:《Configuration-driven development》。
tokimeki 日前回應的文章中提到 然後在函數內作過濾參數動作
,讓我想起在不同程式語言對參數宣告一事有著不同的寫作風格。我就從參數宣告的寫作風格中,展現一下不同程式語言的各種風貌吧。
日前我在《相信我看不到的事物,除非我能證明它不存在》的回應中,針對 Karl Popper 的科學哲學理論做了一番維護。然而這個立場只在其用於自然科學領域時成立。
雖然 Karl Popper 在社會科學領域中也頗有名聲,並因著有《開放社會及其敵人》一書而常與海耶克 (Hayek) 一起被視為自由主義的代表性人物,但具體而言,其研究方法並不適用於社會科學。對於 Popper 的說法,米塞斯 (Mises) 表示 這只是語言上的詭論
(Mises, 1962/1991)。
我先前為了測試 PHP5 的 reflection 能力,找到《Benchmarking dynamic function/method calls》為參考文章,寫了一段效率測試碼。剛好今天看到 HACGIS 也做了《各種呼叫方式的比較》。因為 HACGIS 沒測到 reflection 的部份,所以把我的效率測試碼也放上來供各位參考。
我參加 2006年「微軟應用平台架構優化」研討會時,在《 建立新一代使用者操作經驗的 Windows 與 Web 應用程式》議程中,我寫下一句話 "Write only one Control/Model with two or more Views." 此為我對該議程內容的總結。
該議程主要介紹使用微軟的 WPF/XAML 技術開發「新一代使用者操作經驗」的應用軟體,然而我看到的只是微軟將一個舊技術按自己的策略量身打造的專有規格。我說的舊技術,是指使用標籤語言 (markup language) 設計應用軟體呈現層的方式。這句話聽來很玄,但其實早已非常普遍, HTML 就是這種技術的最佳代言人。
本人部落格之內容,明顯標示採用 GNU Free Document License (GNU FDL) 授權條款分享,而其他部落格大多數採用 Creative Commons Attribution-NonCommercial-ShareAlike (創用CC 姓名標示─非商業性─相同方式分享) 授權條款分享。由於這兩者之內容不相容,為了避免使用者無意中觸犯著作權,我在此說明 GNU FDL 與 CC 不相容。若在採用 CC 授權條款之部落格或論壇等處轉載本人著作,須註明著作是採用 GNU FDL 授權,否則將侵害本人之著作權。
我曾在《Copyleft 與 GNU Free Document License 在部落格寫作上的適用性,兼論 Creative Commons 與 Copyleft 的相容性》討論過這兩者的不同。在 CC 中也僅有 Creative Commons Attribution-ShareAlike (創用CC 姓名標示─相同方式分享) 之授權形式符合 Copyleft 精神;我最不樂見者,則是加上「非商業性」用途限制的 Creative Commons Attribution-NonCommercial-ShareAlike (創用CC 姓名標示─非商業性─相同方式分享) 。雖然在 GPL-ism 與 BSD-ism 之間,存在著是否應該限制以相同方式分享的歧異,但這僅是道德與哲學的問題。「非商業性」之用途限制,則明顯偏離自由或開放著作權的精神了。
我寫了篇寓言,篇名為《夏目寓言, 夏目看到一隻貓長著兩條尾巴》。我在寓言中所對答的種種內容,總結起來就是一種「科學態度」,亦即 Karl Popper 所主張的「證偽法 (falsifiability)」。我建議在繼續閱讀本文前,先看看那篇寓言。
這是一篇寓言,起因是我近日看的一套漫畫,「綠川幸」著作的《夏目友人帳》(台灣由東立出版社代理翻譯中文版,中文版書名《妖怪聯絡簿》) 。看漫畫是件有趣的事,我在閱讀時常常會假想自己若是書中一份子,又該如何扮演我的角色,又會如何與書中角色互動。我看完《夏目友人帳》後,設想自己是書中的角色,碰到主角「夏目」時會跟他說些什麼。我所假想的內容,便成為這篇寓言了。
在進行任何程式的設計工作之前,我們必定已經知道程式的輸出入結果,亦即我們已經確知當使用者輸入什麼資料後,程式應該輸出什麼結果。更進一步說,我們已經知道使用者將如何使用這個程式,諸如使用者在操作過程中會做什麼事,而程式對操作內容應該如何回應等等。這段理所當然到近乎廢話的敘述,卻是所有軟體設計人員惡夢的開始,也是所有軟體工程實踐作法的起點。在 eXtreme Programming 中,我們稱這些內容為「故事 (story)」;在 RUP 中稱之為「使用案例 (use case)」;在 Microsoft Solution Framework 中稱之為「情節 (scenarios)」。我個人偏好使用「故事」一詞,因為它不像術語。既然故事是設計人員惡夢的開始、設計工作的起點,那麼就先說一個故事。
欲建立一個運動會報名表單,一位選手可報名參加一個以上的項目 (如100公尺、200公尺等) ,資料庫表格應如何設定?
我們通常不會在一個選手表格中建立多個比賽項目的關聯欄位,像 game1, game2, game3 這種欄位設置就不太適當。第一、如果多數選手只參與一個項目,則剩下的 game2, game3, etc. 欄位就閒置了,佔用磁碟空間。第二、限定了可參加比賽項目數的上限,如果我只定義到 game3 ,則一位選手最多只能參加 3 個比賽項目。第三、只能用複雜且僵化的查詢語句,例如 SELECT * FROM "Players"
INNER JOIN "Games" ON "Games".id = "Players".game1 OR "Games".id = "Players".game2 OR "Games".id = "Players".game3;
,欄位愈多則 OR
條件 串的愈長。當然,如果程式需求限定每位選手至少參加一個項目,最多參加 2 個,那麼用這種方法倒也無妨。