Hangouts Clock!

今天寫了一個可以在 Google Hangouts 的影片加上時間註記的 extention. 視訊時開啟就會在影片下面即時顯示當地時間。
很多社群朋友或是最近太陽花社會運動運用 Google Hangout 進行現場轉播,日後再回顧這些影片的時候,常會覺得缺了時間的訊息,影片整理起來比較不方便。有了 Hangouts Clock! 影片內直接嵌入時間註記,整理起來方便的多。

這會是個 Open Source Project,歡迎大家一起參與給意見或者送 Pull Request。也許可以等黑客松的時候再跟大家一起加新功能。

P.S.目前預計要增加的一項新功能是文字註記,讓使用者直接寫上影片事件的標題。

Facebook g0v.tw 後勤中心 - Hangouts Clock

今天聊到 Quality Without A Name 的概念。這個是2月參加C.C. Agile Sprint18 - 那一夜我們說Pattern: Design Patterns 20周年紀念,講者 Teddy 在介紹Design Pattern 20年歷史所提到的。這個概念是由Christopher Alexander在 The Timeless Way of Building 書中提出的,意思是好品質是沒有辦法用言語完整形容的,但品質存在人們的心中。

一開始聽這段話也覺得滿玄的,仔細再聽 Teddy 講下去才覺得這確實很有道理。Quality是我們要追求的目標,而為了達到這個目標,於是我們設定了一些評價方式來衡量它,但並不是達成了我們的評價方式就叫做好。

以 Design Pattern 來說,在 GOF 書裡就列出了二十多項Pattern。但是一個軟體系統並不是套用了Pattern就叫做好,而是要看這個系統哪個地方發生了應力(Bad Smell 等等),而讓我們需要去對這個應力去採取一些方式化解。

換句話說,一項系統不是因為它被套用了這個 Name (Pattern)而有了品質,而是高品質系統展現出給人的感覺,我們給他一個統稱。

Quality Without A Name,一種精確但卻無法被命名的特質。雖然無法被命名,只要用心觀察體會,當這種特質出現的時候,你就可以感受到。當它不存在的時候,你也可以感受到。

要追求的是系統展現出來的特質,而不是追求系統有沒有套用了什麼。其實這就有點像是,要感受團隊是否真正溝通了什麼,而不是看大家是否開了會,是一樣的道理。

「老師忘掉他是老師,學生忘掉他是學生」- 感動!
我是屬於提出疑問進而找尋解答而成長的人。 葉丙成教授這篇文章讓我意識到我在追尋的是什麼。其實就是一個能夠透過論辯而成長的環境。我想我是屬於在這種環境中會表現的比較好的。就像以前在研究所也經常跟教授論辯很久,當下很辛苦,但也有很好的結果。

翟本喬 - 你做的是一份工作,還是事業上的一步? 翟本喬說的這一句精準的點出我很認同的想法。未來要好好為自己的前途計劃、努力改進。

最近注意到台北市圖書館是每月第一個星期四為清館日不開放,而新北市圖書館是最後一個星期四為清館日不開放。這樣恰好錯開了不開放的時間。
進一步想到如果其它縣市像是桃園縣、基隆市等等也希望跟相鄰的縣市錯開清館日的時間,而且都要安排在周四。考慮到一個月通常有4個星期四,這樣就變成是四色定理的問題了..

第一次新聞看到 deadlock 這個詞 Kerry Blames Syrian Government for Deadlocked Talks

查了一下發現其實在歐美新聞中,這個詞不算少用。像是:Government Shutdown Begins as Deadlocked Congress FlailsCompromise breaks deadlock at UN climate talks

Understanding delete 這篇文章討論 Javascript 的 delete 行為,並且釐清一些常見的誤解。全文很長,最後總結是精華,我把它整理翻譯後分享出來如下。

  • 變數跟函式宣告都是屬性。他們會是Activation Object(啟動物件)的屬性。或是Global Object(全域物件)的屬性。
  • 屬性具有 attributes (像是 ReadOnly, DontEnum, DontDelete and Internal,可視為一種旗標)。其中 DontDelete 是負責表示這項屬性可否被刪除的 attribute
  • 不管在全域或是函式作用域中,變數與函式宣告總是具有 DontDelete
  • 函式參數是 Activation Object 的屬性,具有 DontDelete
  • Eval code 裡的變數、函式宣告不具有 DontDelete
  • 由配值(assignment)產出的屬性一定沒有任何 attributes ,也就不會有 DontDelete
  • host 物件對 delete 的反應是無法預料的,他們想回應 true 或 false 都行

如果想更進一步了解,可以查閱 ECMA-262 3rd edition specification.

其它相關Reference Link: stackoverflow - How to unset a Javascript variable?

10項系統監控
2014-02-12

10 Things We Forgot to Monitor 在做系統監控時,我們常想到Disk Usage, Memory Usage, CPU Load, Ping latency。bitly的工程師 Jehiah 分享10項有用但平常少提及的系統監控項目,有些項目甚至附上了 script 供 Devops 參考。

  1. Fork Rate
    • 異常的 Fork Rate 可能表示系統設置有問題。作者舉了一個例子,某次系統設置錯誤, curl 不斷觸發 modprobe
  2. flow control packets
    • 確定網路流量管控機制的設定不會使得系統在某一時刻停止接受封包
  3. Swap in/out rate
    • 藉由記錄 vmstat 的數據, 推算 swap in/out rate,確定系統流暢
  4. Server Boot Notification
    • 系統重開機時,寄email給管理員
  5. NTP Clock Offset
    • 確定 ntpd 在背景執行,並且記錄機器時鐘誤差,以及機房時間伺服器與外部的時鐘誤差
  6. DNS Resolutions
    • 監控內部 DNS Resolutions 狀態,也監控外部 nameserver 的穩定性
  7. SSL Expiration
    • 在 SSL 快過期前發出通知
  8. DELL OpenManage Server Administrator (OMSA)
    • 購買硬體伺服器所需做的監控
  9. Connection Limits
    • 了解系統並確定限制連線設定符合需求,作者這邊給的限制是 65536
  10. Load Balancer Status.
    • Load Balancer health check

附註:看到 Hacker News 推文中有人另外列出一個也滿值得監控的數值: file descriptors 的最大數量

Mutex VS Spinlock
2014-02-07

這篇發問的最佳回答 When should one use a spinlock instead of mutex? 說明了 mutex 與 spinlock 的不同。 mutex 的機制是當 process 無法鎖定 mutex 時,process 會進入 sleep,中間會需要付出 context switch 的代價。spinlock 的機制是採用 busy-waiting,直到鎖定 spinlock 為止。 依據兩者的特性,一般來說,在單核心的系統中,會採用 mutex。而多核心,且 critical section 只耗用一小段時間的狀況下,適合使用 spinlock。
解答者 Mecki 還補充了實務上的狀況。由於要預期應用情境下的 lock 狀況相當困難,現代的作業系統中也加入一些機制增加彈性,發展出了 hybrid mutex, hybrid spinlock。當 process 無法鎖住 hybrid mutex 時,作業系統不會馬上讓 process 進入睡眠,而是以類似 spinlock 的方式 busy-waiting 一小段時間,確定真的無法鎖住 hybrid mutex,才讓 process 進入睡眠。而當 process 無法鎖住 hybrid spinlock 時,作業系統會允許 process 進行 busy-waiting。但超過某個時間限制,則會讓 process 進入睡眠,讓其它 thread 運作。

pthread mutex vs pthread spinlock 這篇文章則是給出實作,實際表現出在多核環境,且critical section佔用極小時間的情況下,pthread spinlock 的表現優於 pthread mutex

More Link: Jserv - Mutex與火車排班

The Magic of Strace
2014-02-04

過年讀了這篇 The Magic of Strace ,裡面介紹了使用 strace 來追蹤 unix 下的程序使用 system call 的運作情況。觀察 process 對 system call 的呼叫,包括 file read/write, database read/write, Inter-process communication,可以找出其中出現的 bug, error 。對於某些很難重現的錯誤,可以藉由 strace 進行 log 。下次在 unix 上多個工具可以試試了。

updata: Understanding how killall works using strace 這篇文章也很有意思,利用 strace 去追蹤 killall 的流程。
首先 killall 爬過所有 process 的 stat (/proc/$PID/stat),找到相同的 process name 就把 PID 送進 kill system call。
最後底下推文回應還提到了 ltrace,可用來追蹤 library call,以及一份關於 /proc 的文件 THE /proc FILESYSTEM