顯示具有 資訊學習 標籤的文章。 顯示所有文章
顯示具有 資訊學習 標籤的文章。 顯示所有文章

2018/11/06

「耐心的溝通絕對比鬥爭更好」

雨蒼的 Medium 看到的文章「我們該如何反思並使黑客文化更好?從Linus變得有禮貌開始說起」:
推廣理念,耐心的溝通絕對比鬥爭更好,也更能爭取到支持與理解。

有衝突 (conflict) 表示有不同的意見、不同的解決方案,有多個不同的解決方案是好事,但並不是每個方案都適合鎖情況。魚與熊掌不可兼得,只能找到當下較為適合的方案來使用,所以需要溝通、討論,了解每種方案的優缺點。

2018/09/17

HiNet 宣佈年底關閉 Proxy 服務

看到 Hinet 宣佈 2018 年底中止 Proxy 服務,另外看到 gslin 的文章說「網站都走 HTTPS 的情況下,Proxy 服務能帶來的好處愈來愈少了」,當下想不出來為什麼。

查了一下資料恍然大悟。HTTPS 主要目的就是希望所有的網路資料傳輸不會被中間人 (MITM) 竊聽,當然這個和 proxy 的目的剛好互斥,proxy 的行為就是做中間人並協助將常用檔案儲存起來讓你下次使用時可以快速取得。所以走 HTTPS 的話資料是不會進 proxy 做快取的。

ref:

2018/09/04

防止搜尋引擎顯示敏感資訊

Google 搜尋引擎提供了強大的功能,讓使用者可以快速的找到需要的資料。所有事物都有雙面刃的特性,也因此有人使用他來做惡意行為,像是搜尋個人隱私資訊、帳號密碼、網站架構、特定檔案等。

圖一:透過關鍵字和「filetype」搜尋到的聯絡人資訊




圖二:Google 也可找到一些可下載的檔案


早在 10 年前,我就使用這些搜尋技巧在網路上搜尋可用的電子書以及其他資料,只是已意外的到現在還有這麼多網站有安全問題。



透過 robots.txt 告知搜尋引擎不要建立索引


搜尋引擎除了造訪各個網頁,並儲存網頁內容以外,會先參考網站根目錄的「robots.txt」檔案,此檔案主要目的是告訴搜尋引擎哪一些路徑不應該被建立索引、不該被搜尋:

通常會設定為:
User-agent: *
Allow: /
Disallow: /upload/
Disallow: /download/
Disallow: /file/

但要注意:並不是所有搜尋引擎都會按照你預期的方式處理。

同樣的,由於雙面刃的特性,當惡意使用者發現 robots.txt 中有「Disallow」的項目,就可以猜得到這些目錄有敏感資料,進而特別去分析這些目錄的用途。


目錄加上 HTTP basic auth


這個作法很簡單,搜尋引擎造訪網頁時沒有帳號、密碼,無法讀取資料,也就沒辦法對網頁內容建立索引供使用者搜尋。



透過防火牆阻擋擋搜尋引擎


若有注意的話,你可以在 HTTP server log 中看到 user agent 的資訊,例如:
 .... Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

順著 user agent 的提示,你應該會發現多數的搜尋引擎 bot 都會有關鍵字,且有些搜尋引擎服務甚至會告知 bot 所使用的 IP。透過這些設定,設定防火牆或其存取規則,來阻擋搜尋引擎讀取特定網頁。

ps. 十多年前,百度的 bot 會在一秒內同時送出數十個 HTTP request 來檢索網頁,導致機器被DoS。後來不爽把所有中國網段全部用防火牆給擋了 ... Orz

2018/08/31

電腦字型的授權範圍

近日有 YouTuber 被告知不可隨意使用特定字型,否則會發法律上的問題。

看到法操 FOLLAW 整理了與電腦字型有關的法律規範出來,做個筆記。

以下節錄自「用新細明體和標楷體做影片字幕一定會構成侵害嗎?」:
我國著作權法在民國81年修正前,當時規範著作物類型的第3條並未將字型納入著作權的保障範圍。但隨著字型的議題受到重視,在民國81年修正著作權法時,將著作物類型移列第5條,並由行政機關針對各個類型的範圍另以命令規定。

因此,行政機關依據上述條文的授權,訂立並公告了《著作權法第五條第一項各款著作內容例示》,來明確說明第5條各著作物的詳細內容。而在該例示中,行政機關順應當時的需求,將「字型繪畫」納入了「美術著作」的範圍。


個人認為,目前法律好像還沒跟上資訊發展的速度,因此有一些模糊地帶、也可能造成一些糾紛。

已有其他網友整理出目前常用字型的使用法律授權:YouTuber 合法使用中文字型的管道有哪些?。有需要時可供參考。


Reference

2018/08/07

讓 dehydrated 遇到錯誤仍繼續執行

發現手上一個 domain 的 HTTP cert 過期沒被更新到,但 dehydrated 理應會自動檢查到過期的憑證才對:
/etc/nginx/cert/dehydrated -c > /dev/null 2>&1; service nginx reload

手動執行 dehydrated 以後,發現有個 domain 已經被我刪除,而 dehydrated 遇到這個錯誤以後就會中斷執行,也因此後面幾個 domain 都沒有被檢查。

翻了文件,加上「--keep-going」參數,即可讓 dehydrated 遇到錯誤繼續往下走。

2018/07/30

PHP array_keys() 會自動轉換資料型態

給定一個 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 以後再手動轉換資料型態。

2018/06/14

PHP 的 Memcache 與 Memcached 函式庫無法共用資料

剛接觸的應該會被命名搞的一頭誤水,畢竟名字相同、不然就是幾乎相同 XD

負責提供記憶體讀寫快取的服務叫做 Memcached,這個服務和 PHP 八竿子打不著關係,就算你不是寫 PHP 也這樣可以使用他。

再來要說的是 PHP 底下的二個函式庫:MemcacheMemcached。這二個函式庫,主要是提供一個方法讓 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 看起來很接近,但是底層處理資料的方式不一樣,只能挑其中一個來使用。

2018/04/29

Blogger (終於) 支援自訂網址使用 HTTPS

或許這個消息有點 lag,但 Blogger 終於讓自訂網址的使用者可以使用 HTTPS 了。

到管理頁面中點選「設定」=>「基本」,就可以看到 HTTPS 啟用選項:



啟用以後,網站大概會中斷約 10 ~ 20 分鐘,恢復正常以後就會發現可以使用 HTTPS 連線了。


可能有人好奇 HTTPS 憑證到底怎麼生出來的?可以透過瀏覽器的開發人員工具看一下憑證內容:


其實是 Blogger 自己跑去向 Let's Encrypt 跑認證流程申請的  XD


在 Blogger 開始使用 HTTPS 以後,若編輯器發現網頁中的連結、圖片仍有使用 HTTP (無加密) 協定時會發出警告,我這邊是把 AWS s3 的圖床中間再多加一層 Cloudfront 走 HTTPS,目前看起來費用沒有增加多少 (敝站也沒多少流量就是了)。

再找時間把 Cloudfront 的設定方式整理出來,比想像中的簡單。

2018/02/22

docker aufs 把 inode 吃光的問題

前幾天在做 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%,看來以後真的要小心。


其他參考資料:

2018/01/26

2018 年開發人員的技能整理

Hacker News 看到一篇文章「2018 Developer Skills Report」,裡面列出一些程式設計師的特質,還蠻有趣的,這裡大概列出幾個有趣的點:

  • 有超過四分之一的人在 16 歲左右就開始接觸程式設計,但有 36% 的人在 26 歲才開始學習程式設計,而且現在是資深工程師。所以學寫程式不嫌晚、也不嫌早。
  • 幾乎左有的開發者都求知若渴,大多都學了 3 種或以上的程式語言
  • 自修的人比在學校上課的比例還稍微多了一些
  • 年輕人傾向從網路媒體取技術知識 (像是 StackOverflow、YouTube)
  • 幾乎所有人都把問題解決能力擺在最前面
  • 在工作與生活間取得平衡的方法:彈性的工時、遠端作業、注重產出而非工時 (這些台灣公司好像很少有聽過)

2017/11/21

IBM DNS 9.9.9.9 測試

看到新聞:「IBM宣布推出免費DNS轉址服務 Quad9,只要將DNS伺服器設為9.9.9.9 即可阻擋惡意網站」,聽起來頗有趣的,所以玩了一下。



我這邊比較偏重 DNS 回應速度,自家機器在中華電信的線路上,先用 168.95.1.1 來看回應速度:
johnroyer@box:~$ ping -c 5 168.95.1.1
PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data.
64 bytes from 168.95.1.1: icmp_seq=1 ttl=247 time=11.5 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=247 time=11.8 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=247 time=11.9 ms
64 bytes from 168.95.1.1: icmp_seq=4 ttl=247 time=10.5 ms
64 bytes from 168.95.1.1: icmp_seq=5 ttl=247 time=10.3 ms
--- 168.95.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 10.377/11.248/11.921/0.664 ms

2017/11/10

函式中參數順序的設計

最近在 refactor legacy code,遇到很尷尬的函式定義,笑也不是哭也不是。

函式會要求使用者傳入多個參數,有時並不是所有的參數都必須給值,函式的設計者會以大家較常使用的方式來當作參數的預設值,例如 PHP 裡面的「json_decode()」:
json_decode($json);  // consider as json_decode($json, false)

json_decode($json, true);  // 不使用預設值才手動傳數第二個參數


但這次遇到比較尷尬的是,legacy code 把第一個參數設計為 optional,也就是有預設值。但問題來了,在 PHP 的語法當中,呼叫函式無法在前幾個參數不給值:
getData( , 'some', 'option');  // syntax error

所以不管怎麼樣,都至少要給第一個參數:
getData(null, 'some', 'option');

所以把有預設值的參數放在前面其實根本沒有省下什麼時間呀 ... XD

2017/10/20

讓 MySQL 在查詢時區分英文大小寫

今天又遇到相同的問題,解法有很多種,可以從 SQL 下手,也可以在 table schema 就先做好設定。


SQL 強制區分大小寫


假設原本的 SQL 為:
SELECT * FROM users WHERE name = 'john' ;

這樣會撈出「John」、「john」等結果。那麼可以要求 MySQL 使用 binary 的辨識方法去做搜尋:
SELECT * FROM users WHERE binary name = 'johhn';

這樣一來,查詢時 name 欄位就會區分大小寫來做查詢。



修改 table schema


如果在設計 table 時,就確定查詢一定要區分大小寫時,可以在 create table 就先將欄位設定好:
CREATE TABLE users (
    name varchar(100) binary
)

這樣之後下 query 時,只要遇到 name 欄位,就自動會區分大小寫。



修改 collation type


一般常用的 collation 是「utf8_general_ci」,該 collation 最後面的「ci」其實是「Case Insensitive」的意思,也就是不區分大小寫。

如果要讓該 table 的所有欄位都區分大小寫,可以將 collation 的 postfix 改為「cs」或是「bin」,例如:
CREATE TABLE user (
    name varchar(100)
) COLLATE utf8_general_bin ;



以上三個區分大小寫的方法 scope 差異頗大的,可以挑比較適合當下情況的方法來使用。

2017/10/17

WPA2 金鑰交換協議問題導致的安全漏洞

T 客邦看到「破功確認!KRACK破解 WPA2 原理已公開,你家的無線路由器還安全嗎?」,是在於 wifi 路由器和 client 做金鑰交換時,原本擔心擔心環境中的訊號傳遞不好,所以在金鑰交換協議上制定在雙方都沒有確認金鑰交換成功時,可以再次跑一次金鑰交換的流程。

比較尷尬的是,這份金鑰交換的協議並沒有制定怎麼樣才算交換成功,而中止流程。所以駭客只要發出金鑰交換的訊號,client 以為要再次跑流程時就會中招。

看起來目前的解決方法,就是先降低 wifi 訊號強度,讓只有 wifi client 所在環境才收的到訊號,讓偽造的金鑰交換訊號沒辦法進入 wifi 使用環境範圍內。再來就是等 wifi 的通訊協定更新了。

gslin 這邊提到,走 wifi 最安全的方法還是用 VPN。總之,電磁波是任何人都可以收到的,有無線網路至少、至少都要使用有 HTTPS 的加密通訊。

2017/10/11

建立供行動裝置使用的網頁瀏覽界面

最近用手機追新聞有感,分享一下心得。

由於行動裝置的使用量漸漸超越了桌上型電腦,而行動裝置為了攜帶方便體積本身就小,連帶的螢幕也較桌上型電腦小很多,因此不少網路服務也跟著建立行動裝置專用的網頁,像是自由時報就有針對行動裝置客製化網頁:




有留意的話可以發現行動版網頁的網址和供一般電腦瀏覽的網址是不一樣的,如了全幅廣告不說,網頁寬度、排版方式都看電腦版不同。

這時如果覺得文章不錯,透過行動裝置分享道社交平台上,別人如果是使用電腦開啟時,則會出現這樣的畫面:


別人就會變成使用超大螢幕來看超小版面的新聞,而且還有全幅蓋版廣告喔 XD

如果有 sense 一點的人,可能會想試著把網址「http://m.ltn.com.tw」改成「http://www.ltn.com.tw」嘗試開啟一般網頁版來閱讀,可惜自由時報沒有這個設計,改完網址只會顯示 404 找不到網頁 (但蘋果日報將網址改為 www 開頭以後是可以正常瀏覽的,這個設計頗為貼心)。

那什麼樣的設計才能同時滿足行動裝置以及一般電腦呢?可以參考 Wikipedia

Wikipedia 使用 Responsive Web Design (RWD) 來讓瀏覽器自動判斷裝置、螢幕大小,並自動更換成適合閱讀的版面。即使網址相同,在不同裝置上可以呈現不同的畫面,讓使用者方便閱讀。

只是一自己的經驗,要設計一個讓不同行動裝置都可以正常瀏覽、顯示符合需求的 CSS,費工又費時,就看業者到底想要給使用者什麼樣的體驗了。

2017/10/09

PHP curl 的一些特性

curl 在 PHP 中是以 extension 形式存在,所以只能透過 resource reference 去操作 curl 行為,沒辦法透過 debug 工具摸清楚 curl 在背景到底做了哪些事情。

手癢用 memory_get_usage() 看了一下 curl 在 init、exec 以及 close 這幾個狀態的記憶體使用量,來猜測 curl 到底怎麼運作。

echo memory_get_usage() . "\n"   // 236136;

$ch = curl_init();
var_dump($ch);                   // resource(4) of type (curl)
echo memory_get_usage() . "\n";  // 237472

在 init_curl() 以後,會先在記憶體中 allocate 並放一些資料,所以吃掉大概 1 KB 左右的記憶體,再將 curl 的 reference 傳出來給 $ch。

2017/10/03

使用 VCS 時程式中不應該出現的東西

這件事情應該要從 FreeBSD 6 左右的 make build world && make install world 開始說起。每次 build world 以後,新版的 tool chain 設定檔可能都會有小部份的更新,可能是多幾個功能可以設定,或是把一些舊的功能拔掉,這時 install world 時為了擔心使用者改過的 config 檔直接被覆蓋掉,都會先做一次 diff 讓使用者確定設定檔更新以後不後搞垮系統。但有半數以上的 diff,均為 config 中開發人員的註解,像是「2005/xx/xx 最後更新」之類的,單單處理這類的 diff 就可以耗掉數十分鐘。

現在大家在寫程式時,應該都有習慣將 source code 放進 version control system (VCS) 中,方便做版本管理以及除錯。VCS 除了能夠協助開發者幫不同的修改留下記錄以外,也支援版本之間的比較、建立補丁 (patch) 等功能,讓開發者可以專心在功能的開發上。

既然 VCS 已經協助開發者記錄了這麼多東西,那有哪些是開發者已經不需要寫在 source code 裡面的呢?

  • 日期:大多數的 VCS 在開發者 commit 時就會記錄日期,開發者有修改時不必特別在程式中註解修改日期,只要 commit 時將 commit message 寫好讓其他人看得到、搜尋的到即可。
  • 作者:每個開發人員在 VCS 都會被視為不同的 commitor,所以哪個 commit 是誰送、甚至哪一行是誰修改的都有記錄。把修改原因寫清楚比較重要。
  • 註解掉不使用的程式碼:因為 VCS 會保留從古到今所有的程式碼異動,所以大可不用擔心程式碼刪除以後無法還原,若發現某一段程式已經不再使用了,就放心的把他刪掉吧,萬一誤砍了還是可以透過 VCS 復原回來。(如果 VCS 做不到這個功能就換一個吧 XD)
  • 與專案無關的 binary:大多數 icons、font、design files 都會與專案的版本一起演進,放進 VCS 是應該的。但與專案週期不同、或為一次性用途的 binary 檔案,如週年慶的活動圖片設計、影片等,就不適合放進 VCS,若真的有版本管理需要,應該另外開一個 repository。
  • symbolic link:恩 .... 有事嗎?

2017/09/26

各家手機的 I/O 性能測試

以前一直以為是自己買的 MicroSD 卡不夠強,所以讀取、寫入都很慢,經過幾個朋友一起測試以後,才知道其實瓶頸根本不是在記憶卡,而是手機內建的硬體支援有些原本就很低。

以下的結果均是使用 A1 SD Bench 測試以後的結果,先來貼一下我自己正在使用的 Sony 系列測試。

Sony


Sony Xperia XZ:SD 卡的寫入速度只有 30 MB/s,不是你的 SD 卡不夠好

2017/09/12

使用 datastax/php-driver 對 Cassandra 做 query 需要留意的地方

最近在研究如何把 log 塞到 Cassandra 中,使用的 Datastax 的 php-driver 輕鬆很多,但還是有一些需要留意的地方,免得莫名其妙鬼打牆。

這邊先假設我要記錄一個使用者上傳檔案的記錄,包含 ID、檔案名稱、檔案大小以及上傳日期,建立了一個 table:
CREATE TABLE hermes_log.file (
    id uuid,
    name text,
    size decimal,
    create_time timestamp,
    PRIMARY KEY (id, name, size, create_time)
)

這個時候使用 PHP 塞資料進入,直接建立 CQL 且不使用 prepare/binding,可以成功執行 insertion:
<?php

$cluster = Cassandra::cluster()->build();
$session = $cluster->connect();
$cql = "
    insert into hermes_log.file
    (
        id,
        name,
        size,
        create_time
    ) values (
        uuid(),
        'gavatar.jpg',
        123.4,
        '2017-01-01 10:30:45.678'
    )
";

$session->execute($cql);

cqlsh 看一下資料格式:
cqlsh:zero_test> select name, size, create_time from file;

 name        | size  | create_time
-------------+-------+---------------------------------
 gavatar.jpg | 123.4 | 2017-01-01 02:30:45.678000+0000

(1 rows)

除了日期會自動轉為 UTC+00:00 以外其他都沒什麼太大的問題。

2017/09/05

用 Apache Bench (ab) 可能無法模擬高負載的網站實際情況

看到一篇「Why Apache Benchmark Is Not Enough」,這邊提到 Apache Benchmark (以下簡稱 ab) 由於都固定戳同一個 URL,這個情況下有很大的機會讓 HTTP server 或是 DB 用到相同的資並 cache 起來。

這樣子其實 ab 計算出來的 request per second 等數據,就失去了參考價值。

若要模擬真實的情境,像是「使用者看到圖片以後點擊連結開啟令一個網頁」,可以考慮使用 Apache jMeter 來建立不同的網頁 request 流程、隨意點擊,讓測試時更像真人在瀏覽網頁。