論賭博遊戲

賭博遊戲我大致會分兩種,第一種是「同莊對賭」,第二種是「不是同莊對賭」。

「同莊對賭」的遊戲往往是「局」,長賭必輸,若目的是求財的話則不理性。
「不是同莊對賭」的遊戲的例子是,與其他參與者們之間的零和遊戲。這類遊戲有機會是理性可取的遊戲。

而在「不是同莊對賭」的遊戲中,越多人參與遊戲,則對玩家越為有利。(獨立以此性質判斷,排除其他因素)

只有少數人參與的遊戲,會有機會玩家面對的是少數的精英,所以有機會令輸的機會變大。
多人參與的遊戲,玩家有機會從一般劣勢玩家中得益。
當然,玩家在此同時也有機會輸給精英玩家。
所以關鍵就在於,遊戲是否有給玩家選擇「場地」的空間。
盡量避開「莊」﹑「精英」,而選擇合適的場地,與一般/劣勢玩家玩,就較易得益。

當然,如果我說的只是「遊戲性質令遊戲對玩家存有優勢」,那麼豈不是對所有玩家都存有優勢?那豈不是廢話?
關鍵在於….現實世界中,往往恆常存在一班非理性賭徒,是沒有盡用遊戲衍生的策略優勢。
越是多人能參與﹑門檻越低的遊戲,非理性賭徒的比重越多。
若能選擇「場地」,面對非理性賭徒,就能較有優勢。

所以「遊戲性質令遊戲對玩家存有優勢」,前提是當事人是理性的玩家。
玩家並不一定需要是最top的那堆玩家。
反之,let’s say可能玩家的策略只需是最top的幾十%甚至是50%,然後與最劣勢的一群玩家對賭,就能得益。
(off topic, 這衍生出的一個道理就是,知道自己的定位﹑決定適合自己的「戰場」,比起自身的絕對實力,更為重要)

—————————————————————————

以上是純粹的理性分析。
所謂「賭博遊戲」,我不是只是指最狹義的那種賭博遊戲。
Generally,也是applied to 打機的遊戲,甚至是股票/投資衍生工具,甚至是社會上資源分配。

就拿社會上資源分配問題來說一些例子,
部份中產是利用相對優勢與基層博奕(or壓榨)中得到得益。
又或是,在沒有人能做大個餅的當下香港,有能力的人們(例如已上岸人士),利有僅餘的既有優勢,從劣勢玩家中壓榨利益。

—————————————————————————

生財/遊戲,我認為該是取之有道。
若是在比較公平的環境下明買明賣,我覺得尚可取。
但若是巧取豪奪,我就覺得是不義之財,不應為了利益而埋沒良心。

fortel-solar-term.js – 24節氣時間換算

依排抽返少少時間攪風水命理野,寫下code。

https://github.com/airicyu/fortel-solar-term

依個nodejs library其實只係做緊d好簡單既時間換算:
1) 由某個時間計返係邊年既邊個節氣月份
2) 估算某年既節氣月份既時間range

由於係純粹用Formula計,所以同現實測量既時間係會有所出入(around 5 min誤差)。

我寫依個library既原因,係因為我學八字想寫program/library去計。而八字係需要用節氣去定月份。

dev roadmap:
1) 寫個八字library (純粹起盤,不含analysis/interpretation)
2) 寫個擇吉日(結婚)library,擺上網free俾人用
3) 八字加少少analysis/interpretation,擺上網,類似我個fortel紫微斗數網咁樣。
4) 依排學緊奇門遁甲,又寫下d起盤library,加少少analysis/interpretation,擺上網….etc

遊戲的可持續發展

我個人並不反對d遊戲用expansion﹑DLC形式去營運。

雖然我個人身份係打機既玩家,但我覺得最大既win win solution係一種可持續模式。
一隻遊戲,玩家有方法feed到遊戲開發者,而遊戲開發者亦可以keep住update game content去令玩家打得開心。
而expansion/DLC形式,可以係一種可持續既營運方式。

其實又要拎warframe做例子,隻game出左好耐,佢定期出下戰甲/武器,d玩家就課金買下d戰甲/武器黎玩。佢地亦會keep住update隻game令到隻game有更多野玩。
其實隻game係可持續發展得幾好。

佢地有個平衡位做得好好既係,就算你係唔課/輕課玩家,其實你都一樣係玩到隻game完全冇問題。
一開始excalibar都係唔差,一開始果d槍你打mod升勁佢一樣係有得打。隻game主打PVE,亦不見得pay to win。

只不過,你課左,有得即時買D戰甲/武器黎玩(唔駛農材料),咪玩下新玩具囉。唔同槍唔同手感唔同樂趣,課金唔係屈機,而係課金係買新玩具玩既樂趣。

講返主題。
我自己真心係希望d開發者可以用心做到好遊戲。有好遊戲,我唔介意課金。
甚至調轉,我成日擔心d開發者用心做遊戲,但做不好$ feed back loop,最後很多很有potential的遊戲,最後都因為冇$而無以為繼開發下去。

現實是,正正是因為很難做到可持續健康發展(有幾多隻warframe?),很多遊戲開發最後都走上速食罐頭cap水之路。
玩家與開發商,其實從來都是互動生態關係。所以對這問題,我作為玩家亦覺得不能單單怪責遊戲開發商。

AI後社會

李開復去TED講AI後社會。除了慣常的routine<->creative既axis去分析社會既工作,佢用多左條compassion axis去睇人同AI合作既工作。

 

 


 

個人感想:

o係未來可能講緊幾十年時間,AI技術都仲係未「底特律變人」到,咁都應該仲可以講下人同AI既合作關係既。

不過雖然AI係令人類方便左而且多左時間,可以更注重生活﹑倫常﹑love。
但可能少數比較high end人口先可以enjoy到得益。
隨住未來一波又一波智能工業革命,首當其衝的是失業問題。
社會會越黎越多閒置勞動力,而失去工作後佢地冇錢亦冇生活,low end no job no $ no life。

科技free左d man power,而man power背後既價值(人工)係唔會交返去工作既人身上,而只會是根據supply demand重新分配。
當中利益我相信大部份會係由”employer/公司/財團”與”科技資產掌控者”(e.g: amazon, alibaba)瓜分。

AI革命係咪能為人類帶來新生活?
是的,但可能係部份人生活得更易,而部份人生活得更艱難;
以及部份生活的基本元素更方便,而部份生活的重要元素卻更難以追求。

Java紫微斗數排盤open source library

其實我一早就想把Fortel的core部份open source的了,不過現在才比較有空整理一下project,寫一點test case及doc。

Github: https://github.com/airicyu/Fortel

 

Fortel

Java紫微斗數排盤Library

Author: Eric Yu


Samples

排盤

排盤:一九五二年十二月十五日早子時天盤,男性

JSON Output(Formatted):


檢查宮垣

排盤:一九九零年三月十一日午時地盤,男性

檢查命盤命宮是否: 會見廉貞, 並且同時”天魁或天鉞同宮”或”不見化忌”

Output:


檢查命盤命宮是否: 會見廉貞, 並且同時”天魁或天鉞同宮”或”不見化忌”

Output:


JavaDoc:

You can view the Javadoc page at “\fortelcore\javadoc\index.html”

[Nodejs] FB Page post comment/reply event engine

岩岩寫左隻FB Page post comment/reply event engine既Nodejs module。

個module目的係幫FB page owner去mon住個FB page係咪有新comment,然後generate event & 俾個位d人自己去寫callback logic。

實際做法就係佢背底會行個schedule job去call FB graph API黎check post既new comments。

NodeJS module for keep track Facebook Page Posts New Comments

NodeJS module “fb-page-comment-event”

This module can keep track your Facebook page posts’ first level comment events. Hence, if someone commented on your post, you will be notified by an event.

This module support running an event-engine which would manage a background schedule job to check new comment and generating events. This module also support raw APIs which you can check new comments and digest as events by yourself via APIs.

 

Related Pages

Github page: https://github.com/airicyu/fb-page-comment-event
NPM: https://www.npmjs.com/package/fb-page-comment-event

 

Description

This module can keep track your Facebook page posts’ first level comment events. Hence, if someone commented on your post, you will be notified by an event.

This module support running an event-engine which would manage a background schedule job to check new comment and generating events. This module also support raw APIs which you can check new comments and digest as events by yourself via APIs.


Running the event engine

You may use the lib.pageCommentEventApp(options) API to get a event engine app and then start it with run function. This event engine app would manage a schedule job to auto pull data.

Sample:

  • Remarks: pageId is the facebook page ID. postId is the facebook page post ID of post which you want to monitor its comment. accessToken is the Facebook page access token(remember to use the long live token) which Facebook page owner can generate in developer dashboard.

Sample console log output:


(DIY) Use the APIs to check new comments and generating events

Sample:


event engine APIs

let app = lib.pageCommentEventApp({accessToken, pullInterval})

Description:

Initializing the event engine app.

parameters:

  • accessToken: The required accessToken(need permission manage_pages) for the API calls.
  • pullInterval: The sleep time(ms) interval between each scheduled page post new comment checking.

return:

The event engine app.

app.registerMonitorPost({pageId, postId})

Description:

Registering a page post which the event engine would tracking for new comments

parameters:

  • pageId: The page ID.
  • postId: The post ID.

app.run(eventsCallback)

Description:

Start running the event engine and register the new-comment-events callback. Once users write new comments, new-comment-events would be fired and handled by the callback.

parameters:

  • eventsCallback: The batch new-comment-events handling function.

app.stop()

Description:

Stop the event engine


DIY APIs

let queryPostCommentAgent = lib.api.getQueryPostCommentAgent(options)

Description:

Initialize a agent for query post comments.

parameters:

  • options: object with attribute accessToken which holding the required accessToken(need permission manage_pages) for the API calls.

return:

The agent object.

let postCommentFetcher = lib.api.getPostCommentFetcher(queryPostCommentAgent)

Description:

Initialize a fetcher for fetching new post comment.

parameters:

  • queryPostCommentAgent: The agent object which come from lib.api.getQueryPostCommentAgent(options)

return:

The fetcher object.

let postCommentObj = await postCommentFetcher.fetch(postObjId, since)

Description:

Use the fetcher object to fetch post object with comments. We can use this API to get all new comments under the target post which those comments are created since the since time.

parameters:

  • postObjId: The post object ID which is in format of ${pageId}_${postId} in Facebook Graph API.
  • since: The timestamp in second

return:

The post object with comments (All comments child objects are new comments).

let postDigestor = lib.api.getPostDigestor();

Description:

Getting a digestor object which can turn the post-comment object from postCommentFetcher.fetch() result into new-comment-events.

return:

The digestor object.

let newCommentEvents = await postDigestor.digest(postWithNewComments)

Description:

Use the digestor object to digest post-comment object into new-comment-events

parameters:

  • postWithNewComments: The post object with attaching new comments.

return:

New comment event objects

關於呂麗瑤事件的評論

關於呂麗瑤事件,
我認為,對(疑似)受害者最大的支持,不是訴諸同情地輕信,而是求法制上﹑社會上的公平對待﹑保護。

法制那些我不熟悉就且不多說。
就「社會上的公平對待」而言,我認為社會是該用正面肯定的角度去對待受害者肯站出來面對的這件事。
但肯定受害者站出來面對,這件事從來不應簡單地等同於輕信單方面片面之詞,這是完完全全的兩件事。

好些人可能會說,大眾若持有這種理性批評,不輕信受害人,這對疑似受害人構成壓力,是一般被非禮/強姦者不願站出來的原因。
我get到的言下之意(如果冇get錯)好像就是說,你若不信疑似受害人所說的內容,就是在壓迫疑似受害人。
姑勿論是真非禮還是老作,女方較易受同情及信任,這是社會客觀現實。
但觀感上的同情情緒並不等於真相。
呂麗瑤選擇公開處理這件事,雖然沒有點名那名教練,但已令對方被辭退。(好似係)
若事件不明不白只是半透明地處理,其實大眾只是被借助社會壓力向校方施壓。
借助大眾的社會壓力本身無可厚非,但若件事不明不白地就發生,則這種訴諸同情而非真相的culture/做法對社會長遠有害無益。

很多人看待件事,可能是很簡化地either選擇了男方或女方立場。
件事內情其實至今仍然是外人大眾不大清楚,所以只能用推測角度去看,難以下定論,不用跟車太貼。
觀乎一般大眾那種「歸邊」,以及把「支持受害者站出來」以及「確信其所指內容」兩者的綑綁,在一片爭議之中對疑似非禮/被非禮方都是不公平的。

在這種處理不當﹑對雙方也有欠公允的情況下,我覺得社會大眾是應該再反省一下hashtag “metoo”的意義及社會大眾對待這些事的態度。
單單是一個hashtag “metoo”,加上一個人的片面之詞,是否就代表著真相與充分的證據??我看法是有點保留的。
陶傑那篇文,是有點抽水諷刺意味,寫出來引起嘩然。但他就社會輕信處理metoo hashtag的這個point而言,是有一定道理的。

關於blockchain的少少個人理解與想法

講少少個人理解,blockchain大概是一種在處理asset擁有及轉移的應用技術。
對於這種應用,傳統社會的做法牽涉大量trust與資訊交換機制與成本。而因為trust issue, 所以形態上是很多parties各自的centralized trust機制,所以加大了交易成本。

blockchain的做法,是去中心化的trust(rathet than only data storage層面)機制。
藉着公有公開驗證的做法,所有資產轉移都是自帶驗證。
所以大大解決了trust與驗證的成本。(這是blockchain的最大價值)

但當然,技術還技術上的價值,應用上仍然可以是空殼廢紙,所以把資產本質由實體($)轉為虛擬貨幣的應用,用家進入市場有很大風險。

另外,在應用層面,blockchain一定是資產轉移流水帳的use case。若否,則blockchain技術不會帶來太大價值。

另外,blockchain需要公開帳目,我沒仔細研究過,但我懷疑仍有可能由transaction之間去trace back到account持有者身份。
例如,我是e store, 我賣了一件貨給某人,進行了某bitcoin交易,那應該有一條transaction是若干bit coin由某人銀包轉移到我銀包。那我是否能由“某人銀包”去識別出其他關於某人的bitcoin交易?若我掌握大量銀包識別資訊,那會否讓我能知道大眾的帳目資訊?
(我不熟這範疇,純粹ff 想想而已)

Airic API Gateway

Just for fun.
最近斷斷續續前後用左幾個星期左右,自己用NodeJS寫左個REST API Gateway。
 
簡單講隻REST API Gateway做d乜就是:
有個API config server,可以o係上面register隻app+import個swagger,
之後就可以create client同reg API key,
之後就可以用d API key經gateway去call果d REST API。
 
隻Gateway帶黎既benefits係:
– 隔左一層as protection layer,
– 有得落Quota rule去set quota (quota rule =/= spikearrest),
– 會收集到usage stat (1minute bucket),事後可以睇得到某時間內咩人call過邊個app邊個rest operation幾多次。
 
 

Project code name:

Airic API Gateway
 
 
 

基本Features:

 
– 冇UI…(其實依個唔係feature…)
因為我好怕攪frontend野太煩sosad, 所以直頭完全冇攪UI。
CRUD app API﹑CRUD client﹑register API key全部management operation靠REST API去做。
 
– app API definition係食swagger。
 
– support quota rule (1m, 5m, 1h, 1d, 1week, 1Month)。
quota rule可以apply落app level, operation tag level, 或者operation level。(app/tag/operation係跟據swagger spec而判斷)
 
– support對應同一app之下,唔同client分別用唔同quota plan (可以同時apply多個quota plan)
 
– 會log低API usage statistic & 可以用REST API query返出黎,睇到每隻app/operation/client o係某段時間內call左幾多次之類。
 
 

Performance

 
load test今日有試過下。
local PC用jmeter做load test (200 Testing thread), nodejs cluster x 4, 有enable 3條quota rule。
 
throughput都做到~2800 req/s。
random take sample既純粹入gateway processing直至response完成時間(而唔計proxy call背後API既時間)大約係0.x ms至10ms之間。
 
之後我再試多次,code果度直頭完全唔proxy call後面API,直接response返去,咁就真係可以計到純粹gateway processing直至response既時間& throughput。
咁樣load test係可以去到~5200 res/s。
random sample 入gateway到response時間都大約係0.x至10ms之間。
 

project status:

 
算係做左prototype,functionally基本叫做workable…
不過test我都只係人手test冇mocha unit test, 亦都冇寫doc。
(遲D執返好晒D野少少, 得閒先放上github吧~XD)
 
 

Component有邊幾樣野?

1) API config server – 儲住App﹑API config definition既核心。
2) API gateway – 就係隻gateway
3) API stat server – 儲住usage stat
(原本諗住寫多隻key server由config server拆出黎, 但我發覺key同config好難拆得開,我懶+怕煩就冇攪喇)
 
 
 

Database用左乜

1) App Config可以用MySQL或者Mongo或者Memory (好似Mongo方便dd, 不過我MySQL都係用json type儲, 所以差唔多)
 
2) API key可以用MySQL或者Mongo或者Memory (MySQL或者Mongo都冇所謂)
 
3) API call quota可以用Redis或者Mongo或者Memory (Prefer Redis, 好似快好多咁, 依part是用key-value lookup的)
 
4) API usage stat可以用MySQL或者Memory (Prefer MySQL, 只用來事後Aggregate, 其實用Mongo做都ok不過我冇整到)