Tag: string

在 DOM 操作時的 insertAdjacentElement

看到「Why I'm still using jQuery in 2019」這篇，裡面提到了 jQuery 很多操作上相較於 vanilla javascript 簡單很多，其中一個例子提到了 DOM 操作的 insertAdjacentElement()：

el.insertAdjacentElement('afterend', other) undoubtedly works, but $(el).after(other) is actually palatable.

其實我不知道 insertAdjacentElement() 這個功能，我知道的操作都是透過 parentElement、firstChild 在移動位置，然後用 appendChild() 與 insertBefore() 放進去。

跑去 MDN 上查了「Element.insertAdjacentElement() - Web APIs | MDN」後才發現有這個好用的東西：

targetElement.insertAdjacentElement(position, element);

position 的四個變化減少了以前組積木組多了會頭暈的情況。

接下來是研究支援度的問題，才發現可能是因為 Firefox 一直到 48 才支援 (從「Firefox version history」可以看到 48 是 2016 年八月釋出)，所以網路上大多數的文章都還是用組積木的方式在介紹 DOM 操作，以避免相容性的問題：

Firefox 48 was released on August 2, 2016 for both desktop and Android.

另外還看到 insert​Adjacent​HTML() 與 insert​Adjacent​Text() 可以用，其中讓我注意到 MDN 上面提到 insert​Adjacent​HTML() 居然是 Firefox 8+？本來以為是 48+ 的誤植，但從 Mozilla 的記錄「Implement insertAdjacentHTML」這邊可以看到，應該是在 Firefox 8 的時候實作的，這樣的話可以當作 insertAdjacentElement() 的替代品 (如果考慮到古早的相容性)，只是這邊需要輸入 html string，跟其他操作是是用 element 不太一致...

意外的學到不少歷史故事... @_@

PHP 數字與字串比較的提案

在「Links: February 2019」這邊看到 PHP 社群的提案，想要改善數字與字串比較的結果：「PHP RFC: Saner string to number comparisons」。

他給了一個經典的範例：

$validValues = ["foo", "bar", "baz"];
$value = 0;
var_dump(in_array($value, $validValues));
// bool(true) WTF???

原因是 in_array() 是 == 而非 ===，所以就噴了... 而提案我看了還是覺得不行啊，看看會怎麼改吧 :o

YAML 裡放多行區塊的方式

因為在寫 ansible 的 playbook，有些地方想要偷懶，把檔案放進在 playbook 本身...

網路上搜了一下找到「In YAML, how do I break a string over multiple lines?」這篇，最常用的應該是 |、|- 以及 |+ 了，用這三招塞檔案應該是夠用...

裡面的範例拿 JSON 的格式來解釋還蠻有趣的，代表 JSON 真的很好懂...

Trac 1.1 增加的 time 欄位，以及 Due Date 資料的轉移

Trac 的版本玩法跟早期 Linux Kernel 的模式有點像，也就是版號偶數是正式版，奇數是開發版... 雖然現在 Linux Kernel 已經不玩這套了，但 Trac 還是維持這樣的開發方式。

先前一直都是用 Trac 1.0，其中 Due Date 的功能則是用「DateFieldPlugin」這個套件，讓 Trac 支援 date 格式，於是就可以在 [ticket-custom] 裡面指定 Due Date 了：

due_date = text
due_date.date = true
due_date.date_empty = false
due_date.label = Due Date
due_date.value = <now>

在套件的頁面也有提到在 Trac 1.1.1 後就有內建的方式可以用了：

Notice: This plugin is deprecated in Trac 1.2 and later. Custom fields of type ​time were added in Trac 1.1.1.

連結是連到 1.1 的，我要測 1.2 的，所以往現在的版本翻資料，可以看到在 TracTicketsCustomFields 這邊的說明：(這邊就懶的照原來 html 排了，用 pre 直接放縮排)

time: Date and time picker. (Since 1.1.1.)
    label: Descriptive label.
    value: Default date.
    order: Sort order placement.
    format: One of:
        relative for relative dates.
        date for absolute dates.
        datetime for absolute date and time values.

這樣一來設定就會變成：

due_date = time
due_date.format = date
due_date.label = Due Date
due_date.value = now

但底層資料怎麼存？先看 ticket_custom 這個表格的結構，可以看到是 EAV 的架構：

+--------+------------+------+-----+---------+-------+
| Field  | Type       | Null | Key | Default | Extra |
+--------+------------+------+-----+---------+-------+
| ticket | int(11)    | NO   | PRI | NULL    |       |
| name   | mediumtext | NO   | PRI | NULL    |       |
| value  | mediumtext | YES  |     | NULL    |       |
+--------+------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

隨便拉一些可以看出來放法很簡單：

+--------+----------+------------+
| ticket | name     | value      |
+--------+----------+------------+
|      1 | due_date | 2016-10-03 |
+--------+----------+------------+

改成 Trac 1.2 內建的 time 後，塞 2018/02/28 變成：

+--------+----------+--------------------+
| ticket | name     | value              |
+--------+----------+--------------------+
|      1 | due_date | 001519776000000000 |
+--------+----------+--------------------+

拿掉後面的六個 0 後可以看到就是 2018/02/28 了，要注意的是，這邊會受到時區影響，我一開始測試的時候沒調整，寫進去的時間是用伺服器預設的時區計算的。另外也大概能理解前面放兩個 0 的目的，是為了讓 string 比較時的大小就會是數字實際的大小。

$ date --date=@1519776000
Wed Feb 28 00:00:00 UTC 2018

這樣就知道要怎麼做人工轉換了...

PHP 的 Unquoted Strings 將在 PHP 8 被移除

Twitter 上看到 PHP 的 unquoted string 被視為字串的功能將被移除：「PHP RFC: Deprecate and Remove Bareword (Unquoted) Strings」。

常見的情境是 $_GET[bar] 這樣的用法被視為與 $_GET["bar"] 相同... 超奇怪的功能，而現在這個功能已經投票通過，將會在 7.2 被列為 deprecated，到 8 就會拿掉。

這個功能本來是標示 E_NOTICE，但比較特別的是，雖然是列為 deprecated，PHP 7.2 預定會標示為 E_WARNING 而不是 E_DEPRECATED。主要是這次的兩個目標互相衝突 (可以參考原文)，取比較有效的那個 (因為 PHP 8 就不會有這個問題了，所以 PHP 7.2 的過渡期以比較容易提醒使用者的那個為主)。

投票是 100% 通過 (41/41)。

CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了：「Announcing Query String Whitelisting for Amazon CloudFront」，對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string，或是把整個 query string 當作 cache key 的一部分，現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上，針對 v=\d+ 當作 cache key 的一部分，而其他的參數可以忽略，不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用，像是 Slack 把整個網站放上 CloudFront 後，應該會有很多 API 是透過 query string 傳遞參數，而這次的改變讓 CloudFront 可以細部調整。

MySQL 裡搜尋 CHAR/VARCHAR (String) 欄位時要注意的事情

MySQL 表格欄位是 CHAR 或 VARCHAR 時，寫搜尋條件要記得使用 string 格式，而非數字。意思是，要避免這種 SQL query：

SELECT * FROM foo WHERE `column_string` = 123456;

原因是即使 column_string 加上了 B-tree index，也無法利用這個 index 加速查詢。

原因是，除了最明確的 '123456' 會符合外，還有很多種 case 符合：

mysql> SELECT 123456 = '0123456';
+--------------------+
| 123456 = '0123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT 123456 = ' 123456';
+--------------------+
| 123456 = ' 123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

這使得 index 無用武之地。

但如果欄位本身是數字 (INT/BIGINT)，搜尋時用字串反而沒關係：MySQL 會先把字串轉型為數字再比較，所以會用到 index。

總而言之：

  • 可以用 INT/BIGINT 時，不要用 CHAR/VARCHAR 儲存。
  • 使用 CHAR/VARCHAR 的欄位當搜尋條件時，要用字串形式當作搜尋條件。(除非你很清楚你在做什麼)

今天上場當救援投手時解掉的問題...

關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter，結果剛剛洗澡的時候想了想，好像寫錯了？

問題在於「到底是先 de-null 再 iconv()，還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關，也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character，所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去：

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單，de-null 後沒有 \0 的字串，卻會因為 iconv() 而產生 \0。

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能，因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份)，而 UTF-8 string 內的 \0 一定可以當 separator，所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以？

可能以現在的 iconv() 實做來說，兩者都不會有問題，但寫程式的時候總是要避免 side-effect，所以後者的方法會比前者好。

Google 對字串處理的最佳化

在 Google Research 上看到 Google 針對字串處理最佳化問題所發的論文：「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache，這沒什麼特別的，比較有趣的地方是解決方案，除了自動化的方式外，另外還有工具「提醒」撰寫程式的人，另外還有一些數據以及 code name 可以看...