生一個 static 版本的 ffmpeg

目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題,沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD),但反正看一看沒看到適合的,所以弄了一天包了一包出來。另外也是因為同樣理由,這邊也只能提供步驟讓大家自己編...

我的主力放在 AV1VP9 的支援上,步驟就寫在「FFmpeg」這邊了,裡面是先開了一個 Docker container 再去裝環境,接著再把會用到的 source code 用 git clone 拉下來再固定版本,所以應該是不會有太大的意外。

另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包,主要是查了一下版本還算堪用,而且也不是主力要處理的東西,就不想要再自己拉下來編了。

這邊就是整理一下感想...

首先是 Rust 一直在推新功能,然後各家的軟體也幾乎就是馬上跳進去用這些新功能,所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e

然後 x265 搞不定 static compile 的問題,卡在沒有 libgcc_s.a 可以用,如果還要搞 GCC 的話就太累了...

這樣在 AV1 與 VP9 的支援度就比較完整了,另外內建 libvmaf 也可以拿來分析...

用 Semgrep 掃一些安全性的問題

Hacker News Daily 上看到「Semgrep」這個軟體,看名字本來還以為是 semantic grep,結果是個靜態分析工具:

Static analysis at ludicrous speed
Find bugs and enforce code standards

專案是用 Python 寫的,可以直接用 pip install semgrep 裝起來,然後直接下指令掃,像是在自己的專案裡面執行,這邊用的 ruleset 是 r2c-ci

semgrep --config=p/ci .

官方網站上的截圖看起來也整的不錯:

可以自己跑或是掛進 CI 裡面跑...

Facebook 放出 Pysa,靜態分析 Python 程式碼的工具

Facebook 丟出來的靜態分析工具,可以拿來分析 Python 程式碼:「Pysa: An open source static analysis tool to detect and prevent security issues in Python code」,專案在「facebook/pyre-check」這邊可以取得。

不過軟體居然是用 OCaml 寫的啊,另外已經包好了,可以用 pip 直接裝 pyre-check

官方的說明裡面有提到要裝 watchman,不過這算是選擇性安裝,不裝 watchman 直接執行也可以用,只是會跳個訊息跟你說裝了可以遞增檢查:

To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install

最近在寫的專案都是用 Python,剛好可以拿來掃這些專案...

靜態網頁服務的選擇

Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇,除了文章連結外,留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務,或是透過 Netlify,需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後,其他人把真正有用的工具整理了出來...

在 Raspberry Pi 上面設定 Fixed IP (Static IP)

家裡本來是用 Raspberry Pi (第一代) 跑 SmokePing 觀察有線電視提供的網路 (看品質狀況),但前陣子 SD card 掛掉了... 只好網路上找一張新的 SD card 重新裝一套系統。

在拿到卡後去 Raspberry Pi 的官網上下載最新版的 Raspbian,發現版本變新後,裡面有不少東西不一樣了 :o

固定 IP address 以前都是改 /etc/network/interfaces,但裡面可以看到還蠻有趣的警告,我就是要設定 Static IP:

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

這邊說明了如果要設定固定 IP 的話不要改這個檔案,而是修改 /etc/dhcpcd.confdhcpcd 處理。

打開以後依樣畫葫蘆,加了一段進去後重開機應該就可以用了:

interface eth0
static ip_address=192.168.2.1/24
static routers=192.168.2.254
static domain_name_servers=192.168.2.254

繼續處理後續的設定...

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

用 Psalm 掃出 PHP 有問題的程式碼

Psalm 的 slogan 是「A static analysis tool for PHP」,由 Vimeo 發展並開放出來的軟體:「vimeo/psalm」。

目前是 v0.3.71,所以需要 PHP 5.6 以上才能跑:

  • v0.3.x supports checking PHP 5.4 - 7.1 code, and requires PHP 5.6+ to run.
  • v0.2.x supports checking PHP 5.4 - 7.0 code and requires PHP 5.4+ to run.

Psalm 主要的目標是找出哪邊「已經發生錯誤」,而不像其他幾套的目標是「預防」,這樣可以避免過高的 false alarm...

靜態站台的選擇...

Hacker News 首頁上看到的文章,講 Jekyll 一路跟 Amazon S3Amazon CloudFront 接上去的步驟:「Jekyll CBCD Pipeline to the Cloud」。

我看了以後覺得好麻煩 @_@

然後回頭看 Hacker News 上的評論:「Jekyll Static Web Hosting – Deployment Pipeline on AWS | Hacker News」,看到這段:

What a nightmare. I'm sure there are use cases for a setup like this, but this is not the system I'd like to maintain. I use Jekyll because of it's simplicity. I edit my site in my favorite text editor and rsync to shared hosting.

好多人都有同感啊 XDDD

另外有人提到 Netlify 這個服務:

After I discovered Netlify, I'm kind of thinking "why bother". It's free, I just push to my repo and they take care of all the building/publishing/hosting/CDNs, and they're very responsive for support and have high availability. I'm a very happy customer (or rather leech, as I don't pay anything).

下面評價看起來還算不錯,而且有 free tier 可以用,也許可以找機會玩看看...

shellcheck

在朋友的 Twitter 上看到 shellcheck (ShellCheck, a static analysis tool for shell scripts) 這個專案:

可以看到有點像是 lint 工具,給了不少建議:

而且看起來已經發展很久了... 在各大 distribution 內都可以直接裝。

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

Facebook 花了不少時間對付 reload 這件事情:「This browser tweak saved 60% of requests to Facebook」。

Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應:

In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.

Google Chrome 很明顯偏高:

於是他們找出原因後,發現 Google Chrome 只要 POST 後的頁面都會 revalidate:

A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.

然後在討論後認為這個行為不必要,就修掉了,可以看到降了非常多:

We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.

但還是很明顯比起其他瀏覽器偏高不少,在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter),Google Chrome 會當作 reload:

The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.

不過這次推出修正後發現沒有大改變:(拿 production 測試 XDDD)

Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.

後來是針對 reload button 的行為修改,max-age 很長的就不 reload,比較短的就 reload。算是一種 workaround:

There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

Google 也發了一篇說明這個新功能:「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時,Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate,而不像 Google Chrome 的 workaround:

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...