HTTP/2

原文網址：http://www.integralist.co.uk/posts/http2.html

---

引言

這是一篇很簡短的文章，展示如何利用新的 HTTP/2 通訊協定。如果你不熟悉它，那麼讓我花一點點時間來討論其中的一些亮點：

• 單一、持續的連線
• Multiplexing
• 壓縮 header
• 優先等級
• 加密
• Server Push

如果這些功能對你而言都不知所云，讓我作進一步的解釋……

Maven Assembly 的各種版本哏

故事是這樣的，專案的 project 海當中有一個是處理 Applet（不要問為什麼這個年代還在用 Applet，我後來改了一個 JWS 的版本，但是客戶還是想要保留 Applet [攤手]）。雖然這個 project 是 maven 結構，但是 sign jar 還有最後整合進去真正的 web project 都還是用人工手動作的（不要再問了，我都要落淚了）。

雖然千百個不願意碰這個 Applet project，但事情終究還是發生了，因為最底層的 library 升級了，所以不改不行，那就順便把他變得自動化一點吧… Orz

sign jar 當然是找 maven-jarsigner-plugin（以下簡稱 jarsigner），掛上去之後發現… 奇怪，怎麼始終 build 失敗？用他錯誤訊息噴出來的那個 Windows command 字串去執行看看（當然要把 keypass 跟 storepass 換回實際的字串）卻又沒問題。喔對了，似乎這個問題只會在 Windows 上頭重現… Orz

最後發現，問題不是出在 jarsigner 上，而是 project 當中本來就有掛的 maven-assembly-plugin（以下簡稱 assembly）造成的。因為如果拿掉 assembly 的設定、或是把 jarsigner 挪到 assembly 之前（這居然是某些人認為的解法… 完全沒意義阿… WTF），是可以正常運作的。

兩個 plugin 的官方 issue tracker 都有這件事情（jarsigner、assembly）。似乎是 assembly 2.2 版之後才會發生的事情，因為退回到 2.1 版就沒問題了，那就退回去吧… 祈禱不要踩到「為什麼要升級」的哏。

BUT…

希望 assembly 產生的檔名是乾淨的 foo.jar，所以加了 <finalName>、也加了 <appendAssemblyId>false</appendAssemblyId>，然後又開始 build 失敗了。問題點是卡在 <appendAssemblyId> 上頭。最妙的事情是… 這個問題在 2.2 之後解決了…

…………（嗶──）

好了，解法有兩個，一個是忘記 assembly 改成用 maven-shade-plugin，我用 2.0 版測試沒有問題，能滿足上述兩個需求。

另一個是… 把 assembly 提升到 2.6，也可以滿足上述兩個需求… （我沒有測 assembly 2.5 搭配 jarsigner 會不會出問題，但是 2.4 版是確定有問題的）

…………（嗶──）

我說那個 issue 可以麻煩順便關一關嗎？還是說根本是不知不覺間修好了，所以也沒發現......

這種排列組合的問題實在是很浪費生命阿… [淚目]

畫一個箭頭

注意

這是一個沒學過圖學、線性代數也亂學的人寫出來的東西 (艸

名詞定義

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)

理解 Finalizer

原文網址：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。

啥時找 library？啥時自幹？

原文網址：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，因為我會假設他們處理一些我不知道的特殊狀況。不過它們搞出來的麻煩往往多過它們的價值。

2014 年 GWT 調查報告中文摘要

原始報告請到 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 為篇名。

基本上都只翻譯數據跟（個人認定的）重點，非逐句翻譯。

---

1. 評價

4.47 分（滿分 5 分）。

這是 1101 份投票的平均分數。有 82% 的人投了 4 分以上。