網頁

搜尋此網誌

2010年7月30日 星期五

Joomla Operation 運作說明

這篇是記錄研究Joomla!的運作原理,主要方法是去分析Joomla!原始碼的內容,沒什麼深奧的技術,大家參考參考就好!還是參閱官方文件網站:http://docs.joomla.org/

依據HTTP Requestfu進入的執行先後順序撰寫如下:
程式的進入點(Entry Point)只有一個:index.php(安裝根目錄中,下述路徑皆以根目錄為相對參考)
  • 定義一些常數名稱
    define( '_JEXEC', 1 );
    define('JPATH_BASE', dirname(__FILE__) );
    define( 'DS', DIRECTORY_SEPARATOR );
  • 呼叫定義檔,裡面更多常數名稱的定義
    require_once ( JPATH_BASE .DS.'includes'.DS.'defines.php' );
  • 載入Joomla框架
    require_once ( JPATH_BASE .DS.'includes'.DS.'framework.php' );
    • 匯入Joomla框架所需要的程式庫 require_once( JPATH_LIBRARIES.DS.'joomla'.DS.'import.php'); 並且利用JLoader::import方法,載入許多物件, 例如JLoader::import( 'joomla.factory');載入JFactory
    • 設定Joomla框架的組態設定 require_once( JPATH_CONFIGURATION.DS.'configuration.php' );
  • 產生應用程式物件,這是繼承於JApplication的JSite物件
    $mainframe =& JFactory::getApplication('site');
  • 實際上是實體化includes/application.php的定義JSite類別, 建立JSite物件,而不是JApplication, 但是注意JSite類別是泛生自JApplication類別,而JApplication類別則是泛生自JObject類別。
  • 初始化應用程式物件
    $mainframe->initialise();
    • 觸發事件$mainframe->triggerEvent('onAfterInitialise');
  • 路由應用程式,決定HTTP Request應該傳送到哪個Component處理,建立JRouter物件。
    $mainframe->route();
    • 觸發事件$mainframe->triggerEvent('onAfterRoute');
  • 批准授權使用者的權限,利用JMenu物件判斷
    $mainframe->authorize($Itemid);
    • 派遣應用程式,將HTTP Request的參數資料取出派遣到對應的Component處理,建立JDocument物件
      $mainframe->dispatch($option);
      • 觸發事件$mainframe->triggerEvent('onAfterDispatch');
    • 提交應用程式,將Component處理後的資料與template結合,提交給JResponse緩衝暫存。
      $mainframe->render();
      • 觸發事件$mainframe->triggerEvent('onAfterRender');
    • 將JResponse輸出成為HTTP Response
      echo JResponse::toString($mainframe->getCfg('gzip'));

    ###

    2010年7月29日 星期四

    Controls in WPF 控制項

    講述Windows Presentation Foundation (WPF)中的控制項(Contorls),對於Windows應用程式開發來說,開發程式非常仰賴控制項,因為控制項就是使用者介面(User Interface)的一部分。

    WPF的控制項是基於System.Windows.Controls.Control類別所泛生出來的子類別,接下來先介紹Control類別的繼承階層架構:
    非常壯觀的類別繼承架構,但是別恐慌!注意到兩個重要類別:ContentControl類別與ItemsControl類別。ContentControl是表示內含單一內容片段(single piece of content)的控制項,換句話說,ContentControl的XAML子節點只能有一個元素,這個元素代表的是ContentControl的內容(Content屬性)。相對的,ItemsControl的XAML子節點可以有多個元素,這多個元素是存放於ItemsControl的集合(Items屬性)之中。

    另外,ContentControl類別與ItemsControl類別的控制項加入標頭(Header)外觀的子類別也很常使用到,分別是HeaderedContentControl 類別和HeaderedItemsControl 類別。

    最後提及一下命名空間(Namespace),控制項的命名空間主要有兩個:System.Windows.ControlsSystem.Windows.Controls.Primitives,其中Primitives的類別是屬於基底類別 (Base Class)的定義,主要做為其他更複雜控制項(泛生類別)的一部分,前述階層架構中的[System.Windows.Controls.Primitives]代表此類別屬於Primitives命名空間之中。

    MSDN參考連結:控制項概觀http://msdn.microsoft.com/zh-tw/library/ms752069%28v=VS.90%29.aspx

    ###

    2010年7月28日 星期三

    Windows Presentation Foundation Architecture

    最近又進一步深入研究Windows Presentation Foundation (WPF),對於一個知識領域,每次閱讀都有不同的收穫,因為視野每次都越來越廣,高度每次越來越高!今天談談WPF的架構(Architecture)

    MSDN(Microsoft Developer Network)參考網址:
    首先必須要知道,WPF是Managed Code的方式運作,也就是WPF必須使用.Net Framework,然而WPF的顯示為了效能因素,設計時不是在.Net Framework的CLR上運作,看看下面的架構圖就能懂了。

    WPF是由PresentationFrameworkPresentationCore milcore(mil=Media Integration Layer)三個部分組成,有三個動態連結程式庫 (DLL) :
    • C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll
    • C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationFramework.dll
    • .NET Framework 3.5 SP1milcore.dll更改名稱為wpfgfx_v0300.dll,C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\WPF\wpfgfx_v0300.dll
    WPF 在 .NET Framework 中的位置。
    WPF的物件非常有架構(OOP就是這樣啊),我們來看看WPF的類別階層(Class Hierarchy)架構,因為實在是太龐大了,我們只看看10個WPF重要的類別。
    比較需要注意到的是DispatcherObject類別,這是WPF的基礎運行原理,可以參閱「執行緒模型」,另外,DependencyObject也是WPF中較特別的一個地方,請參閱「相依性屬性概觀」。

    最後,我想介紹FrameworkElement類別,FrameworkElement加入重要的邏輯樹狀結構功能,並且泛生許多你會用到的WPF類別,像是控制項、面板、頁面、圖形等等,FrameworkElement的類別繼承階層架構如下(僅列出重要項目):
    ###

      2010年7月23日 星期五

      The Sutra of My Heart 送你一首渡河的歌

      我的老師(ycwang)曾經告訴我:「心定」,直到有一天我才瞭解,所有的煩惱都來自於心,而每一次的心煩又讓自己更定性。


      洪啟嵩繪著,送你一首渡河的歌:《心經》The Sutra of My heart,台北:網路與書出版:大塊文化發行,2008。

      大家一起來讀讀Sutra吧!

      觀自在菩薩,

      行深般若波羅蜜多時,照見五蘊皆空,度一切苦厄。

      舍利子!色不異空,空不異色,色即是空,空即是色。

      受、想、行、識,亦復如是。

      舍利子!是諸法空相,不生、不滅;不垢、不淨;不增、不減。

      是故空中無色,無受、想、行、識;

      無眼、耳、鼻、舌、身、意;

      無色、聲、香、味、觸、法;

      無眼界,乃至無意識界;

      無無明,亦無無明盡,乃至無老死,亦無老死盡;

      無苦、集、滅、道,無智亦無得。

      以無所得故,菩提薩埵,依般若波羅蜜多故,心無罣礙。

      無罣礙故,無有恐怖,遠離顛倒夢想,究竟涅盤。

      三世諸佛,依般若波羅蜜多故,得阿耨多羅三藐三菩提。

      故知般若波羅蜜多,是大神咒,是大明咒,是無上咒,是無等等咒,能除一切苦,真實不虛。

      故說般若波羅蜜多咒,即說咒曰:

      揭諦揭諦
      波羅揭諦
      波羅僧揭諦
      菩提薩婆訶

      ###

      2010年7月20日 星期二

      The Professionalism 專業:你的唯一生存之道

      介紹大前研一先生著作的「The Professionalism」,中文書名是「專業:你的唯一生存之道」。

      當初買這本書是因為自己想知道「專業」究竟是怎樣一回事,然而閱讀完這本書之後,大前研一先生定義的「專業」可說是非常正確,每看完一篇文章,真想說好啊!讓人越想一直看下去。(大前研一先生的文章非常具有魅力)

      大前研一著,呂美女譯,專業:你的唯一生存之道,台北:天下遠見,2008。

      第一章「你夠專業嗎」的第一篇文章:「什麼才是專業」,說明了「專業(Professionalism)與專家(Specialist)有點類似,卻不盡相同」,在大前研一先生定義之中,我們一般人所認知的專業其實是專家的意思,這大大誤解了專業的內涵與價值!

      大前研一先生認為專業人士也應該具備醫學界「希波克拉底誓詞(The Oath of Hippocrates)」的精神(詳細內容請google),而對象則是由病患改為顧客,我認為這就是專業的職業道德與誠信原則。

      當下是一個「看不見的新大陸」時代,就像拓荒者進入一個未知的叢林,大前研一先生認為必須具備「先見力、構思力、議論力、矛盾適應力」這四個能力才稱得上是「專業」。擁有先見能力,我們才能找到新叢林前進的方向。擁有構思能力,我們才能在新叢林中勇敢前進。擁有議論能力,在新叢林中才不會走進陷阱之中。擁有矛盾適應能力,我們才能在新叢林中建立新的生存法則。

      最後,我不得不承認自己的經歷實在有限,大前研一先生所說的我不能完全領悟,但這的確是一本值得細細品味思考的書籍,如他自序中所言:這是幫忙培育專業人士的教科書,教導我們不是如何去做,而是讓我們什麼才是「專業」的精神。

      我們所能倚賴的,只有自己。」書末結語非常切實!

      2010年7月13日 星期二

      The Daily Review 2 心得日誌2

      在一群大象中待久了,整理一些組織生活的心得報告,避免日子一久遺忘自己曾經是隻怎樣的跳蚤!Thanks to Charles Handy.

      「Daily Review」心得日誌第二篇:「組織這樣做應該會更好」。

      每天早上的會議跟升旗唱國歌沒有兩樣,只是例行公事。
      會議不是為了討論如何解決問題,而是為了釐清責任而開會,
      唯一的用處是:這是一天當中我和太陽神阿波羅對話的唯一機會。

      如果早上不開會,整天我就不曉得為何要存在於大象群之中,
      會議的內容是跳蚤們報告每天的進度,每隻跳蚤輪流說明專案的工作進度,
      阿波羅一般而言不會和跳蚤有所對話互動,純粹是單方向的溝通契約,
      最後只會詢問跳蚤們還有沒有事情?或是現在進度到哪裡?
      對話內容似乎只是為了善盡阿波羅的責任。

      會議每次應該訂出討論議題,善用白板繪製圖像,
      這樣才能發揮眾人智慧的力量,溝通交流更加順暢清楚,
      而且應該每次都要記錄討論事項內容,這樣才能瞭解討論是否有所盲點,
      可惜的是大象群沒有這樣的文化,似乎也不想去改善求進步,
      這樣的大象可預期已經生病了。

      大象群似乎不太注重跳蚤的教育訓練,而且跳蚤之間似乎沒有團隊合作的情形,
      跳蚤不訓練算是沉浸理論(Immersion Theory)的實踐吧!
      沉浸理論把跳蚤丟下水,看看跳蚤會不會自己學會游泳,
      反正跳蚤們最後都會慢慢習慣大象群的一切,
      阿波羅何必花時間教導訓練跳蚤呢?跳蚤對大象群只是過客而已。

      我認為跳蚤一定要教育訓練,因為我們必須對我們的顧客負責,
      阿波羅應該教導新人至一定的知識水準,不需擔心新人會學走任何知識,
      因為我相信經驗是很難傳授的知識,而這正是阿波羅最有價值的財富,
      更重要的是培養新人符合組織期望的工作態度。

      新人沒有一定的訓練,未來一定會傷害到顧客,更反過來讓組織受傷,
      從資料中可以看到麥肯錫管理顧問公司(McKinsey & Company)、通用電氣公司(GE,奇異),
      這些公司都不怕教育訓練新人,而且對於人才非常投資,因而吸引一流人才。

      好的人才,才能夠形成好的組織,好的組織才能提供好的服務,
      也因此能夠有好的獲利,最終滿足顧客、股東和員工的需要,形成一個正向循環的成長。
      新人一定要教育訓練,而這種教導不只是依靠大象群的制度,阿波羅也必須教導新人。

      跳蚤在大象群待久了,如果一開始的大象群文化不好,很容易產生劣幣驅逐良幣的情形,
      因為跳蚤要影響大象群通常很困難,於是好的跳蚤會離開大象群,留下不好的跳蚤與文化。

      以我看到大象群來說,團隊合作的方式很奇怪,一隻跳蚤接一個專案,
      在這個專業分工化的時代,要求跳蚤應具備所有專業能力,這實在是不可思議!
      或許只是為了讓跳蚤承擔所有的責任,萬一專案失敗才有人可以扛。

      大象群中的分工最容易發生的問題是推卸責任,為了避免跳蚤推卸責任,
      於是每隻跳蚤開始劃清責任,跳蚤盡最大努力讓事情最少,責任最小,
      這樣又要如何形成開放、創新、團隊合作的文化呢?

      關於這個問題,或許要從大象群的制度面著手解決,畢竟文化的改革很難,
      但是對於大象群而言,只要是「改變」都是困難,通常會遭遇很多跳蚤的批評,最後不了了之。

      有容德乃大,無求品自高。待續...

      2010年7月12日 星期一

      DirectShow.NET Principle 工作原理

      DirectShow.NET用了一段時間,差不多也快忘了!趕快紀錄DirectShow.NET的原理,當時研究了一陣子好不容易搞清楚。

      DirectShow.NET是一個程式庫(Library),目的是讓你的.NET Framework可以使用Microsoft DirectShow API,DirectShow.NET基本上是利用.NET Framework的互通性(Interoperability)元件叫用方式呼叫DirectShow API,而DirectShow本身是COM元件。

      可以參考MSDN這兩篇文章,你就大概清楚DirectShow.NET的工作原理:
      • COM Interop Part 1
        Shows how to use C# to interoperate with COM objects. Covers a C# client.
      • COM Interop Part 2
        Shows how to use C# to interoperate with COM objects. Covers a C# server.
      如果還有興趣,可以打開DirectShow.NET的原始碼,你可以看到基本上都是一些定義宣告,可以自己寫(你可能需要Globally Unique Identifiers (GUIDs)或是COM Class Identifier (CLSID),別怕,參考Windows SDK中的標頭檔,通通有寫清楚),但是自己寫很花時間也可能有Bug,所以直接使用DirectShow.NET程式庫是最有效益的!(No Need To Reinvent The Wheel.)

      對於想要利用C#來撰寫DirectShow的開發人員,你可以參考DirectShow.NET的範例程式,這會讓你更快上手!尤其是有專案壓力的情形之下。

      2010年7月8日 星期四

      Geometric Matching 幾何比對

      這篇將介紹數位影像領域中幾何比對(Geometric Matching)的課題,幾何比對是利用幾何形狀的資訊,目的是要找出影像之中,存在與樣板(Template)影像相同(相似)的影像區域。

      幾何比對的程式運作大概是這個方式:
      1. 建立欲尋找物體的樣板影像,計算出幾何的特徵。
      2. 程式利用樣板的幾何特徵,搜尋影像中與樣板相似的區域。
      3. 計算這些區域相似的程度並於以量化評分(score)
      4. 最後依據評分的高低,程式可以找出與樣板最相似的區域(即目標物)。
      5. 結果將包括目標物的數量與位置。
      幾何的比對搜尋與下列特性無關:光線變化(lighting variation),影像的模糊(blur)、雜訊(noise) 與閉塞(occlusion),幾何空間轉換像是移動(shifting)、旋轉(rotation)與縮放(scaling)。因為幾何比對關注的是物體的幾何形狀。

      我們利用幾何比對通常是為了下列的應用:
      • 空間量測(Gauging)
        量測物體的長度、直徑、角度或其他量度(dimension)。
      • 檢驗(Inspection)
        偵測物體上簡單的缺點(flaw),指形狀上的瑕疵。
      • 對齊(Alignment)
        找出物體的位置(position)與方向(orientation)。
      • 分類(Sorting)
        基於形狀或尺寸的分類。
      必須注意到利用幾何比對的前提是:欲搜尋的物體(提供的樣板)本身必須要有明顯區別的(distinct)幾何形狀資訊,通常是利用影像的邊緣(edge),否則比對將無法順利進行(發生誤判斷)。另一方面,若欲搜尋的影像中有太多的幾何資訊(太多的邊緣資料),程式計算比對的時間也將會增加,於是影響幾何比對運作的效能。遇到上述的情況下,則建議使用樣式比對(Pattern Matching)

      幾何比對的過程分成前後兩個階段:學習階段(Learning Stage)比對階段(Matching Stage)

      學習階段的過程中,程式萃取樣板的幾何形狀資訊作為比對的特徵值,程式將儲存這些特徵值以及特徵值的空間資訊。在比對階段的過程中,程式將萃取影像中所有的幾何資訊,並且和先前學習的特徵值進行比對和評分計算,程式最後將選出與樣板相同的影像區域。

      幾何比對技術的核心基礎是以曲線萃取(Curve Extraction)的方式取得影像中的幾何資訊,利用萃取後的曲線資訊作為比對的方法則有兩種:
      • 邊緣為基礎的幾何比對(Edge-Based Geometric Matching)
      • 特徵為基礎的幾何比對(Feature-Based Geometric Matching)
      一般來說,Edge-Based是利用物體全部的幾何資訊來比對,相對於Feature-Based只用部分的特徵比對,因此,Edge-Based的辨識率較高,可以的話,盡可能使用Edge-Based的幾何比對方法。

      當然,事情不是想像中的簡單,凡事都有優缺,決定前都必須權衡取捨(trade-off),下列列出Edge-Based與Feature-Based的相對比較,可以作為選擇方法的參考。

      Memory
      Requirement
      Matching
      Speed
      Recognition
      Rate
      Template
      Restriction
      Edge-Based 任意形狀
      Feature-Based 明顯且易區別的形狀

      2010年7月6日 星期二

      Joomla Programming

      Joomla!是一套Web的內容管理系統(Content Management System, CMS),具有完整的前台語後台架構,Joomla的擴充模組也很多,開發模組也相當容易,本文先介紹1.5.17版本的程式架構,希望對於想要開發Joomla的人員能有所幫助。

      Joomla!架構圖(取自官方網站http://docs.joomla.org/Image:Joomla_Architecture.jpg,更多資訊請參閱http://docs.joomla.org/Main_Page)

      資料夾說明:
      1. administrator=>後台管理
      2. cache=>快取
      3. components=>元件
      4. images=>影像
      5. includes=>副程式
      6. installation=>安裝檔
      7. language=>語言
      8. libraries=>程式庫,包含Joomla!框架的程式庫(framework)。
      9. logs=>日誌
      10. media=>媒體
      11. modules=>模組
      12. plugins=>外掛
      13. templates=>樣板
      14. tmp=>暫存區
      15. xmlrpc=>可延伸標示語言‧遠端程序呼叫
      檔案說明:
      1. CHANGELOG.php=>修改日誌檔。
      2. configuration.php=>Installer安裝程式產生的組態檔。
      3. configuration.php-dist=>原始的組態檔(distribution),手動安裝Joomla才會需要用到。
      4. COPYRIGHT.php=>版權宣告
      5. CREDITS.php=>榮譽榜,包含貢獻者與Joomla內自由軟體的清單。
      6. htaccess.txt=>Apache存取的組態檔。
      7. index.php=>Joomla!進入點(Entry Point)
      8. index2.php=>只顯示元件輸出內容。
      9. INSTALL.php=>安裝說明
      10. LICENSE.php=>授權條款
      11. LICENSES.php=>完整的授權條款內容,包含BSD License,GNU Lesser General Public License (GNU LGPL) version 2.1與MIT License。
      12. robots.txt=>搜尋引擎漫遊器的組態檔
      Joomla是非常有架構的一套CMS,非常適合用來當作開發平台使用,而且擴充元件(Component)很多,說明文件詳細清楚。推薦!玩網頁的人也一定要會一套CMS,就是Joomla!啦。

      The Daily Review 心得日誌

      「Daily Review」心得日誌:在一群大象群中待久了,整理一些心得報告,避免日子一久遺忘自己曾經是隻怎樣的跳蚤!Thanks to Charles Handy.

      早晨開會,
      阿波羅只問我資料閱讀了沒有,我回答「看了」,
      我和他的對話就此結束,彼此沒有任何交集。

      阿波羅似乎不知道應該問我什麼事情,
      他想了一個很普通的問題,目的只是為了破除兩人之間的寧靜。

      阿波羅說:「應該加班的時候,還是要加班。
      專案的里程碑(milestone)快要到截止期限了,
      不要讓沒有加班變成專案延期的原罪(Original Sin)。」

      專案延期究竟是人力的問題,亦或是專案規畫的問題呢?
      如果是人力問題,是不是應該增加跳蚤,而不是要求加班。
      不找尋專案延期發生的原因,只求跳蚤加班祈求心安,這種文化還能讓大象群存活多久?

      阿波羅問我:你這個專案研發要多久?
      我說「我目前無法預估,因為這個新專案我正在開始研究而且不熟悉,後續會遇到多少問題必須解決我也不知道!沒有辦法跟你預估時間」
      阿波羅也說;「專案總要有個期限,你要盡量保持住時間,兩個月夠嗎?」
      呵呵...(我笑了)

      問題在於根本就不清楚專案的需求,又如何達到目標呢?
      就像是你只說要吃飽,我弄了炒麵給你,你說如果可以吃炒飯更好。
      我弄了炒飯給你,你又說炒飯要加蝦仁,最好還有紫菜蛋花湯。
      我都弄給你吃了,你吃完說其實我想吃牛肉麵,好吧!
      弄了牛肉麵給你,附上小菜一盤,這樣可以了吧!
      你說牛肉不好,你要半筋半肉的清燉牛肉麵,麵條要刀切的...沒完沒了。
      你為什麼不一開始就先說清楚!是因為你也不曉得要吃什麼才好。
      要是專案遇到這種,真的會瘋掉,大象群的資源也因此浪費掉了,可惜。

      跳蚤們每天下班擬定好明天早上開會的說詞,
      週一敘述這週的預期進度,週五報告完成的進度,
      於是只剩下三天的報告內容需要想想,內容通常是報告昨天做了什麼事情,
      這就是為了開會而開會檢討,完全沒有實質的意義。

      雖然說開會沒有任何意義,但是說話千萬不要低於一分鐘的內容,
      這會讓阿波羅感覺你沒有做事情,跳蚤的原則就是用嘴巴做事。
      只要敘述你問其他跳蚤什麼問題,跳蚤回答你的內容,再加上你閱讀什麼資料,
      這樣的模式絕對可以講三分鐘,冠冕堂皇!

      豈能盡如人意,但求無愧我心。待續...

      2010年7月2日 星期五

      Organizations and Individuals 2 組織與個人2

      查爾斯‧韓第 (Charles Handy)的啟發,Thanks to Charles Handy.

      接續之前曾寫過的部落格文章「組織與個人」,這是第二篇,我想記錄一些我在「大象群」中所觀察的心得感想(我附屬的是一家全球逾六萬跳蚤的大象群,故稱之為「大」),必須說明的是這些觀點可能不完全,因為我只是位於大象群中的一個大象,自己如同井底之蛙

      大象群多數存在一個文化:「可以推就推,不可以推就閃,閃不過就躲,躲不過就拖,好過揹黑鍋。」困難的工作最好永遠不要淪落到自己的身上,輕鬆過日子領薪水會比較快樂,何必那麼辛苦呢!我認為一個人一旦有這種想法之後,個人就開始變爛了!

      如同韓第先生所說的「S曲線(Sigmoid Curve)」理論,只不過我說的是相反方向。S曲線(Sigmoid Curve)理論是「解釋公司如何成長,以及最後可能如何失敗,而這條曲線運用到個人生命以同樣適合。」

      個人進入組織後開始學習,到達S曲線的最高峰(也許是職位),之後曲線向下彎曲(學習進度開始下降),個人進入S曲線的最低點,就在這裡因為太爽(不用學習,而且擁有職位和權力),個人思考對策展開另一段S曲線,邁入另一個低點中的高峰和另一個最低點。

      總體而言,個人的學習開始僵化退步,個人開始邁向一個又一個的低點,對於組織而言,這樣的「負S曲線(Negative Sigmoid Curve)」如同癌症慢慢消耗組織的營養,個人可以不進步,可是組織必須要進步才能競爭生存。另一個角度來說,組織如果不進步,我們自己還是要進步,不能將眼光只侷限在這個組織之中,世界全球還有更多優秀的組織等著我們進入。

      熱門文章