2017九宮飛星方位運程

今年當旺位在東方, 三煞位亦在東方, 所以會較辛苦。若大門在屋的東位, 或睡房門在睡房的東位, 或帎頭在睡房東位, 則今年會行運, 可能是搵辛苦錢多勞多得得一年。

東南及西南方, 為次旺位。今年運程都會幾好, 而冇東位既人咁辛苦。

太歲位為西方, 西面不宜多動土或出入。

災位在南方, 大門/房門/帎頭在南面的今年會不太順利。要化解, 可以在南位掛風鈴, 或放置銅鑼之類金屬聲的東西。(hifi不能, 因為有電為火, 火生土加強廉貞災煞力量)

西北方亦有可能會多病, 要小心健康。

Tier Model and Lego Block Model

Why Tier Model is bad

 

 

Just think about, eventually every application and every code would be legacy in the future. Always there would be a day application need to migrate/change to better solution.

 

 

Everything which build on your tier means that they rely on your tier. The more coupling/specific tricky logic in both tier for integration, the more pain you would have when you change/evolve. It is a kind of long term technical debt which sometimes people may not be aware.

 

Lego Block Model

 

 

Design components in a way such that components are not tier-on-tier. Instead, make it plug-and-playable blocks.
It might be application side to control and plug the components they want, and such plugging would better be fault tolerable, and have fallback handling.

“Application are not on top of (live on) your component, they just make use of your component.”

One more thing to mention, each component should make their integration interface as thin and small as possible. Delegate integration as REST API is a usually work solution.

 

Component dependency: Cross cutting dimension

The inter-component relationship, for different models, has different dependency complexity.

  • Tier-on-Tier relationship is plane-to-plane (2D)
    • E.g: Application on top of weblogic container has to compatible with weblogic container. The compatible complexity is a plane because upper tier component sit on top of lower tier component (as a platform/plane).
    • Difficult to switch tier solution.
  • Block-to-Block relationship is node-to-node (1D)
    • E.g: Application consuming another application through REST API. The technical coupling part is on HTTP/REST protocol, which is industrial defined standard.
    • Switch solution is easier.

For example, older/existing way to do web service component is making a code generation tool to generate required code. It is code level solution. Actually such component has to fit with the programming language or the application container. The cross cutting integration is a plane. It is even not mentioned the case if you have multiple programming language solutions.

Instead, more modern way might be making a API gateway component. The logic is put behind the gateway instead of code level codes. It is easier to live for application component to just call API gateway, instead of including framework jars in their codes.

In reality, it is not possible to archive absolute “1D” relationship. But we can still design in a philosophy that inter-component cross cutting part as thin and small as possible.

 

 

Is Tier model equal to”Platform solution”?

From the above, it may sound like I disagree with “Platform solution”. But actually it is not true.
I think “Tier” and “block” are just abstract concepts. While “Platform” is just a dummy term, “Platform solution” can be designed as a tier or a block style.

Semantically, the wording “platform” in “platform solution” is describing the component’s business logic’s role but not component architecture model. We should aware of not mixing up these two concepts.

And what I said above about tier models, are talking about component architecture model. To better understanding, we may better focus on the philosophy of “dependency complexity” and “minimizing technical dependency”.

IT狗up – 講API platform solution講trend講生態

而家個時代是開始興唔玩monolith,轉玩API﹑microservice﹑container﹑distributed system等。

之前自己睇過既,坊間都開始有好多圍繞住API生態既platform solution。
而好多platform solution,簡單地說實際在做的都是這幾件事:
1) API owner 管理 API definition
2) 幫API owner 起隻 API portal
3) third party developer subscribe API
又或者我換個角度去概括呢幾件事,其實成套野就係facilitate去幫API owner同thirdparty developer做API形態既contract initiation。

但而家仲係個trend既岩岩開始,所以果d API生態未係好成熟,而platform solution亦可能同步地有少少濟後。
前面都有說過,坊間Platform solution,比較集中於API contract initiation。
但其實我看到的是,那些solution比較缺少了API integration test﹑後續維護的部份。

過往既API service形態都係一d比較concrete,少change的穩定soa service。
現時(2017)坊間大部份生態都是舊生態,都是比較CONCRETE﹑少CHANGE的穩定soa service。
而亦因為現時大部份API是相對穩定﹑少change,
所以在build contract之後也未必會改動;
所以即管platform solution缺少了API integration test﹑後續維護的部份,問題並不大。
所以這「缺少」,除了可能是現時的人的vision問題,也可能是未成熟生態所促成。(too-early未必是好事)

我預期過多三兩年,IT architecture生態開始改變,應該會越來越多microservice/API as service既形態。
形態成熟之後,就會浮現現時2017年未浮現的問題:
「你d API係咁change,我d API又係咁change,點maintain呀大佬?」
當成個生態都keep changing,2017當下這種純粹build contract的solution顯然是不夠的。

到時,除了當下較著重的API/microservice各自獨立的unit test,亦更著重如何做mock/integration test。
API management platform solution生態圈中需要的add-on,可能是API signiture management。
而unit test ﹑ API signiture ﹑ platform solution,會有更緊密的串連。

file-query.js – nodejs module using jQuery to manipulate your folders/files

Recently, I wrote a opensource node.js module “file-query” and put on github. (It is my first opensource github project.)

The basic concept of this module is mapping folder directory structure into virtual DOM structure. And then the module allow you to use jQuery syntax to select and even manipulate the virtual DOM structure in order to manipulate folders/files.

Github: https://github.com/airicyu/file-query
NPM: https://www.npmjs.com/package/file-query

 

Example:

The above code first load the “file-query” module, and then scan folder structure’D:/root/d1′ in order to create virtual DOM mapping.

And then in the later code, we use jQuery selector and manipulation functions just like what we do usually with jQuery. We find directories under path “d:/root/d1/d2”. And then find directory “d3”. And then find all directories under it which has name start with “abc”. And then find all child files. Finally we rename all those files.

More examples can be found in the Github webpage.

 

雨傘革命後的時代 – 勇武or和理非

當初雨傘革命後, 我認為, 勇武之路很快會到樽頸, 暫時走不成, 其後就不得不反省, 稍稍反向轉傾溫和。
而溫和路盡, 也不得不轉型進化。
換言之, 兩者光譜上會傾向converge。

在勇武與溫和兩極派系光譜之間, 世代轉化, 需要的是中間的光譜連接。那正是勇武派中的溫和主義反思, 以及溫和派中的改革力量。

光譜converge, 光譜連接, 這是我由從前就一直支持青政, 及後來的香港民族黨的原因。
至於香港眾志, 雖因理念而不認同, 但我也樂見其成。
我一路走來如此立場取態, 正是出於世代轉化光譜考量, 至今思量不變。

很多人可能只道我常撐青政吧。
但其實我開心見誠, 只要真係拎個心出黎為香港/抗爭, 我都會撐, 尤其是弱勢組織/後來者/後輩。
熱不熱, 左不左, 我倒是不多計較。

對於社運抗爭該走的方向,
我起碼成年幾之前已經講過, 社運要回頭轉向社區。
在上帶動港人自主意識形態, 在下結合社區/地區議題, 上下連動。
溫和, 勇武, 議會, 地區, 前詹, 保守, 各從其類, 不需要統一/大台, 而是需要找到連動的”軸”。

“鄭松泰:熱血公民撤出社運-加強社區服務”

回想過往, 本土派系中某些言論, 指”投機”, “面目模糊”之類……今日會否以同樣理據同樣批判鄭松泰/熱?

又回想, 另一邊廂, 有些人當初聲言青政”收中共錢”, 如今還有人如此說嗎? 民主派自身獲中共恩準派回鄉證, 自己收野就咁高興?
又, 有些人口口聲聲”從現實論幫梁振英助選”, 到今時今日梁振英唔選,班人除左扮冇左回事, 有冇出過黎找數解畫?

當梁遊說籌錢打官司, 黃絲們以一些statement去crit。
ok的, 但當你為那四位議員籌錢打官司, 唔該老實一點同樣地面對返之前自身的statements。
說穿了, 班人根本上早預設立場, 才堆砌理據, 到自己友有事, 就扮晒野當冇回事。仲要勁肉酸地”四位”, 姿態式做下樣都費事。

青政梁遊生死, 本身事小。因社運會有後來者上。
但社會裡許多人事, 言論, 行為, 都經不起時間驗證。隨波逐流, 捕風捉影, 這些事遺害更大。

remarks
利申, 我是贊同鄭松泰走向社區的決定(但不認同撤出社運)。
利申, 由始至終我立場都是撐六位被司法覆核的泛民主派議員。