給定一個 array：
$list = [
'200' => 'OK',
'404' => 'not found',
'500' => 'internal server error',
];使用 array_keys() 取得 keys 以後，key 的資料型態若可以被轉為 int 則會被自動轉換：
$keys = array_keys($list);
// array(3) {
// [0]=>
// int(200)
// [1]=>
// int(404)
// [2]=>
// int(500)
// }由文件中可以看到，透過第三個參數「$strict」可以要求保留原始資料型態，但無法避開第二個參數「$search_value」。所以第三個參數基本上是放好看的 (WTF)
如果要處理的資料是比較敏感的，建議在 key 前面加個 prefix，或是取得 keys 以後再手動轉換資料型態。
剛接觸的應該會被命名搞的一頭誤水，畢竟名字相同、不然就是幾乎相同 XD
負責提供記憶體讀寫快取的服務叫做 Memcached，這個服務和 PHP 八竿子打不著關係，就算你不是寫 PHP 也這樣可以使用他。
再來要說的是 PHP 底下的二個函式庫：Memcache 和 Memcached。這二個函式庫，主要是提供一個方法讓 PHP 連接前面提到的 Memcached 讀寫資料。另外要注意的是 Memcache 和 Memcached 函式庫雖然名字很接近，但卻是二個完全不同的函式庫，無法同時使用，只能二選一。
以下透過 psysh 實際操作，來看一下同時使用會發什麼事情。
使用 Memcache 寫入一筆資料：
>>> $m = new Memcache
=> Memcache {#201}
>>> $m->connect('localhost')
=> true
>>> $m->set('test', ['Hello', 'World'])
=> true
>>> $m->get('test')
=> [
"Hello",
"World",
]
再來使用 Memcahed 函式庫，連到 localhost 的 Memcached server 看看會發生什麼事：
>>> $d = new Memcached
=> Memcached {#198}
>>> $d->addServer('localhost', 11211)
=> true
>>> $d->getAllKeys()
=> [
"test",
]
>>> $d->get('test')
=> 0可以看出這二個函式庫提供的 methods 看起來很接近，但是底層處理資料的方式不一樣，只能挑其中一個來使用。
或許這個消息有點 lag，但 Blogger 終於讓自訂網址的使用者可以使用 HTTPS 了。
到管理頁面中點選「設定」=>「基本」，就可以看到 HTTPS 啟用選項：
啟用以後，網站大概會中斷約 10 ~ 20 分鐘，恢復正常以後就會發現可以使用 HTTPS 連線了。
可能有人好奇 HTTPS 憑證到底怎麼生出來的？可以透過瀏覽器的開發人員工具看一下憑證內容：
其實是 Blogger 自己跑去向 Let’s Encrypt 跑認證流程申請的 XD
在 Blogger 開始使用 HTTPS 以後，若編輯器發現網頁中的連結、圖片仍有使用 HTTP (無加密) 協定時會發出警告，我這邊是把 AWS s3 的圖床中間再多加一層 Cloudfront 走 HTTPS，目前看起來費用沒有增加多少 (敝站也沒多少流量就是了)。
再找時間把 Cloudfront 的設定方式整理出來，比想像中的簡單。
前幾天在做 aptitude upgrade 時，系統噴儲存空間不夠的錯誤訊息，用 df 追了一下，發現是 inode 被吃光，網路上找了一下統計 inode 使用量的 script 來掃整個分割區：
find / -type d -print0 | xargs -0 -n1 count_files | sort -n
...
1794 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/app/assets/images/emoji
1794 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/public/assets/emoji
1794 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/png
1794 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/svg
1794 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/app/assets/images/emoji
1794 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/public/assets/emoji
1794 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/png
1794 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/svg
1794 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/app/assets/images/emoji
1794 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/public/assets/emoji
1794 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/png
1794 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/gemojione-3.0.1/assets/svg
1966 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/public/assets
1966 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/public/assets
1971 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/public/assets
2271 ./var/lib/docker/image/aufs/distribution/diffid-by-digest/sha256
2271 ./var/lib/docker/image/aufs/distribution/v2metadata-by-diffid/sha256
3291 ./var/lib/dpkg/info
4025 ./var/lib/docker/aufs/diff/fcfbf2f22b171407b0a9d657131c0c4b55aadd50c49a26abfc40cd404ab02298/home/git/gitlab/tmp/cache/assets/sprockets/v3.0
4029 ./var/lib/docker/aufs/diff/04d42c6fb6b72464ab397cc0cd67d8600f7bc0964ff7c9bb54392ec3eb53a13e/home/git/gitlab/tmp/cache/assets/sprockets/v3.0
4029 ./var/lib/docker/aufs/diff/bb44ab5db5ec7f5e3fe0bde806002e887cf11cf9aa598ce0453083f80fc10ff9/home/git/gitlab/tmp/cache/assets/sprockets/v3.0看起來兇手是 docker，而且吃掉的量還不小。
查了一下資料，其實是自己在刪除 images 和 volumes 時有漏參數，導致有檔案沒有被清乾淨，inode 被吃光沒有回收回來。參考這篇「Docker、AUFS、inode耗尽和一个小工具」整理，可以透過以下 script 把無用的檔案清空：
docker images -qf dangling=true | xargs docker rmi
docker volume ls -qf dangling=true |xargs docker volume rm這二個 script 跑完以後，我的 inode usage 從 99% 瞬間降到 17%，看來以後真的要小心。
其他參考資料：
在 Hacker News 看到一篇文章「2018 Developer Skills Report」，裡面列出一些程式設計師的特質，還蠻有趣的，這裡大概列出幾個有趣的點：