注意
這是一個沒學過圖學、線性代數也亂學的人寫出來的東西 (艸
input：
S 座標為 (sx, sy)E 座標為 (ex, ey)rx1、rx2、ry1、ry2。d
d = 0。箭頭向下是 d=90。變數：
w：abs(ex - sx)h：abs(ey - sy)x2：w * rx2 / (rx1 + rx2)y2：h * ry2 / (ry1 + ry2) / 2所以各點座標為：
A：(ex, (sy + ey) / 2)B1：(sx + x2, sy)B2：(sx + x2, sy + y2)C1：(sx, sy + y2)C2：(sx, ey - y2)B3：(sx + x2, ey - y2)B1：(sx + x2, ey)原文網址：https://plumbr.eu/blog/debugging-to-understand-finalizer
這篇文章涵蓋了一個 Java 的內建功能：Finalizer。這個功能實際上廣為人知卻也鮮為人知，取決於你是否仔細看過 java.lang.Object。在 java.lang.Object 中有一個叫做 finalize() 的 method。它沒有實際的內容，但是它的威能與危險程度都取決於 JVM 內部如何處置這個 method。
當 JVM 偵測到 class 有 finalize() 這個 method，黑魔法就開始了。所以，我們來弄一個有不同 finalize() 的 class，這樣我們就能知道在這種狀況下 JVM 會如何處理這個 object。
原文網址：http://games.greggman.com/game/when-to-find-a-library-vs-when-to-write-code/
譯註：我幾乎完全不認同這篇的說法，更不用說 HappyFunTimes 也是一個 library [大笑]。只是拿來恢復一下翻譯的感覺…
身為一個 C / C++ 碼農，除非是很大的 project，不然我很少找 library。舉例來說，如果我需要讀 BMP / TGA 檔，帳面上要寫的程式碼不到 100 行。看一下資料格式、寫一些程式、打完收工。要是我需要載入 JPG / PNG 這些格式異常複雜的檔案，我終究會去找一個 library。
我現在寫 JavaScript 就不太一樣，在 JavaScript 的世界中有數以萬計針對各種狀況的小型 library，讓我不知道該自幹程式還是找找看有沒有 library。這常常讓我覺得很浪費時間。
例如我要有一個非常簡單的功能：把字串裡頭的關鍵字換掉：
replaceParams("Hello %(name)s", {name: "World"});
// produces:
// Hello World
後來為了可以這樣搞，所以拓展到 20 行：
replaceParams(
"Hello %(name)s from %(user.country)s",
{
name: "Joe",
user: {
country:"USA",
},
});
// produces:
// Hello Joe from USA
最近我希望可以用路徑插入其他檔案，像這樣：
replaceParams("->%(insertfile: foo/bar/moo.txt)s<-");
如果 moo.txt 裡頭是 this-and-that，結果會是：
-->this-and-that<--
只需要幾分鐘的時間就可以加這個功能，但是… JavaScript 中的 template 系統超級多，我建一個 template 很快。也許我應該去用那些 template 系統而不是重新再造輪。
那麼，第一個問題是：要用哪一個？我聽過 mustache、handlebars、jade、ejs…… 為什麼要選 A 而不選 B？我花了大概 20 分鐘搜尋、試圖比較… 來讓我知道哪一個比較優秀。我看到「ejs = 嵌入 JS」看起來很像 PHP；我看到 handlebars 是以 mustache 為基礎但是快了很多。我決定用 handlebars、花了大概 20 分鐘來改程式碼，它輸出相同的結果，一切看起來很棒。
然後我試著加上我那個 insertfile 指令，靠夭，炸了 AFAICT，除了關鍵字以外都沒辦法傳進 template 中。現在已經過了一小時了，誰能告訴我為什麼我要再作一次這件事情？
這就是為什麼寫這篇文章《啥時找 library？啥時自幹？》。當然，在這個例子中，如果我不去找 library 就可能只會花掉我 5～10 分鐘。我選用的 library 有一些功能，像是可以擴展功能… 自幹版當然也可以加功能。另外它可以選擇要不要轉換跳脫字元，自幹版當然也可以有這個功能。我其實沒有答案……
我知道的是… 找 library 讓我覺得分心、浪費時間。前頭我很誇張地描述許多我下載的熱門 library 證實是爛掉的，時間都花在找尋、設定跟測試。相對地，也有人告訴我應該使用更多 library。像最近在 HappyFunTimes 就有人說我應該用 body-parser 來自動分析 JSON 而不是自己處理。我的程式有 5… 也許 10 行，但是 body-parser 有 2000 行。好啦好啦，它能處理一堆 case，但是這些 case 在 HappyFunTimes 幾乎都不會遇到。我試了 body-parser 結果發現它也沒有處理我沒法處理的錯誤。如果我能解決這些錯誤，在網路上找答案是不會解決的，只會找到誰也遇到這個問題而且一樣沒辦法解決。
我想用 library，因為我會假設他們處理一些我不知道的特殊狀況。不過它們搞出來的麻煩往往多過它們的價值。
原始報告請到 https://vaadin.com/documents/10187/4238532/GWT_report_2015.pdf 下載。 這個連結是在某個 G+ 上頭看到的， 目前 https:/vaadin.com/gwt 的連結還是指向 2013 的版本， 但是 https://vaadin.com/gwt/report-2015 的東西似乎 ready 了？
這是在 2014 年作的調查，所以雖然 vaadin 是標注 2015 年， 我還是以 2014 為篇名。
基本上都只翻譯數據跟（個人認定的）重點，非逐句翻譯。
4.47 分（滿分 5 分）。
這是 1101 份投票的平均分數。有 82% 的人投了 4 分以上。
作為 Sencha GXT 的團隊代表，我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間，我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員，你們的回饋意見始終是非常寶貴的。
GXT 3.1 導入了新的 Theme Builder（妝點 GXT 程式的新工具）、Neptune 這個佈景主題就是用 Theme Builder 做出來的；另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。
（譯註：省略兩段純粹提供 3.1 各式連結的部份）