矽酸質塗佈型防水材施作

「矽酸質塗佈型防水材施作」的重點整理，參考網路上，樂土郭博士的教學

重點條列整理如下

1. 材料有 5 Kg 包裝 / 25 Kg 包裝
2. 適用範圍 -- 負壓面，即外牆滲水，施作於室內的壁面
3. 用水清洗牆面，要在壁面濕潤下施作，
4. 1 平方米，要 1.5 Kg 的材料
5. 加水量 26%，即 5 Kg 材料加 1.3 Kg 的水
6. 均勻攪拌 3 分鐘
7. 要用毛刷塗佈 2 次
8. 塗第 1 次後，在手摸硬化之後，可進行第 2 次塗佈
9. 噴水養護 3~7天，保持壁面潮濕，使其反應完全

我回來了

在 Yahoo 決定關掉部落格之後，落腳 Hinet 的「隨意窩 (Xuite)」，它的速度脫泥帶水，編輯功能不好用，這也就算了。最後，還出現了老擋在前面的廣告，防礙正常作業。

因此想找個能用得久一點的部落格。Google 該不會那天也決定關掉這功能吧!

啊，我知道，為何不用這個部落格了，沒有文章分類，只能按日期排列記流水帳 ...

2015-6-7，抱歉，我錯了，靠著 Google 的幫忙，發現我錯了，是可以幫文章加上標籤的，只是比較不直覺而已。嗯，你已經看到了，就在此文的旁邊。

ffmpeg 轉檔測試

 2015-02-10 14:13

fmpeg 轉檔測試，主要是針對產生 H.264 的影片，不同條件下，產生的檔案差異

原始檔的資料

• 檔案大小 754MB
• 長度 1h:38mn
• Overall bit rate : 1,074 Kbps
• Video 的 bit rate: 878 Kbps

Two-pass 轉檔

指令 ffmpeg -i input.mp4 -y -c:v libx264 -preset medium -b:v 800k -pass 1 -f mp4 /dev/null && ffmpeg -i input.mp4 -c:v libx264 -preset medium -b:v 800k -pass 2 output.mp4

• 檔案大小 657 MiB
• Overall bit rate : 936 Kbps
• Video bit rate : 800 Kbps

Constant Rate Factor (crf=20)

指令 ffmpeg -i input.mp4  -c:v libx264  -crf 20 -maxrate 1000k -threads 6 output.mp4

• 檔案大小 446 MiB
• Overall bit rate mode : Variable，Overall bit rate : 636 Kbps
• Video bit rate : 499 Kbps

Average Bit Rate (ABR, 800Kbps)

指令 ffmpeg -i input.mp4 -c:v libx264  -b:v 800k -threads 6 output.mp4

• 檔案大小 592 MiB
• Overall bit rate : 843 Kbps
• Video bit rate : 706 Kbps，Nominal bit rate : 800 Kbps

Groovy，真的是 groovy

 2015-01-08 20:26

有句話說，「肝要是不好，人生是黑白；肝要是好，人生是彩色的」

開發網頁，在 Java 的黑白世界中，Groovy 讓它變成彩色的。

最近，接了一個用 Java 開發的專案，真有股衝動，想把它換成熟悉的 PHP+Laravel。可是，它可是集合多人，經過多年才完成的結果，若想換語言，那可不是輕易的想做就可以完成的。一邊用 PHP 挖掘系統的細節，一邊思考該如何做才好。經過一陣子，無聊的，在 Google 上，搜尋類似「Java 好難」的 keyword，不經意的注意到和 Java 似乎完全不相干的字眼，Groovy。細看下去，還真的讓我心中，陰暗的天空，逐漸的開朗，彩色慢慢的重現出來。然後，相關的 Grails 也連帶的出現，心情就變得更好了。

Groovy，正如其名，真的是 groovy。把原來的 Java 程式，剪貼進來，完全照吃。然後，接下來的修改，就變得很隨興，行尾不加「;」，只用 def 宣告變數。list 和 map，更是讓人不用再去碰那難用的 ArrayList。

人生真的，因 Groory 而變得明亮，富有彩色了。

論文寫作修訂整理

 2014-06-29 10:10

投稿的 paper 被 reviewer 嫌英文太差，要求經 native English speaker 修訂。透過前輩介紹，給台灣有名的 Ted 教授修訂。一個 word 要台幣 2 元，一篇 paper 有 9 千多字，花了 1萬8。國科會最多可以報 1 個字 1 元左右，不夠的要自己墊。好在有上，剛好過畢業門檻，算是值得。

修訂重點與建議，整理如下，以供參考。

• Avoid First person “We” unless explicitly stating your opinion such as ‘we conclude’ ‘we can infer’ ‘we posit’ ‘we speculate’ ‘we recommend’ ‘we postulate’ ‘we hypothesize’.
• Avoid negative voice in technical writing as much as possible. 例如 ‘not inconvenient’ -> ‘inconvenient’ 或 ‘infeasible’。
• Consistent verb tense is important.  Unnecessarily switching back and forth in verb tense – especially in the same paragraph – will confuse the reader. 華人最困擾的部分之一 – 時式。
• Don’t always use Chinese-English structure of  “A is used to solve B.”  Instead write more directly in emphasizing the contribution rather than the method itself by stating “B is analyzed using A.” 華人感到困擾的部分之一 – “用 A 來解決 B” ，沒有生命的東西怎麼會有動詞呢?。
• Avoid redundancy.  Why do you have to repeat ‘implement’ twice in the same sentence. 例如 As a resultConsequently, a most intuitive implementation of the AC-algorithm is to implements the AC-DFA in a lookup table. 唉，你以為我喜歡啊，就只會那一招半式而已啊 ... 不過，這句也改得怪怪的，後來指導教授有修訂。這兒就做個參考吧。
• a higher throughput THAN WHAT? ‘higher’ implies a comparison with something. Just write ‘high’ if not implying a comparison. 啊，我們就習慣說得到比較好的結果啊，那考慮那麼多 ...
• However, Yet another difference between the software and hardware approaches also differ in is that the former generally has a larger dictionary size can be larger in a software approach generally. 簡潔有力，就是要這樣改。不過，還要再練，才有辦法。
• Especially when implementing a multi-character transition matching architecture, the required space will (NOTE: Avoid future verb tense in technical writing as much as possible) grows exponentially with respect to the number of characters (to be inspected OR under inspection) in parallel.

FastCgi + Phalcon 有多快

 2014-02-02 12:59

使用 Laravel 之後，自己負責的應用程式，差不多都 porting 到 Laravel，只剩下一個有效能要求的，不敢動，仍然使用 ASP.NET。春節 (2014) 期間，上網看到 Bruno Skvorc 的 "Best PHP Frameworks for 2014" (http://www.sitepoint.com/best-php-frameworks-2014)，排名第二的 PhalconPHP (簡稱 Phalcon)，以效能著稱，不禁心動，春節過後，就來實際測試一下。

其實，Phalcon 並非第一個擴展的框架 (extension-based framework)，YAF 在 2011 年中就已提出，並被包含在 pecl extension 中。而且，在目前可得到的 benchmark，YAF 還是略快一些。只是，相對於 Laravel 這樣方便的框架，Phalcon 和 YAF，兩者都同樣有 extension-based framework 特有的難以使用的特性，而 YAF 還更難一些。至少，我照著 Phalcon 的網頁，簡單的建立幾個檔案，就可以看到成果。YAF 則要更為深入的調整，才能成功。另一個，不考慮 YAF 的因素是，其最後的 DLL 下載版本是一年前的，表示，這一段時間，它的進展是停滯的。

測試環境，OS 為安裝在 VMware ESXi 5.1上面的 Window server 2003，配置 CPU*2，1.5GB RAM，PHP 為 5.4.12。資料庫存取為透過 PDO:SQLSRV 從 MS SQL 2000 取得某個使用者的相關紀錄，大約 10 筆，傳回的文件長度約 680 bytes。

執行命令 ab -n 100 -c 10 http://10.161.81.190/abtest.php

CASE 1
首先，來個測試的基準，在 php 中單純送出 'hello' 文字，傳回的文件長度為 5 bytes。
CGI 的結果為 29.65 [#/sec] (Requests per second) 。
使用 FastCGI 1.5，第一次 1534.14 [#/sec] ，第二次 3305.29 [#/sec]。

具資料庫操作的測試，CGI 為 18.15 [#/sec]，FastCGI 為 1377.57 [#/sec]

對照組，ASP.NET 的結果為 1462.69 [#/sec]。
另外，也用 phalanger 測了一下，大約在七八百之間吧。不過，終究其相容性較差，PDO:SQLSRV 無法正常運作，Laravel 也跑不動，用 Google 搜尋，也不容易找到相關資訊，不要再浪費時間去測試了。

CASE 2
使用 PhaconPHP 1.2.6，具資料庫操作。
單純使用 CGI 的結果，20.16 [#/sec]。
使用 FastCGI 1.5，第一次 208.91 [#/sec]，第二次 788.36 [#/sec]。

CASE 3
使用 Laravel 3.2.14，無資料庫操作，單純的產生一個空白的 form，未連結資料庫， 傳回的文件長度為 737 bytes。
使用 CGI 的結果，15.19 [#/sec]。
使用 FastCGI 1.5，第一次 64.32 [#/sec]，第二次 71.83 [#/sec]。

 比較表

	CGI	FastCGI
PHP (純文字)	30	3305
PHP (資料庫)	18	1377
ASP.NET	NA	1463
Phalcon	20	788
Laravel	15	72

註: 結果取較高的次數，並且四捨五入

個人心得
非 常吸引人的結果，使用 PhaconPHP 配合 FastCGI，效能可以提昇 10 倍以上，從每秒處理的服務數量來看，能有超過 500 次的能力，著實讓人心動。但在目前的版本下，有個小問題是其所支援資料庫實在很少。另外，使用 FastCGI 有個不便之處，那就是基於安全的考量， FastCGI 會隱藏錯誤訊息，debug 要稍微費心些。說真的，暴露出錯誤訊息，是不好的習慣，但人有時候就是為了省事和方便，不會認真處理錯誤訊息。

FastCGI 對於 Laravel 的提昇效果並沒有如此顯著，但我所負責的程式，大多每分鐘的使用者都不超過一個人，就算使用 CGI 也足以應付，真正在乎的是程式好寫且好維護。

誠如 Bruno Skvorc 的結論所說的，各個 PHP 的 FrameWork，深究其中，都很類似。而 Phalcon 在提昇效能上的作法，無疑的提供了一個不錯的可行方向。曾聽起前輩提到科技發展的 divergence and convergence，在各種 FrameWork 相繼被提出之後，最終，PHP 可能會加上原生 MVC 的支援。

令人失望的新款小紅點鍵盤

 2013-12-05 23:39

現在只有一個想法，覺得「中國設計製造，真是讓人沒信心」。

我是 IBM 的 Trackpoint 鍵盤的愛用者。最近 (2013 年 11 月)，因為使用中的鍵盤變髒變舊了，想再買個新的。

好不容易，透過網拍，找到一個，產品的全名叫 ThinkPad Compact USB Keyboard with TrackPoint，多了一個 Compact 的形容詞，型號為 KU-1255。雖然沒有中文輸入法，但將就著用也還好。只是，用了一陣子之後，真的是讓人感到很失望。

舊款的叫作 ThinkPad USB Keyboard with TrackPoint，型號為 SK-8855，FRU 為 55Y9010，或繁體中文的 FRU 為 55Y9060。

明顯的缺點是，按鍵行程變得更短，很沒有觸感，打字很不舒服。而且，手指很難放對位置，在按右邊的 Shift 時，老是按到 Ctrl。

最嚴重的缺點則是，把調 Trackpoint 的 sensitivity 的功能給閹掉了。雖然可以調指標速度，讓游標移動的很輕鬆。但是配合中間按鍵模擬 scroll 功能時，就要較費力推動。一整天下來，可以微微感覺肘部肌肉，甚至背部的肌肉，都會緊張，持續個幾天，就會造成肌肉疼痛。

ThinkPad 的鍵盤，自 IBM 以來，已經用了很多年。IBM 的鍵盤，一般來說，還可以接受。不知道聯想 (Lenovo) 在買下 ThinkPad 時，談的授權為何。想來是授權的約束或時間過了，聯想為了省錢，就改用自己的設計。以往，會買 ThinkPad 的筆電或鍵盤，純粹是為了那顆小紅點。如今，鍵盤和 TrackPoint 變得如此難用，ThinkPad 的愛用者，再買新的電腦時，真的該考慮不同的品牌了。

不得已，我只好趁網路上還買得到舊款的時候，趕快搶購一個，還可以再撐著用個幾年吧。這個新款的，就留著當備用的了。

2013-12-15 補記

其實，是我後知後覺，ThinkPad 早就因為鍵盤的改版而吵得熱鬧滾滾。雖然，似乎有人支持聯想求新求變的作法，但相信會有許多人，已經決定不再買新的 ThinkPad 了。這個連結的說法可以做個參考http://ultrabook.pconline.com.cn/330/3304664.html

這個連結的 title 定為「ThinkPad X1c 長测三:巧克力鍵盤中的霸主」，會讓人誤認為新的比舊的好，應該是說，巧克力鍵盤都不太好用，ThinkPad 的做得最好，雖然是越改越差，只是「乞丐中的霸主」罷了。

綜合一下，該文的說法

首先，對巧克力鍵盤做一些說明。在 92% 全尺寸鍵盤的標準下，採用巧克力块獨立式鍵帽，讓每個按鍵如同巧克力塊浮在水面上一般放置在鍵盤底座上。在保證了鍵盤區尺寸的情况下，增大了手指與鍵帽接觸的面積，擊鍵更加準確，手感更加舒適。依據人體工學特徵設計出凹帽状按鍵，同时，非粘連設計也減少了按錯鍵的機率，這與傳統鍵盤相比，不論是鍵程還是鍵距都有著明顯的提高，增加了操作的舒適度。外觀簡明清潔、1.902mm 最佳鍵程和指腹彎曲設計、强對比色標注快捷鍵、按鍵防塵功能緊湊、手感舒適，這些内涵，在巧克力鍵盤上得到了融合創新與呈現。

但是，以上巧克力鍵盤的特徵，並不一定優於 ThinkPad 傳統鍵盤。ThinkPad 傳統鍵盤為了良好的手感需要比較大的鍵程，每一個按鍵的下方還留有一定的弧度，雖然看上去它贴合手指的面積和巧克力鍵盤相仿，但是它鍵帽下沿的區域對於手指感受提升是很明顯的。用戶手指每一次按鍵不一定會按到鍵帽的中间部位，即便只按到了下沿區域也能够獲得回馈，變相的來說，ThinkPad 傳統鍵盤的實際反馈面積要比改進后的鍵面要大，也就是對用戶輸入錯誤的纠正能力要强很多。這也是為什麼 ThinkPad 的鍵盤给人的感覺打字極為舒適。

現在，再說回 ThinkPad X1 Carbon，這款產品所採用了新一代的巧克力鍵鍵盤，但是它也並非普通的巧克力鍵盤，ThinkPad 的獨特依舊存在。相比 ThinkPad 傳統鍵盤，新鍵盤的鍵帽增大了接觸面積，增添了 “X” 型支架。雖然這些改進從賬面上來說讓它更美了，但是實際的手感確實有所下降。除了傳統鍵盤的真正面積要大之外，傳統鍵程確實要長一些輕微。新型鍵盤的 “X” 型支架與 “鼓” 型弹片對回饋力的影響很大，按鍵按上去並不是那麼 “渾厚” 和稳定，有一點輕飄飄的。好處是不需要太大的力氣即可打字。壞處就是，傳統鍵盤的柔顺手感確實已經不再了，需要老用戶們重新去適應。

先前 (T400s) 提供更大尺寸的 [Esc] 和 [Delete] 按鍵，因為它說

. 研究結果表明使用率高的按鍵是 Esc 和 Delete 鍵

. 調查結果表明 Delete 鍵平均使用約 700 次/星期

ThinkPad 傳統鍵盤對鍵盤排列的理解也遠超過競爭的產品，比如現如今依舊堅持著 Fn 鍵在左下角，用戶在光線不足的情況下，可以很容易摸到组合必備的 Fn 鍵。另外就是大家常用的 Shift+Ctrl 切换輸入法，如果你用中指按住 Shift，再用食指即可，而如果 Ctrl 鍵在邊角上，你就需要用不怎麼有力的无名指，或者把手多移動一些位置，在使用中指與食指。再有就是 7 行這些小细節的與眾不同正是 ThinkPad 的精準所在。

　ThinkPad X1 Carbon 保留了大部分 ThinkPad 傳統鍵盤的鍵位排列顺序，也改動了很多细節，比如將原先的 7 行鍵盤改為 6 行，去掉了 Pause/break 鍵，將原先的大面積的 ESC 缩小，Delete 做成了横向等等。我們看到現如今的 ThinkPad 鍵盤更加簡潔了，但是某些東西是否也不再保留了呢？

綜合來說 ThinkPad X1 Carbon 的鍵盤體驗其實並不如之前的舊款產品，在機身變薄之後，它的按鍵厚度也比 T 系列要薄，這也是為什麼總覺得有些輕飄飄的。在簡潔的流行風之下，為了輕薄便携的 ThinkPad X1 Carbon 也走上了巧克力鍵盤之路。其實去年聯想將 ThinkPad 全線更新為巧克力鍵盤之後，也引來了一大片的反對之聲。曾經有網友評論 “如果整個市場上一水的巧克力鍵盤，那我憑什麼要選 ThinkPad？” 答案或許是：他是巧克力鍵盤中做得最好的。