幹壞事是進步最大的原動力
在「Firefox 86: AVIF support enabled by default」這邊看到的消息，在 Firefox 86 (目前是 nightly) 預設啟用了 AVIF 影像格式，這是繼「Chrome 85 支援 AVIF」後另外一個主要的瀏覽器也跳下來支援了，大概再幾個月後就會推到 stable channel 上了。
不過想測試的人不用去裝 nightly，77 之後的版本已經支援，只是預設沒有啟用，可以透過 image.avif.enabled 開起來。
另外當初在「WebP 的檔案大小未必比 JPEG 小...」這邊剛好也有帶到 AVIF 的壓縮率不錯，不過演算法判斷非重點部位的細節會被吃掉，這點對於一般的網頁應該還好，但對於希望還是保留細節的網站，也許就不是那麼適合了...
Amazon Transcribe 是 AWS 推出語音轉文字的服務，先前只有提供 WAV、FLAC、MP3 與 MP4 格式，現在則是多支援不少格式：
Today, we are excited to announce native support for media files in AMR, AMR-WB, Ogg and WebM format by Amazon Transcribe.
AMR 與 AMR-WB 以前還蠻常看到的，最近比較少看到了，可能是專利加上選擇性多之後用的人就變少了。
上次拿 Amazon Transcribe 測日文的影片，先用 FFmpeg 把 MP4 檔內的 audio track 抽出來再丟上去轉，轉完後用 andyhopp/aws-transcribe-to-srt 把 Amazon Transcribe 輸出的 JSON 再轉成 SRT 檔，就辨識正確度測起來算是堪用，但專有名詞 (像是人名) 就得另外處理，不過比什麼都沒有好不少...
目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式，然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...
昨天早上看到「AVIF has landed」這篇，提醒我有 <picture> 這個原生支援的方式可以用，翻了一下 Can I Use 上面的支援程度，看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」)，而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback，大概是這樣：
<picture>
<source type="image/webp" srcset="https://i.gslin.com/imgur/xxxxxx.webp" />
<img src="https://i.gslin.com/imgur/xxxxxx.jpg" alt="" />
</picture>
換完後來觀察看看...
Percona 對 MariaDB 在 10.5 (目前的最新穩定版) 裡出的 S3 Engine 給出了簡單的測試報告：「MariaDB S3 Engine: Implementation and Benchmarking」。
這個 engine 顧名思義就是把資料丟到 Amazon S3 上，目前是 alpha 版本，預設是不會載入的，需要開 alpha flag 才能用：
The S3 engine is READ_ONLY so you can’t perform any write operations ( INSERT/UPDATE/DELETE ), but you can change the table structure.
另外這是從 Aria 改出來的 read-only engine，而 Aria 是從 MyISAM 改出來的：
The S3 storage engine is based on the Aria code and the main feature is that you can directly move your table from a local device to S3 using ALTER.
測出來發現在 read-only 的情境下，COUNT(*) 超快，看起來就是跟 MyISAM 體系有關，直接撈 MyISAM 內的資料，所以本地要 18 秒，但放到 S3 反而秒殺 XDDD
整體看起來還不錯？算是一種 Data warehouse 的方案，主要是要用到 row-based format 儲存的優點，遇到一些冷資料可以這樣玩。
從「Using the S3 Storage Engine」這邊的設定方式看到 s3_host_name，看起來有機會接其他家的 S3 API，或是本地的 Storage。
話說 Aria 這個引擎當初最主要的重點就在 crash-safe，在有了 crash-safe 之後，DRBD 這種 block-level replication 機制就可以硬幹上去，後來主力就在擴充其他型態了，像是 GIS 與 virtual column 的功能，不過這些功能本家在 InnoDB 上好像也都陸陸續續跟上來了，單純的 Aria engine 好像還好...
最近常常需要提供資料給其他部門 (非技術類的部門)，有時候需要提供一些表格類的資料，傳統大多數人比較熟的是產生 CSV 格式的資料讓使用者可以用 Excel 打開，但這個格式其實有很多問題，最常見的就是 encoding 與資料有逗號 comma 的問題。
如果是在 Python 下，其中一個解法是用 openpyxl 直接產生 .xlsx，但用起來還是沒那麼有下面提到的方法順手。
如果是 shell script 時就比較麻煩了，像我這次手上有一堆影片檔，要用 FFmpeg 確認每個影片的 resolution 與 framerate 再提供給同事，這時候如果還是想產生 .xlsx 就累了...
下面要提到的解法好像記得是在 K 社的時候同事教的，用 TSV 檔格式 (當然檔名要取 .tsv)，然後 encoding 用 UTF-16 (LE) 就可以解決上面提到的兩個問題，產生出來的檔案可以讓 Excel 直接打開。
在 StackOverflow 上的「Is it possible to force Excel recognize UTF-8 CSV files automatically?」這邊翻一翻，會發現裡面提到比較好的解法其實都是產生 TSV。
這邊另外推薦，就算是寫程式，也還是可以先產生出 UTF-8 的版本 (通常副檔名我都會先取 .txt)，然後用 iconv 或是 piconv 轉成 UTF-16 (LE)：
iconv -f utf8 -t utf16le a.txt > a.tsv
包到 Makefile 裡面用起來其實還蠻順手的...
因為在寫 ansible 的 playbook，有些地方想要偷懶，把檔案放進在 playbook 本身...
網路上搜了一下找到「In YAML, how do I break a string over multiple lines?」這篇，最常用的應該是 |、|- 以及 |+ 了，用這三招塞檔案應該是夠用...
裡面的範例拿 JSON 的格式來解釋還蠻有趣的，代表 JSON 真的很好懂...
在 Hacker News Daily 上看到六月的文章，看起來是 Firefox 下一個版本要支援所以冒出來了：「Date/Time Inputs Enabled on Nightly」。
然後支援多國語系：(官方拿的範例剛好就是中文)
依照 MDN 上的說明「<input type="date">」以及 Can I Use 往站上的說明「Can I use Date and time input types」，可以看到這樣又多了一個瀏覽器啦：
Safari 被稱為新世代的 IE 真不是蓋的 XDDD
Adobe 發出的公告，將在 2020 年中止所有對 Flash 的支援：「Flash & The Future of Interactive Content」。
Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.
然後 Google 與 Microsoft 也來補刀講兩句話：「So long, and thanks for all the Flash」、「Saying goodbye to Flash in Chrome」、「The End of an Era – Next Steps for Adobe Flash」。
在「MySQL 8.0: When to use utf8mb3 over utf8mb4?」這邊提到了 MySQL 對 utf8 以及 utf8mb4 的故事，以及在 MySQL 8.0 預期的效能提昇：
可以看到 Oracle 的團隊花了不少力氣提昇 utf8mb4 的效能。另外提到了在 5.7 的時候將 row format 的預設值轉成 DYNAMIC：
MySQL 5.7 (2015) added some optimizations such as a variable length sort buffer, and also changed InnoDB’s default row format to DYNAMIC. This allows for indexes on VARCHAR(255) with utf8mb4; something that made migrations more difficult prior.
依照「14.11.3 DYNAMIC and COMPRESSED Row Formats」這邊的敘述，看起來 COMPRESSED 也應該支援一樣的特性，不過不確定... （因為通常不會完整 index 整個 VARCHAR(255)，只會 index 某個 prefix length)：
The COMPRESSED row format uses similar internal details for off-page storage as the DYNAMIC row format, with additional storage and performance considerations from the table and index data being compressed and using smaller page sizes.
