Tag: push

幫你打理伺服器環境的 piku

但文件寫的很糟：「The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.」。

名字來自於 Dokku，另外應該是用到了 pico 這個數量級詞：

piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.

這個工具是在「Piku: Allows git push deployments to your own servers (github.com/piku)」這邊看到的，就如同說明提到的，希望透過 git push 就可以發佈軟體。

不過在討論裡面也有人抱怨文件的問題，像是在 id=40625339 這邊就有人提到。

實際到 AWS 上開了一台 EC2 instance 測，看起來就是提供一包 script 把伺服器端設定好，包括了 Let's Encrypt + nginx 以及 SSH 與 Git 相關的設定，接著你可以直接將這台 server 設為 git remote，然後就可以用 git push 推軟體上去了。

對於只是想要跑軟體，而且容易接 CI/CD 的方案來說還算 OK，但如果想要自己客製化 nginx 或是一些工具的情境就不是那麼適用了。

讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的，F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush：「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息：

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification)，所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案：使用者在 Android 手機上安裝一隻程式 (ntfy)，這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務)，另外一方面，當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題，還是可以 fallback 回去使用 Google 的 FCM，也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用)，但是是分散式的架構，而且使用者有一定的控制權。

目前支援的 app 看起來不多，但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援：「Apps using UnifiedPush」。

心情不好時自動送貓貓圖推播的專案

Hacker News 上看到「I wrote a program that sends cats to my phone when I'm sad at the computer (healeycodes.com)」這個東西，居然是用 cam 判斷，當判斷心情不好的時候就推播貓貓的圖片，像是這樣：

除了 machine learning 的部份快，這邊還用到了幾個服務，像是 Pushover 與 The Cat API (居然有這種服務 XDDD)...

馬上想到前陣子看的 Don't Look Up (千萬別抬頭)，裡面好像也有類似的產品 XDDD

kernel.org 推動 git push 的簽名

在 LWN 上看到 kernel.org 解釋並且推動 git push 的電子簽名：「Signed pushes for kernel.org」。

在「Signed git pushes」這篇裡面解釋了除了 git commit 本身的簽名外，另外 git push 的簽名也有重要性。

而在「Introducing the kernel.org git transparency log」這邊則是公開了對應的 git transparency log。

這個方法讓 kernel.org 上的 git repository 會更透明，加上 kernel.org 上的 git repository 會被很多人 mirror，在真的出問題的時候，大家手上也都有資料可以交叉比對...

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

nginx 的 HTTP/2 要支援 Server Push 了

在 Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了：

看起來是只要送出對應的 HTTP Header，後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽，就透過 server push 預先把 css/js 丟出去，加速頁面呈現。

Amazon Pinpoint：對 Amazon Mobile 得到的資料設定條件發推播

這次 AWS 對 Amazon Mobile 收到的資料定義條件發出推播：「Amazon Pinpoint – Hit your Targets with AWS」。

功能是陽春了一些 (其他競爭對手應該還可以發 mail 之類的)，但以 AWS 的名字放出來，等於又殺了一票市場上還沒爬起來的競爭對手...

清出一個乾淨的 Git Repository

自動化機制中，要確保可以拿到最新的 Git Repository 最保險的方法是 rm -rf 掉再重新 clone 一份，但對於稍微大一點的 repository 速度就太慢了，所以得想辦法保留 repository 加快速度。

目標是想要處理 submodule 的變更，並且仍然可以處理 force push 時的災難，避免需要人工介入... 這在建各種自動化機制時常常會用到，像是用 Fortify SCA 白箱掃描，或是 CI & CD 機制上。

BRANCH=master
git fetch --force
git reset --hard origin/"${BRANCH}"
git submodule sync --recursive
git submodule update --init --force
git clean --force --force -d -x
git checkout "${BRANCH}" --force

用了很多 --force 主要是要處理 force push 後的收拾 :o

其實如果想要處理的更好的話，可以在發生錯誤時改走 mv (保留屍體) + 重新 clone 的機制，並且發警報出來讓管理者事後研究，這樣發生問題當下還是可以先提供服務。

不過這個想法還只在腦袋裡還沒寫... XD

CloudFlare 宣佈支援 HTTP/2 的 Server Push

CloudFlare 宣佈支援 HTTP/2 的 Server Push：「Announcing Support for HTTP/2 Server Push」。

如同預期的 (最簡單的方式)，是透過 HTTP header 標示，也就是透過 rel=preload 辨識：

Link: </asset/to/push.js>; rel=preload;

可以看到沒有 Server Push 與有 Server Push 的效能差異：

HTTP/1.1 時代的 Best Practice 變成 HTTP/2 的問題

Velocity 2015 上的「HTTP/2 is here, let's optimize!」提到了很多關於 HTTP/1.1 時代所採用的 Best Practice (或者說，workaround) 變成了 HTTP/2 的問題。

這張表整理了各種技巧在 HTTP/1.1 與 HTTP/2 的差異：

在 HTTP/2 因為有了 multiplexing 機制，用了 Apply domain sharding 後反而增加 DNS query 以及開新的連線所需要的 handshake 時間。

而 Concatenate resources 也算是 workaround 的一種，不同等級的合併會有不同的 trade-off。全站合併 assets 可以讓常逛的使用者下載的量降到最低，但會讓第一次讀取的使用者花比較多時間下載。如果是單頁合併 assets，則剛好反過來：第一次讀取的使用者較快，但常逛的使用者會下載重複的內容。

最後的 Inline resources，作者則是提出利用 HTTP/2 提供的 server push 機制來改善，不過沒看懂...

有些 workaround 總算可以拋開了...