Yoshi's Blog

我一直覺得 Chris Paul (CP3) 是一個天才, 他還早在黃蜂時看他打球就知道, 有一些進攻與傳球絕對不是苦練能得來的, 這種天份就是超越一般人的天才. 可是那麼多年下來, 他有的時候還是會失常, 像前二天和馬刺的比賽, 他只得了 7 分 6 失誤, 全隊以 73:100 大敗給馬刺, 前幾天我聽轉播, 主播一直強調他失去了專注力. 在今天 Game 4 CP3 回神了, 得了 34 分, 命中率 11-19, 在他能維持專注力的場次越多, 他就將會從 all-star 提升到 superstar. 如果他能夠更上一層樓, 進一步得到總冠軍, 他則有可能再把自己提升到名人堂 (Hall of fame) 的層次, 可是這已經超越了天份的問題, 有沒有遇到好的團隊 (隊友/教練/管理層) 也佔了很大的成份. 不知道怎麼超展開的, 我突然想到自己, 還有身邊的許多同事, 其實我們都是 all-star, 我們有的時候會突然曇花一現的展現出超人的一面, 我的同事們都沒有弱者 (人格和道德又是另一回事), 只不過能維持的時間往往不夠長, vision 也常常不夠大, 所以永遠也就只能停留在 all-star 的層次. 小的時候爸媽總會和自己說:"你很聰明, 只是不用功", 現在在職場也是一樣: "你很有潛力, 只是沒有被好好訓練, 沒有遇到適合帶你的人", 做為這個領域的 all-star, 怎麼讓自己再提升到更高的層次, 怎麼去尋找能夠將自己從 all-star --> superstar --> hall of fame 的土壤, 我還在思考這個問題的答案. 加油吧!!! 各位還在職場水深火熱的同事們...

他媽的, 我以為在馬路上只要小心三寶飯就好了, 結果剛剛在網狀黃線區等左轉 (雙線道), 我都等到對向車道紅燈, 車子也慢慢切過去一個車道了, 結果一個騎機車的白人, 後面還載一個女的, 硬是要不減速衝過去, 結果衝不過去就急煞, 停在我前面瞪我. 幹你媽的不要以為你在人類的金字塔頂端我不就敢對你怎樣, 我馬上把窗戶打開伸中指出去, 要下來打架我就讓你看看 Chinese KungFu 啊, 結果還不是立馬加速走了, 我還怕他沒看到, 中指隨著他的機車 object tracking, 騎到哪比到哪啦, 操, 我有行車紀錄器啦, 看你的戰鬥力頂多也就八千, 到台灣玩不到台北夜店玩到新竹這種鬼地方, 幹你媽竹科宅男沒在怕你的啦

最近花了幾天研究 amazon cloud service (工作需求), 也動手申請了帳號玩玩看, 這東西應該也出來個五年有了, 說起來我在這方面是個完全的科技落後者. 有一些老人的感觸, 我是在國二時上傳第一個自己寫的 html 到一個叫 geocities 的網站, 算一算是 19 年前的事了 (1996 年), 我還記得我的 html 是用記事本刻的, " ... "...(想不到 19 年後還是一樣在用這語法啊!!), 不過現在已經找不到我當年做的網站了, 因為 geocities 在被 Yahoo! 收購後, 已經在 2009 年 shutdown 了. 約在 1998 年, 許多網站開放使用者上傳 CGI 服務, 我也忘記 php 是不是在那個時候盛行的, 但是大多這樣的網站都沒什麼賺頭, 到二千年初, 也有一些網站開放 jsp/servlet hosting, 使用的 server 大概是 Tomcat + Apache, 有的也提供 mysql 當 backend 的資料庫, 但是一樣, business model 建不出來, 最後大多都掛掉了, 之後我唸了碩士班 (2005年), 就很少再接觸這方面的訊息了. 現在看到 AWS 的 management console, 裡頭透過 virtual machine 機制, 號稱可以做到動態資源分配* (CPU運算能力, 儲存空間, 頻寬), security management, 還有預先做好的很多 image, 讓使用者建 infrastructure 的時間都省去了, 我一方面感到很驚訝, AWS 做得真的滿不錯的, 一方面在想, 十幾年過去了, 這樣的成長速度該說它快還是慢呢? 最後, 為什麼江蕙的演唱會售票不使用 AWS 建置啊? 我覺得一定可以狂電目前台灣所有的售票服務系統... * 圖片引用自 http://www.slideshare.net/…/introduction-to-amazon-web-serv…

原文:  http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-programmer/ 很好的文章. 最近讀了 Expert C Programming: The Deep C Secret 也有同樣的感想. 這本書描述了非常多歷史的來龍去脈, 指出很多設計其實是在沉重的歷史包袱下做出的妥協 (*), 嚴格說起來這些東西取決於經歷而非它本身設計的美學. * Example: static 在用在區域變數和 function 的語義不 consistent 指標的星號同時擁有形容詞與動詞的意義 複雜的 pointer & const 混用, 在書裡甚至要用上一整頁的流程圖來幫助 programmer 解讀某一行的宣告/定義到底如何解譯 ... 還有很多, 這本書的快感就是作者做為一個資深 Sun programmer (Peter van der Linden), 卻可以不帶著一絲傲氣告訴你"不懂不是你不對, 而是它設計上的缺點", 和這篇文章想要表達的想法有異曲同工之妙.

Linux kernel source code 裡面常看到在 if 的條件裡加上 likely / unlikely 來暗示電腦 true or false 發生, 到底它是怎樣讓效率比較好的? 如果有人說這個是在"暗示處理器的 branch prediction", 這是錯的, 因為處理器的 branch predictor 是硬體機制, 我不確定有沒有辦法去修改, 但至少 likely / unlikely 完全不是這麼回事. 追了一下 kernel 的 source code 看到它是由 macro 定義的:  #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0)  透過反組譯就可以查出 __builtin_expect 到底在做什麼 (*), 簡單說就是把 被暗示較有可能會執行到的 code 放在下面靠近的幾行 (pipeline 後續會抓進來) 被暗示較不會被行到的 code 放遠一點, 不幸發生再 jump 過去" 這麼做的好處是可以保持 pipeline 是滿的, 因為 jump 到遠一點的地方後, 該處的"後續指令"要重新抓, 那就得把目前 pipeline 裡的東西 flush 掉重抓, 自然效率是前者比較好了. 所以總結, 這只是 compiler 幫你排一下 (暗示 compiler 可能還貼切點), 看哪一個排法比較不會影響 pipeline 的效率, 和影響 branch predictor 是二回事. * http://my.oschina.net/moooofly/blog/175019 (注意 code 當中 je 和 jne 跳到哪裡去了) ** http://stackoverflow.com/questions/248693/double-negation-in-c-code/249305#249305 ( __built_expect 二個驚嘆號算是一個小 trick, 叫做 double negation, 目的是快速的把 x 變 boolean 值) /* Update: 插入人類語言解釋 ...

有考過資工研究所的人, 唸書時應該都有學過一題"證明 0 ~ 1 之間有無限多個不可數實數"的證明 (*), 但是一般上課應該沒有人會講這個證明的由來, 今天我在看講解 Turing Machine 的書上看到它的由來. 這是一個叫 Cantor 的人在 1891 年發表的論文, 用了一個超級簡單的方法, 叫做"對角線法", 簡單到只要有國小六年級的數學程度就可以看得懂, 可是情感上很難讓人接受這樣的結果. 他更早的證明, 自己的 comment 是"我看到了, 可是我難以相信 (I see it, but I don't believe it)". 這句話真是相當貼切. 這樣回頭看來, 研究所考這樣的題目真是非常殘忍. 其實這些問題都非常的困難, 也困擾了一堆數學家很多年, 卻要在考題上出現讓我們這些二流學生去解, 不靠先看過或背過, 現場我看是沒解出來的機會吧. 最後這傢伙是在精神病院過世的, 唉, 數學家, 歹路不可行... *  http://www.matrix67.com/blog/archives/4812