jQuery 的發明人 John Resig 已經超久沒更新 blog 了，雖然有訂起來但沒想到會看到他更新：「Twitter vs. Mastodon」。上次的更新是 2016 年初，快七年了。
基本上裡面就是解釋 Twitter 與 Mastodon 的差異，然後順便介紹他自己的 Mastodon 帳號。
不過目前看了一輪，ActivityPub 的各種實做還是離理想差了一截，可能會先繼續龜著...
Mozilla 推出在本地端直接翻譯的 Firefox Translations
Mozilla 推出了「Firefox Translations」這個 Firefox 上的套件。
主打的就是 offline 這件事情，保有隱私性：
Firefox Translations provides automated translation of web content. Unlike cloud-based alternatives, translation is done locally, on the client-side, so that the text being translated does not leave your machine.
從 Hacker News 上的討論「Firefox Translations: Translate websites in your browser without using the cloud (addons.mozilla.org)」可以看到有些人有提到效果，雖然沒有像雲端服務的準確，但算是可用：
I've just installed it, and I'm impressed so far. I've only run it against some sample German Wikipedia articles (https://de.wikipedia.org/wiki/Clan_of_Xymox), but it produces surprisingly readable text. I also particularly like the "highlight potential errors" option to flag stuff that even the translation service thinks might be a bit off.
It's not nearly as speedy as Google Translate, but I'll take that happily if it means keeping it local.
從頁面上列出的支援語言可以看出還是以歐美用到的語系為主，然後下方也有說明這個專案是包括其他計畫的贊助累積出來的：
Firefox Translations was developed with The Bergamot Project Consortium, coordinated by the University of Edinburgh with partners Charles University in Prague, the University of Sheffield, University of Tartu, and Mozilla. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 825303.
不過比較好奇的是在頁面上有提到 CPU 需要 SSE4.1 能力... 這樣就有兩個問題了，第一個是 browser extension 可以直接跑 SSE4.1 指令集？另外一個疑問就是，Apple 的 ARM 架構就無法支援嗎 (應該也有類似的加速指令集)，現在是 x86 限定？
A CPU that supports SSE4.1 extensions is required for this addon to function properly. If it doesn't, an error will be displayed when the translation is being started.
就算現在限制很多，看起來還是個很有前途的計畫，也許有機會移植到其他瀏覽器上？
Cloudflare 宣佈漲價
Cloudflare 寫了一篇很長的漲價公告：「Adjusting pricing, introducing annual plans, and accelerating innovation」。
25% 的漲幅，本來的 Pro Plan 從 $20/mo 漲到 $25/mo，本來的 Business Plan 從 $200/mo 漲到 $250/mo：
Cloudflare is raising prices for the first time in the last 12 years. Beginning January 15, 2023, new sign-ups will be charged $25 per month for our Pro Plan (up from $20 per month) and $250 per month for our Business Plan (up from $200 per month). Any paying customers who sign up before January 15, 2023, including any currently paying customers who signed up at any point over the last 12 years, will be grandfathered at the old monthly price until May 14, 2023.
然後丟出年費方案，就跟原來的月費方案寄算十二個月一樣的價錢 ($240/y 與 $2400/y)：
We are also introducing an option to pay annually, rather than monthly, that we hope most customers will choose to switch to. Annual plans are available today and discounted from the new monthly rate to $240 per year for the Pro Plan (the equivalent of $20 per month, saving $60 per year) and $2,400 per year for the Business Plan (the equivalent of $200 per month, saving $600 per year). In other words, if you choose to pay annually for Cloudflare you can lock in our old monthly prices.
後面就是很長的解釋...
這次 Amazon EFS 兩個新推出的項目：Elastic Throughput 與更低的 latency
這次 re:Invent 關於 Amazon EFS 推出來的新東西，目前有看到兩個，第一個是「New – Announcing Amazon EFS Elastic Throughput」，介紹 Elastic Throughput。
傳統的 Busrting Throughput 模式會依照你的使用空間分配對應的速度，基礎是 50MB/sec per TB 計算，但可以 burst 到 100MB/sec per TB：
When burst credits are available, a file system can drive throughput up to 100 MiBps per TiB of storage, up to the Amazon EFS Region's limit, with a minimum of 100 MiBps. If no burst credits are available, a file system can drive up to 50 MiBps per TiB of storage, with a minimum of 1 MiBps.
而 Elastic Throughput 是一種高效能的模式，可以提供 3GB/sec 的讀取速度與 1GB/sec 的寫入速度：
Elastic Throughput allows you to drive throughput up to a limit of 3 GiB/s for read operations and 1 GiB/s for write operations per file system in all Regions.
但這然是有代價的，Elastic Throughput 的計費方式按照傳輸量計算，以 us-east-1 的計價來說，讀取是 $0.03/GB，寫入是 $0.06/GB。
粗粗算了一下，比較適合短時間要很大量快速讀寫的應用。如果是不在意時間的 (像是 cron job) 就不需要 Elastic Throughput... 然後 home 目錄拿來用可能是個不錯的選擇？
第二個推出的項目是不用錢的，是 Amazon EFS 效能的改進，降低 latency：「AWS announces lower latencies for Amazon Elastic File System」。
首先是讀取的效能提昇，以敘述看起來像是加上了 cache 層產生的效能改進：
Amazon EFS now delivers up to 60% lower read operation latencies when working with frequently-accessed data and metadata.
另外是對小檔寫入有做處理：
In addition, EFS now delivers up to 40% lower write operation latencies when working with small files (<64 KB) and metadata.
不過這些改進只有在新的 EFS 才會有，而且這波只有 us-east-1 上：
These enhancements are available automatically for all new EFS file systems using General Purpose mode in the US East (N. Virginia) Region, and will become available in the remaining AWS commercial regions over the coming weeks.
AWS 推出加速 Lambda 啟動速度的 Lambda SnapStart
今年 AWS 的 re:Invent 又開始了，這一個禮拜會冒出蠻多新功能的，挑自己覺得比較有興趣得來寫。
AWS 針對 Lambda 推出 Lambda SnapStart，改善冷啟動的速度：「New – Accelerate Your Lambda Functions with Lambda SnapStart」。
他拿了一個比較明顯的例子，Java 的 Spring Boot，範例在「Serverless Spring Boot 2 example」這邊，冷啟動的速度可以從 6 秒降到 200ms：
SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.
方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來，之後的冷啟動第一動變成是 restore 而非再 initialize：
With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.
不過不是所有的應用程式都可以直接套用，有些要注意的地方，比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。
比較特別的是亂數產生器需要重新 initialize，不然會有機率產生出一樣的 random data，這個是一般開發者會忽略掉的：
When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.
所以 AWS 有針對 SnapStart 下的 OpenSSL 修正，另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題：
We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.
另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom，這樣就很自然的不會因為 snapshot 而固定，當然也就沒問題：
Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.
這個功能說不用另外收費，看起來對 Java 族群還不錯？
用 3D 印表機修復卡榫故障的 RJ45 接頭
一樣是在 Hacker News Daily 上撈到的，這是一則 2020 就公開的專案，可以用 3D 印表機做出一個小零件，修復卡榫壞掉的 RJ45 接頭：「Ethernet | RJ45 clip to secure/repair/fix broken tab」。
長這樣：
然後用起來是這樣：
不過 comments 裡面有些人有提到，不是每種 RJ45 的頭都符合能用，每家的大小還是不太一樣，真的遇到還是要自己拿回去修修改改，但這個想法還蠻有趣的，用個額外的小玩意幫忙卡住 RJ45 的接口...
同樣的方式馬上可以想到其他類似的接頭 (像是電話線用的 4P4C)，其他的線好像比較沒有這個困擾？可能是 HDMI 跟 DisplayPort 的頭在設計上應該就有考慮到，比較耐操的關係？
用馬鈴薯判斷電極的正負...
在 Hacker News Daily 上看到「“You don't have a voltmeter. Do you have a potato?” (diy.stackexchange.com)」這則討論，原討論在「Is white wire with grey stripes positive or negative wire?」這邊，有人問了一個問題，說手上有一個交流轉直流的變壓器，想要重新接線到下面這種端子，但不確定變壓器輸出的兩條線裡面，正極與負極分別是哪條：
下面的答案很厲害啊，開頭先說如果你沒有伏特計 (像是三用電錶)，那手上有沒有馬鈴薯：
You don't have a voltmeter. Do you have a potato?
把馬鈴薯切半，把 DC 端的兩條線插到同一顆馬鈴薯上面，大約相距 2cm，插電不久後就可以看到有一端會變綠，那端就是正極，把本來插到馬鈴薯上的端子剪掉後再接線就可以了：
With the power adapter unplugged from your electrical outlet, cut the wires, strip a little insulation from the ends, twist the strands of each wire into a point. Do not allow the bare wires to touch each other from this point on.
Cut the potato in half. Take one half, and poke both wires into the cut face of the potato about 2 cm apart. Plug in the power adapter to the wall outlet. In a short time, the potato around one of the wires will turn green. That is the positive wire.
Unplug the adapter and clip off the ends of the wires so you have clean wire for soldering your new plug.
不確定產生的是不是銅綠，但能給出這種解法的確很有娛樂性 XDDD
把所有在 CSS 裡面「有名字」的顏色都呈現出來
前幾天在 Hacker News Daily 上看到「Show HN: A color picker for named web colors (arantius.github.io)」這個作品，把 CSS 裡面有名字的顏色都呈現出來：「Named Colors Wheel」。
移動上去可以看到每個顏色在 CSS 被定義的名稱與色碼，另外從 html code 裡面可以看到他參考了「<named-color>」這份資料。
另外在 Hacker News 上的這則留言也讓我笑的蠻開心的，greenyellow (在黃色 yellow 的左邊) 與 yellowgreen (在 greenyellow 的右上) 的差異：
Also: Finally, a tool to help me decide between greenyellow and yellowgreen.
另外看到這種圖會讓我想到四色定理 (Four color theorem)，不過跟這個主題沒什麼關係就是了...
Tumblr 打算要支援 ActivityPub
Tumblr 現在的老大 Matt Mullenweg 在 Twitter 上提到了 Tumblr 打算要支援 ActivityPub 的消息：
We are mostly dealing with the waves of new users right now and keeping everything scaling but interop and activitypub are ASAP.
— Matt Mullenweg (@photomatt) November 21, 2022
如果支援的話，對於 ActivityPub 這個圈子會是個大消息，等於是有個大平台跳進去支援...
Fred Brooks 過世
在 Hacker News Daily 上看到的消息，Fred Brooks 過世了：
Sad news from @unccs — Fred P. Brooks, the founder and long-time chair of the department (and a major influence on my professional outlook) passed away a few hours ago.
— Steven M. Bellovin (@SteveBellovin) November 18, 2022
Hacker News 上的討論在「Fred Brooks has died (twitter.com/stevebellovin)」這邊可以翻。
Fred Brooks 是 1999 年的 Turing Award 得主：
For landmark contributions to computer architecture, operating systems, and software engineering.
不過在電腦軟體產業裡，用他另外一個被廣為人知的作品來介紹會比較快，軟體工程的經典書籍「人月神話 (The Mythical Man-Month) (MMM)」的作者，從 Hacker News 的討論串裡面也可以看到很多對 MMM 的討論。