Distributed Node with Distributed Quota System (DNDQS)

最近因為某些原因而去研究一下如何在distributed的系統上做API quota機制。

首先是看了一篇研究論文 http://www.ssrc.ucsc.edu/Papers/pollack-msst07.pdf [Quota enforcement for high-performance distributed storage systems]
那篇論文裡所design的系統是用centralized quota server去做control發放voucher給nodes,nodes則能利用那些voucher去行使quota。
這倚賴了centralized quota server做sync quota的處理機制。
而其避免performance bottleneck的做法是一直用slide window protocol的方式預留了一些voucher在nodes那邊。

 

後來我自己也借鑒了其一部份想法design了另一個solution,我稱為Distributed Node with Distributed Quota System (DNDQS)。

Concept Powerpoint PDF:

Distributed Node with Distributed Quota System (PDF)

Introduction:

基本想法是把quota的概念由quota server centralized control的data變成node level distributed而流動的data。
然後透過consistent hashing把nodes固定生成一個virtual circular node chain。
然後每一個node都按需要而沿node chain向下一個node發送request,請求下一個node把它的quota填補自身node的quota。
每一個node都會進行以上logic,所以unbalanced distributed quota會drive quota propagation從而逐漸balance。

Characteristic:

  • Distributed quota on nodes.
  • Make use of consistent hashing to form an ordered circular chain of nodes.
  • Balance node quota by mono-directional flow of quota through the node chain.

Benefits:

  • No need to sync quota to Quota Server.
  • Distributed Quota would eventually be balanced.

這個solution的design只是一個初步想法,我未有實際POC過,實際應用可行性及數據有待考證。
但有一個很大的潛在問題,就是當要support到有大量user各自的quota的時候,distributed quota data就會變得很擁腫,overhead會很大。

Developer日誌:frontend framework初感

最近因為想執下自己d 野d code,所以睇/玩過下三隻frontend framework:angular.js, mithril.js, react.js。

用落angular冇耐就發覺奶晒野,好多野都要用“the-angular-way“去做。
learning curve痛苦固然係好大問題。而另一個大問題係用“the-angular-way“去做,將來點做refactor?同埋the-angular-way既knowledge我自己覺得其實唔係好reusable。
公事上要adapt angular.js,但自己野我就自由意志喇。

mithril.js初頭試ok,但有d位卡住google左陣發覺唔識攪,佢community又唔太大,難d google野。

react.js係相對易上手,lightweight,冇咁多coupling(relative to angular.js),可以同其他野夾得好d易d。
所以暫時試完三隻野都係決定用react.js去執frontend。

btw有個framework見到有d潛力想掂下但未試,Aurelia.js,留名待J。
我睇好原因係因為相對the-angular-way自創directives, Aurelia.js係比較close to用ECMAScript6/html5去做野,比較近web standard同埋d knowledge將來比較能reuse。

同一個我?不同的一個我?

哲學問題,programer解決。

在不同的時候,做不同的事時,有著不同的「我」,對同一件事的看法也有差別。
那麼究竟是同一個「我」,還是不同的一個「我」?

一個program,在不同state,對同樣的input也可能有不同的處理。
那是「同一個」,還是「不同一個」?
我想,是「同」,也是「不同」。
「同」者,是指同樣是那一段code,同樣是那個program。
「不同」者,是指program的dynamic特性。

靜態的code寫出動態的program。
program雖會變,其核心法則規律不變。
宇宙萬物雖然變幻無常,卻依然有其生命周期變化法則規律。
人觀察宇宙萬物變化,這行為背後本質,和programmer睇code﹑debug﹑troubleshooting﹑reverse engineering﹑睇design pattern無異。

我喜歡觀察及歸納model﹑pattern﹑流程。
所以我喜歡programming,以及對世界﹑宇宙﹑宗教﹑哲學﹑神秘,有著好奇心。

programming,是一種哲學。
而programmer,是現代的哲學家。

Java農曆公曆轉換

早前需要在Java上用到農曆公曆互相轉換,但在網上找了好些別人寫的library,要不就是只能做到公曆轉農曆,要不就是會計錯了農曆閏月部份。
最後在 中国阴历与阳历的转换实现【java实现】 這一個網頁上找到了一個能計算農曆閏月部份並互相轉換的source code。
但我在使用時測試過,以香港天文台的 公曆與農曆日期對照表對照 後發覺有些日子會轉換錯誤,e.g: 1990-06-23 <-> 閏五月初一。
所以我把那網頁的source code修改了一下修正了問題。
後來亦參考了 1900年至2100年公历、农历互转Js代码 而加入了一些年份數據,令它支援到1900至2099年之間的計算。

註:這程式只能支援換算以下日期:

 

  • 農曆轉公曆: 農曆一九零零(庚子)年一月初一農曆二零九九(己未)年十二月三十日之間。
  • 公曆轉農曆: 公曆1900年1月31日公曆2099年12月31日之間。

 

Code repository:

https://bitbucket.org/Airic/lunarutil

 

更新日誌:

  • 2017-10-13-v1.3.1:
    • 修正2017年農曆閏六月三十日無法轉成公曆8月21日的bug。
  • 2016-04-21-v1.3:
    • Format code,加入Unit test。
  • 2016-02-05-v1.2:
    • 修正2033置閏問題。
    • 加入2050-2099的年份資料以支援該年份計算。
  • 2014-12-29 – v1.1:
    • 用上了 Joda-Time 去修正了一些因為timezone而出現的bug。
    • 加入了兩個新method:
      • Lunar getPrevLunar(int year, int month, int day, boolean isLeap)
        輸入農曆日期,輸出前一天的農曆日期
      • Lunar getNextLunar(int year, int month, int day, boolean isLeap)
        輸入農曆日期,輸出後一天的農曆日期
  • 2014-12-27 – v1.0: 最初版本

(最後更新日期:2017-10-13)

如找到有bug,請email到 airic.yu@gmail.com 告訴我。

the beginning of a programmer: {

回想小時候,在親戚家玩電腦玩到《三國志英傑傳》﹑《大富翁2&3》(阿土仔做主角果隻),就覺得電腦遊戲很好玩。
家母家教甚嚴,我家沒有電腦,她也不買遊戲機給我們。
但我真的很嚮往那些遊戲,所以我就在家中拿來一張大畫紙,在上面畫著類似《大富翁》的棋盤,和表弟一起玩。
那時候,我大約小學五年班,不知道什麼是電腦程式,不會想到日後。
一切都很沒有意識﹑很自然,我就是喜歡那份「建立」的感覺。

寫program,對普通人來說是什麼?我想大概是「懂得整router﹑砌機﹑整電腦﹑解決電腦問題」……並不是這樣的。
對有IT知識的人來說,那就是寫電腦上運行的指令,指示電腦去做些事。
對我來說,小時候,在一張畫紙上畫著那《大富翁》的棋盤,那已經是「寫program」了。
我想,我是一個比較喜歡抽象的人。
對我來說,program不在於code,而在於「建立」。

在所謂末日前,讓我寫下programmer對世界的看法吧

有時我覺得這個世界可能只是一個程式
所謂神,可能只是一個programmer,但神還是會講粗口的,神也是有boss有客有requirement的,也許神也看電視的師奶劇,也許神會偷偷的在世間留下看不見的comment
神不是全能的,它不能製造自己也舉不起的石頭同時又全能
它還是要跟著program language的制限﹑跟著這世界運行時的rules限制,在限制裡擁有強大創造力去創造萬物

三位一體並不難明白(學高皓正條友話齋),因為這program可能是三個programmer為一team去maintain
又或者神是一日有3個man day去寫code,所以是三位一體的吧
(呢兩個講法係講笑姐~haha)

又或者如果神只是一個object,它implement了3個interface,分別是聖父,聖子,聖靈,object是同一個,但cast做不同interface又可以有不同的behavour,這個model也可以接受
(認真,其實呢個講法我覺得真係可以解釋到基督教果個三位一體)

人可能只是一個object
鬼可能只是memory leakage,又或者是一個object pool,某些bug存在令某些人不小心access到那些memory
超能力,可能是feature,又或者也可以說是bug

次元空間,可能只是multi dimensional的array吧(其實數學上來說也應該只是multi dimensional的vectors吧)

利申,以上我只是隨口說說

------------------------------

世人總認為神蹟是神蹟
這是人的一般理解
但他們從沒想過
神蹟可能只係一個19大意既programmer留下既bug
又可能,神蹟只係神o係度做緊demo炸!
佢做demo,所以派他的獨生子jsp,爆error3秒後復活,又教他夾硬fix,將水變成酒去砌岩o的parameter

神總係寫rules,叫人去跟佢logic做野,而人本身正常係不了解programmer的世界
神,對人來說,只是一個滿足他們calling的interface,compile到就很夠了吧

Android App : Battery Notice

之前寫了一個很簡單的android app放了上google play
是關於顯示電池用量於上方的notification bar的

Battery Notice (google play上的連結)

我寫這個app的原因是因為我之前電話顯示電量的app是用widget去顯示,必須要解鎖後才看到,我覺得很不方便
所以我想到如果顯示到notification bar應該會方便得多
這種app其實坊間亦不是沒有,不過我選擇自己寫一個,因為我本身想學習寫android app;而寫一個app去解決一些實際問題,會比寫一個純粹hello world開心吧!

Android學習日誌

而家寫左個簡單既電池用量app

其實呢o的app出面都有,不過自己寫黎係for learning purpose
學完大概學識基本activity﹑intent filter﹑notification﹑service﹑broadcast receiver﹑share preference

遲下如果有心力(D3就出冇乜餘力)會寫個shortcut打電話既app
都係果句,其實出面都有,for自己learning purpose架姐