jim yeh on 九月 26th, 2007

以前在剛開始練太極拳時,師父常教我們要放鬆,而我們能夠體會到的鬆只有「不用力」,所以出掌成爪也常常是很正常的一件事。隨著招式逐漸熟悉之後,慢慢體會到放鬆除了不用力之外,更重要的是精神上的收攝與專注。 換句話說,鬆代表了兩種不同的層面,一方面要放掉不必要的力氣,在另一方面,精神上則要專心維持在這種鬆的狀態下,也就是把握「用意而不用力」的原則,而才能自然地打出太極拳發勁的味道。 其實許多師兄姐一開始都會想學師父的發勁的動作,但怎麼學都不得要領。師父的教拳風格是要先讓我們把整套拳招式摸熟了,再慢慢從招式細節中去體會鬆、沉、專注,才能真的體會出拳的內涵出來。 模仿是很難學會發勁的,而是要在全身放鬆的情況下,集中在圓周的一個點以全身之力貫穿出去,師父說這就是所謂的忽靈勁,因為動作看起來也像是突然全身抖一下,又稱之為抖縮勁,這也是陳家小架太極拳中的特有發勁方式。在此,舉師父常提毛巾隱喻發勁威力的例子,雖然毛巾是柔軟的,但在完全放鬆的抖縮勁道,卻是可以傷人於無形的。

Continue reading about 練拳體驗鬆之意境

     
jim yeh on 九月 26th, 2007

上次提到用服務層的概念整合業務流程與功能性交易,並指出因應交易流程整合的非同步呼叫考量的兩種技術實作方式,也就是 database sharing 與 message queue 的不同做法。兩種做法會殊途同歸,最後會依據處理狀態,呼叫後端的服務進行後續系統作業。 既然兩種做法會殊途同歸,那麼在設計上,可不可以設計出同時適用不同實作方法的非同步機制呢?依據這樣的設計思路,我們會希望把會變動的部分用界面封裝起來,如下圖所示。 在上圖的設計中,我們定義了一個 ServiceEvent,用以記錄交易識別碼、交易階段代碼及流程代碼等資訊,其中流程代碼的目的可提供系統進行更精細的控制,而交易識別碼及交易階段代碼則是用以取得交易目前處理狀態以讓系統繼續處理交易的後續動作。 ServiceEvent 由 EventAdvice 產生,並由 EventListener 讀取,而傳送及接收 ServiceEvent 的任務則交由實作 EventSender 及 EventReader 的類別來處理,如此便可達到不會因為不同的實作方式而更動到設計。

Continue reading about 流程與交易的整合(其二)