Home » Computer » Archive by category "Programming" (Page 4)

CPU 成為現代網站的速度瓶頸

在「Tracking CPU with Long Tasks API」這邊提到的現象,雖然是在提新的 API,不過裡面提到了很重要的問題。

以前的網站因為 js 都沒有用的那麼多,所以主要的瓶頸在於網路速度。所以大家最佳化的方向都是往「如何讓傳輸量變小」的方式進行,像是各類 js 的 minify,甚至是對 Gzip 演算法的暴力改善 (維持相容的 Zopfli,以及新的 Brotli):

In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.

而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動),於是對於 CPU 的能力就愈來愈要求:

According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.

而手機也愈來愈普及,CPU 的能力相較起來就更嚴峻了...

新出的 RFC 8259:The JavaScript Object Notation (JSON) Data Interchange Format

JSON 的規格書又被更新了 XD

在「The Last JSON Spec」這邊,Tim Bray 寫了這篇關於新的 RFC 8259 跟之前的差異,以及大家對於雙重標準的顧慮。

最大的差異在於,在 RFC 8259 規定了「如果 JSON 被用在非封閉的系統交換資料,必須使用 UTF-8」:

8259 con­tains one new sen­tence: “JSON text ex­changed be­tween sys­tems that are not part of a closed ecosys­tem MUST be en­cod­ed us­ing UTF-8 [RFC3629].” Giv­en that, by 2017, an at­tempt to ex­change JSON en­cod­ed in any­thing but UTF-8 would be ir­ra­tional, this hard­ly needs say­ing; but its ab­sence felt like an omis­sion.

而關於 ECMA-404 與 RFC 8259 都定義了 JSON 的問題他也說明了,因為很多人花了很多力氣在確保這兩份文件的正確性上,所以應該不會有問題 (i.e. 衝突):

The rea­son 8259 ex­ists is that the ECMAScript gang went and wrote their own ex­treme­ly min­i­mal spec, Stan­dard ECMA-404: The JSON Da­ta In­ter­change Syn­tax, and there was rea­son for con­cern over du­el­ing stan­dard­s. But, af­ter a cer­tain amount of standards-org elephant-gavotte, each of ECMA 404 and RFC 8259 nor­ma­tive­ly ref­er­ences the oth­er and con­tains a com­mit­ment to keep them con­sis­tent in case any er­rors turn up. Which is a good thing, but this text has been re-examined and re-polished so many times that I doubt ei­ther side will ev­er re­vis­it the ter­ri­to­ry, thank good­ness.

另外他也提到了對於不同情境下可以看不同的文件。像是要了解 JSON 的話,可以看當初發明 JSON 的 Doug Crockford 所設立的網站 (在「JSON」這邊);而在交換時應該參考 I-JSON (Internet JSON,RFC 7493):

Which spec should you use? · If you want to un­der­stand JSON syn­tax, you still can’t beat Doug Crockford’s orig­i­nal for­mu­la­tion at JSON.org. If you want to use an RFC as foun­da­tion for a REST API or some oth­er In­ter­net pro­to­col, I ac­tu­al­ly don’t rec­om­mend 8259, I rec­om­mend I-JSON, RFC 7493, which de­scribes ex­act­ly the same syn­tax as all the oth­er specs (by ref­er­enc­ing 7159), but ex­plic­it­ly rules out some legal-but-dumbass things you could do that might break your pro­to­col, for ex­am­ple us­ing any­thing but UTF-8 or hav­ing du­pli­cate mem­ber names in your ob­ject­s.

I-JSON 是 JSON 的子集合,比較重要的:

  • (MUST) 使用 UTF-8。
  • (SHOULD NOT) 浮點數的部份,不得超過 IEEE 754-2008 binary64 (double precision) 的範圍。
  • (SHOULD NOT) 整數的部份,不得超過 [-(2**53)+1, (2**53)-1]) 的範圍。
  • (RECOMMEND) 有超過的需求使用字串表示。
  • (MUST NOT) JSON object 內不得有重複的 name。
  • (SHOULD NOT) 最上層的型態不得使用字串,只能使用 object 或是 array。
  • (MUST NOT) 遇到先前沒有定義過的元素不得視為錯誤。(像是新版 API 內會在 object 裡增加元素)
  • (RECOMMEND) 時間使用 ISO 8601 表示 (在 RFC 3339 有提到),英文字的部份全部使用大寫,一定要標上時區,而秒數的 0 一定要加上去 (也就是 00 秒)。
  • (RECOMMEND) 時間長度也建議依照 RFC 3339 處理。
  • (RECOMMEND) Binary 資料用 base64url 傳 (RFC 4648)。

微軟在考慮讓 Excel 支援 Python...

在「Excel team considering Python as scripting language: asking for feedback」這邊看到微軟正在考慮要不要讓 Excel 支援 Python,出自 UserVoice 上的:「How can we improve Excel for Windows (Desktop Application)?」。

比較感覺到有可能性應該是因為微軟做了一個問卷收集資訊:「Python and Excel」。

不過本來的功能就已經可以用到很出神入化了... XD (想到最近提到的「LINE 將內部的座位表由 Excel 改成 Web 界面...」)

Amazon Aurora (MySQL) 的 Stored Procedure 可以跑 AWS Lambda...

查了資料才發現去年十月 Amazon Aurora (MySQL-Compatible Edition) 就支援用 AWS Lambda 當 stored procedure 了,只是當時只支援 async mode,能做的事情比較有限:「Amazon Aurora New Features: AWS Lambda Integration and Data Load from Amazon S3 to Aurora Tables」。

Now you can invoke Lambda functions directly from within an Aurora database via stored procedures or user-defined functions. Lambda integration allows you to extend the capabilities of the database and invoke external applications to act upon data changes. For example, you can create a Lambda function that sends emails to customers whenever their address in the database is updated.

前幾天發表的則是支援 sync mode,可以等到:「Amazon Aurora with MySQL Compatibility Natively Supports Synchronous Invocation of AWS Lambda Functions」。

Starting with version 1.16, we are extending this feature to be able to able to synchronously invoke Lambda functions.

Use the native function lambda_sync when you must know the result of the execution before moving on to another action.

這解掉了 MySQL 的 stored procedure 一直很殘的問題...

AWS CodeBuild 也可以產生 Badge 給網頁用 (像是掛在 GitHub 的 README 裡)

在「Build Badges Sample with AWS CodeBuild」這邊看到 AWS CodeBuild 支援 Badge 的方法。最常用的 GitHub 是給 AWS CodeBuild 授權後取得:

If you chose GitHub, follow the instructions to connect (or reconnect) with GitHub. On the GitHub Authorize application page, for Organization access, choose Request access next to each repository you want AWS CodeBuild to be able to access. After you choose Authorize application, back in the AWS CodeBuild console, for Repository, choose the name of the repository that contains the source code. Select the Build Badge check box to make your project's build status visible and embeddable.


  • PASSING The most recent build on the given branch passed.
  • FAILING The most recent build on the given branch timed out, failed, faulted, or was stopped.
  • IN_PROGRESS The most recent build on the given branch is in progress.
  • UNKNOWN The project has not yet run a build for the given branch or at all. Also, the build badges feature might
    have been disabled.

不過我還是偏愛 3rd party 的組合,不是很愛用 AWS CodeXXX 系列的服務就是了... 唯一一個用的是 AWS CodeCommit 因為有永久的免費額度可以用。

Googlebot 的 Web rendering service 的細節

在「Polymer 2 and Googlebot」這邊文章裡面才看到 Google 官方在今年八月就有公開 Googlebot 所使用的 Web rendering service (WRS) 的細節:「Rendering on Google Search」。可以想像到是基於 Google Chrome 的修改:

Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.

裡面提到一些值得注意的事情,像是不支援 WebSocket,所以對於考慮 Google 搜尋結果的頁面來說,就要注意錯誤處理了...


Disclosure:我跑去找作者簽名,然後被戳說要介紹廣告一下 XDDD

這是本講 Git 的書,翻內容後的感覺... 定位差不多在入門使用者與中階使用者。先引用作者在 Twitter 的 tweet:

天瓏掛第一,然後出版社通知要二刷了,應該是賣的還不錯 XDDD

書的章節可以參考「天瓏網路書店-為你自己學Git」這邊,內容是以 Command Line 為主,對於真的要把 Git 用好蠻有幫助的。除此之外,實務上常見的問題都有提到 (像是搞爛東西後可能的解法),也講了不少冷知識,對於理解 Git 內怎麼運作會有幫助...

唯一覺得奇怪的地方應該是在最後兩章,講 GitHub 與 Git Flow (也就是「A successful Git branching model」這邊提出來的方法),反而不是 GitHub Flow... 雖然在 GitHub 上也可以走 Git Flow 啦。

用 Makefile 跑測試的 Makefile.test

Box 放出來的東西,用 Makefile 跑各種測試:「Introducing Makefile.test: A Generic Makefile to Run Test Executables」,專案在 GitHub 上的 box/Makefile.test

Makefile.test can be used to run any type of test executables. It is not language specific nor it requires any changes to your code. Parallel, serial execution, various platforms and make versions are supported. The executables can be organized in any desired way. The user only lists the test files, the rest is taken care of Makefile.test.

程式碼很短,看程式碼其實比看說明容易理解:「Makefile.test」。看完後感覺沒有很實用... 就當作趣味看一看 XD

AWS Lambda 可使用的記憶體空間從 1.5GB 變成 3GB

AWS 是說 AWS Lambda 可用的記憶體空間 double 啦,不過 3008MB 這個數字有點怪...:「AWS Lambda Doubles Maximum Memory Capacity for Lambda Functions」。

You can now allocate 3008MB of memory to your AWS Lambda functions. Previously, the maximum amount of memory available to your functions was 1536MB. Now, it's easier to process workloads with higher memory or denser compute requirements, such as big data analysis, large file processing, and statistical computations.

這個就真的全區都生效了,包括一般人不能註冊的 AWS GovCloud (US) 與中國區:

This feature is available in US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), AWS GovCloud (US), Canada (Central), South America (São Paulo), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and China (Beijing).