Tag: object

gron：把 JSON 結構轉成條列式的資料，方便後續的文字處理...

在「gron makes JSON more greppable」這邊看到 gron 這個工具，可以將 JSON 轉成條列式的資料 (或是反過來，將條列式的資料轉回 JSON)。

像是網站上給的範例之一：

▶ gron testdata/two.json 
json = {};
json.contact = {};
json.contact.email = "mail@tomnomnom.com";
json.contact.twitter = "@TomNomNom";
json.github = "https://github.com/tomnomnom/";
json.likes = [];
json.likes[0] = "code";
json.likes[1] = "cheese";
json.likes[2] = "meat";
json.name = "Tom";

這讓 grep 或是 sed 之類的工具會更好操作，不然得用 jq 盧半天...

JSON 的 Object 裡 Key 重複的問題

tl;dr：不要亂來啦... 這是 UB (Undefined behavior) 的一種。

因為看到這則 tweet，所以去查一下 JSON 的資料：

首先是找標準是什麼。在維基百科的 JSON 條目裡提到了有兩份標準，一份是 RFC 7159，一份是 ECMA-404：

Douglas Crockford originally specified the JSON format in the early 2000s; two competing standards, RFC 7159 and ECMA-404, defined it in 2013. The ECMA standard describes only the allowed syntax, whereas the RFC covers some security and interoperability considerations.

ECMA-404 裡面就真的只講語法沒講其他東西，而在 RFC 7159 內的 Object 則是有提到 (重點我就用粗體標起來了)：

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

   object = begin-object [ member *( value-separator member ) ]
            end-object

   member = string name-separator value

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

粗體有描述唯一性，但尷尬的地方在於他用 SHOULD 而非 MUST，所以 library 理論上都要能接受。但後面提到如果不唯一時，行為無法預測 (會到 rm -rf / 嗎？XDDD 最像的應該還是 crash？)，所以還是不要亂來啦...

不過如果真的會 crash 的話，應該也會因為 DoS issue 而被發 CVE，所以實務上應該是不會 crash 啦...

PHP 7.3 的 json_decode() 將會用 Exception 處理錯誤

在「PHP: rfc:json_throw_on_error」這邊提到 PHP 7.3 會解決 json_decode() 發生錯誤時的處理方式：

PHP has two functions for dealing with JSON, json_decode() and json_encode(). Unfortunately, both have suboptimal error handling. json_decode() returns null upon erroring, but null is also a possible valid result (if decoding the JSON “null”).

在這之前唯一的判斷方式是另外再呼叫 json_last_error() 或是 json_last_error_msg()，但這樣寫很辛苦，所以要引入 JsonException 了，總算...

有 Lazy Connection 功能的 PDO object

在「Aura.Sql」這邊看到有提供 Lazy Connection 的 PDO object，而且是繼承自本來的 PDO object：

Provides an extension to the native PDO along with a profiler and connection locator. Because ExtendedPdo is an extension of the native PDO, code already using the native PDO or typehinted to the native PDO can use ExtendedPdo without any changes.

Lazy connection. ExtendedPdo connects to the database only on method calls that require a connection. This means you can create an instance and not incur the cost of a connection if you never make a query.

之後可以拿來跟 Laravel 的 Eloquent 一起用看看。本來的 PDO 物件在建立時就會建立連線，對於連線的開銷其實蠻大的，用這個應該是個方向...

另外是 Profiler 的能力，需要用的時候應該會很好用：

Profiler. An optional query profiler is provided, along with an interface for other implementations, that logs to any PSR-3 interface.

引一下來源，當初是從「Atlas.Orm 2.0 Is Now Stable」這邊在看文件時一路看到的。

DigitalOcean 也開始推出 Object Storage

DigitalOcean 也推出了 Object Storage：「Introducing Object Storage」。

不過價錢沒有先公佈啊... 這年頭這種東西沒有比 Amazon S3 便宜，或是有特殊功能的話，也別進來玩了。

以 DigitalOcean 最近的動作來看，還是先放置好了，等價錢出來再來決定要怎麼做 XDDD

AWS Storage Gateway 的新功能：File Gateway

AWS Storage Gateway 推出新功能 File Gateway：「File Interface to AWS Storage Gateway」。

可以讓使用者在前面用 NFS，後面實際接的是 Amazon S3：

After you set it up in your data center or in the cloud, your configured buckets will be available as NFS mount points. Your application simply reads and writes files and directories over NFS; behind the scenes, the gateway turns these operations into object-level requests on your S3 buckets, where they are accessible natively (one S3 object per file).

以前自己用 FUSE 惡搞的方式，現在變成官方支援的功能？XDDD

Amazon S3 的改善

其實老牌的 Amazon S3 也改了不少東西：「Revolutionizing S3 Storage Management with 4 new features」。

其中的「S3 Object Tagging」讓管理可以透過 tag 處理，管理上會多一些選擇。而「S3 Analytics, Storage Class Analysis」則是可以分析存取的 pattern，藉此重新規劃 policy。

看到之前的同事說 CloudFront 要支援 2-tier cache，但卻還沒看到公告，不知道是怎麼樣的實作方式... 這對大型的 live streaming 幫助很大啊，後面的壓力會小很多。

Facebook 上貼的所有的連結都是公開的

tl;dr：Facebook 認為這個功能是 feature，不是 bug。

在「Why you shouldn’t share links on Facebook」這邊作者發現在 Facebook 上貼的「任何一個連結」都會產生 object id，而任何一個 object id 都可以直接取得 url，無論權限設定，像是這樣：

而 Facebook 認定這是 feature 而非 bug：

可以想像 NSA 之類的單位與地下組織開始狂掃...

Amazon S3 的改善

在「Amazon S3 Introduces New Usability Enhancements」這邊提到了 Amazon S3 的兩個改善。

第一個是業務面的改善，以前應該是開 support ticket 請人調整 S3 bucket 數量上限，現在則是可以直接透過界面申請？(沒有遇過瓶頸，不知道以前是不是在界面上看不到...)

第二個才是重頭戲：Read-after-write Consistency。

With this enhancement, Amazon S3 now supports read-after-write consistency in all regions for new objects added to Amazon S3.

也就是說，Amazon S3 現在保證「新增的 object」「可以在建立後馬上被讀取」。之前還沒修正前，這個問題有多嚴重呢？可以看 2014 年時「Netflix 對 S3 的 Eventually Consistency 的補強...」這邊 Netflix 在跑 Pig 與 Hive 遇到的問題。

Netflix 這邊舉的例子是兩個 Pig cluster 在跑，其中 Pig-2 需要 Pig-1 跑出來的資料，在這次公告前，如果 Pig-1 的資料寫回 Amazon S3 時不會馬上出現，那麼 Pig-2 就會拿不完整的資料執行：

Pig-2 is activated based on the completion of Pig-1 and immediately lists the output directories of the previous task. If the S3 listing is incomplete when the second job starts, it will proceed with incomplete data.

而現在總算是保證新的 object 可以馬上被讀取，所以 Netflix 可以利用一個檔案列出所有的 filename，確保知道所有的檔案名稱... (LIST 指令還是 eventually consistent，所以這部份還是要自己處理)