留下還是離開?

早幾年從一些有宗教信仰的朋友身上看到一種處境:
對於宗教團體(e.g:教會)的腐敗不堪,人們對去留會有兩種極化的取態。

(1) 認為應忍辱負重,留下來改善情況。
宗教團體當權者本身既已腐敗不堪,若有良知的人都走了,那麼在團體裡的年輕人,豈不是任由當權者洗腦教壞?誰來保護那些年輕人?

(2) 認為不應參與宗教團體其中。
因為當有良知的人決定留在宗教團體裡,那變相是正當化﹑合理化了宗教團體。
別人很可能會說這樣的話:「你看,那人是有良知的,都留在這教會,這教會一定是好的地方吧」
結果亦會吸引到一些年輕人投入腐敗不堪的宗教團體(e.g:教會)

其實這問題,不只是宗教團體,而是在很多不同地方也會有這種兩難困局,例如走入建制還是走出建制去改革社會……

幾年過去,我都給不到自己一個客觀答案。
但我自己主觀而言,就不喜歡難為自己,所以一定獨善其身,不太投身於任何組織之中。

談本土

「本土」,其實是很籠統的。
何謂「本」?何謂「土」?
其實「本」就是身份認同,「土」就是身份及利益分配。
不同人對這兩個問題有不同的解讀演繹,都可以Develop出一套自己的存在主義政治論述。

對我來說,「本土」之用,正在於其含糊﹑籠統。
含糊﹑籠統,另一角度看就是彈性。
善用之,則能把「本土」變成一套彈性的論述framework。(當寫code咁睇其實都ok)
不善用之,邪惡一點,則能濫用於manipulate群眾。
這是兩面刀,是善是惡,在於人在於心性不在於刀。

我是支持善用「本土」的。
原因在於我明白到,香港近年面對中共赤化的景況越來越壞。
和理非非成為絕對道德原則,是以往幾十年來香港人的習慣。
但隨景況越來越壞,過往的既成原則定得太死,則會成為將來抗爭上自打嘴巴的障礙。
例如:當日長毛反對參與小圈子選舉,但今屆他卻有意去出選,這正是原則太死造成他日抗爭欠缺彈性的問題。

所以我自己其實習慣不將把底線定得太死,需要留論述前路/後路。
論述應是dynamic而有規律的,是能預留buffer隨時代progressive interactive演化的。
而本土論述framework,能提供一定的論述彈性。

很多人執著「本土」牌頭,但我反其道而行,早一兩年已跟人說,放下牌頭吧。
對於「本土」,be water﹑shapeless﹑formless……
過幾年,就會有不一樣的人事﹑不一樣的論述。
那不一定是像當今的「本土」,牌頭可能會變;就像那些人說什麼「現在不講本土,講統獨」。
其實牌頭縱然不同,但背後的歷史演化是continuous與息息相關的。

作為「韜光養晦派」,我不太反感人們熱衷小圈子特首選舉

我對小圈子特首選舉,睇法都是咁,是蔑視的。
不過我其實不太反感很多人在其中熱衷奉曾俊華﹑胡國興﹑長毛,甚至葉劉等。(認不認同是另一回事)

我和很多人想法一樣,認為有志之士,或本土,當下該韜光養晦。
我認為熱衷小圈子特首選舉,長遠意義價值不大。

不過,都不可能所有人都去韜光養晦。
其實這段時候,有D人make some noise,對「韜光養晦派」甚至整個泛民主派來說不一定是壞事,也許比鴉雀無聲好。
沒有一點noise,只怕人們無法面對絕對與虛無,甚至信仰崩潰。

我其實都是站在自己立場——「韜光養晦派」——的角度說的。
我或其他人作為「韜光養晦派」,有人make some noise,其實都可以算係一種cover去掩護你去「韜光養晦」。

Lalaland

我自己是幾鍾意《Lalaland》的。
故事橋段其實幾簡單老調,都是果D故仔,但它成功塑造到男女主角的立體性格﹑心路歷程成長。
立體的人物描寫,讓觀眾投入。所以即使故事橋段老舊,也能帶動觀眾。戲中輕輕帶過的現實與夢想的掙扎﹑情愛的遺憾,都讓人看得很有現實的共嗚。

Nodejs v7.6.0 release would support async/await

Node.js v7.6.0 is just released

Node.js v7.6.0 release change log: node/CHANGELOG_V7.md at master · nodejs/node · GitHub

One of the shining change is that this release contains V8 engine 5.5.
V8 engine is the javascript engine which node.js is underlining using. With V8 engine 5.5, it would support async/await features. ( V8 JavaScript Engine: V8 Release 5.5 )

Async programming – Promise/async & await

In Javascript/node.js, there are multiple ways to dual with async programming.
With ES2016, people can use Promise syntax.
And with ES2017, people can use async/await syntax.

Promise style async programming:

Equivalent async/await style async programming:

Why async/await is better than Promise?

There are multiple advantages:

  • The async/awwait style is much cleaner with less coding block/scopes. Promise would wrap the codes in difference function scopes.
  • We can use try catch to catch errors for sync/async codes.
  • Less lines. The general coding style of most people usually need several lines to write a wrapping function.

 


 

Remarks:

Node.js actually support async/await since v7, but it is locked in harmony flag until v7.6.0.

ahp.js – nodejs module for Analytic Hierarchy Process (AHP)

AHP node.js module

Recently I wrote a node.js library for AHP.

If you do not know what is AHP, you may see a brief AHP intro post I wrote. Basically it is a methodology to help decision making scenario which we have to evaluate several choices against multiple criteria.

Example problem:

Github: https://github.com/airicyu/ahp
NPM: https://www.npmjs.com/package/ahp

Sample code:

 

Console output:

Interpretation:

The overall rank score(higher is better) of the choices are:
VendorA: 0.3652
VendorB: 0.2852
VendorC: 0.3495
Hence, “VendorA” is preferred in overall ranking.

Brief intro about Analytic Hierarchy Process(AHP)

Brief intro about Analytic Hierarchy Process(AHP)

Analytic Hierarchy Process(AHP) is a kind of methodology to help decision making. It is used for decision scenario which we have to evaluate several choices against multiple criteria.

Example problem:

(from https://en.wikipedia.org/wiki/Analytic_hierarchy_process)

For such problem, we may simply subjectively set a criteria weight, and for each criteria we give a score for all options, and finally calculate a final score for all options for evaluation.

What AHP can help on such problem

AHP can help to provide a more consistent method to evaluate the criteria weight, and we can validate the consistency. And for each criteria perspective choices ranking, AHP can provide a more consistent method to rank options. And again, the consistency can be validated.

More details about how AHP works can be found on Google/Wiki if you are interested. I also found a tutorial, https://mi.boku.ac.at/ahp/ahptutorial.pdf , which talking about AHP and I think it is quite well for understanding the idea.

 

Fortel v6.2.4 release notes

=== Fortel v6.2.4 release notes ===
Release date: 2017-02-10:

New feature:

  • 新增”分享到Whatsapp”功能。
    用家在使用mobile或ipad瀏覽時,命盤上方會出現”分享到Whatsapp”的按鍵,讓用家能把命盤分享到Whatsapp的對話中。

=========================

Fortel 紫微斗數排盤網網址: https://www.myfortel.com/
project homepage: http://blog.airic-yu.com/mycode/fortel

Hype Driven Development (一窩蜂驅動開發)

I want to share an article which has some reflective thoughts about technology culture in development teams.

Original post (In English): Hype Driven Development
Chinese translated vernio: 一窩蜂驅動開發

Short summary

It is common for many development teams which fall into:

  • Reddit/Stackoverflow Driven Development
  • Conference Driven Development
  • Loudest guy driven decisions
  • Gem/lib/plugin driven development

The problem is that sometimes the solution/technology people talk about in Reddit/Stackoverflow/Conference may be just specific solution/technology fit into their original problem and use cases. The solution/technology fit your development teams’s problem and use cases.

Another problem is that the technology people talk about may not be matured enough. Such immaturity may cause
serious potential problems.

The article also mentioned some solutions to these problems. The author suggest development teams to learn technology not just from blogs but also experience. It is better to make some quick prototype or POC experiments before making decisions to have better experience and understanding to the technologies.
On the other side, development teams should analyse and understand their own problems and use cases. Listing Pros & Cons and do comparison with different technology/solutions.

My personal thought

the real problem is never because of Reddit/Stackoverflow/Conference or whatever driven culture. The real problem is that we should have clear understanding and deep analysis about our problems and technologies.

5 ‘myths’ about microservices that people believe about but not always true

I want to share this article:
Microservices? Please, Don’t
Although the title of the article is “Don’t” but actually it is not dis-encourage you to not using microservice. It just talks about 5 ‘myths’ about microservices that people believe about but not always true.

Fallacy #1: Cleaner Code

“You don’t need to introduce a network boundary as an excuse to write better code.”

Fallacy #2: It’s Easier

“Distributed transactions are never easy.”

Fallacy #3: It’s Faster

“You could gain a lot of performance in a monolith by simply applying a little extra discipline.”

Fallacy #4: Simple for Engineers

“A bunch of engineers working in isolated codebases leads to ‘not my problem’ syndrome.”

Fallacy #5: Better for Scalability

“You can scale a microservice outward just as easily as you can scale a monolith.”