Type-C快速充電線測試

我的三星Note 8已經用了差不多兩年,原裝充電線已經報銷,所以除了不時尋找快速充電器的替代品之外,亦會留意市面上的充電線。

不過坊間的線材多數走高檔路線性價比不高,而且我需要支援三星快充,選擇有限⋯所以最近精選了多款充電線,希望為自己找到合適的線材,亦在這裡和大家分享一下。

首先今次選擇的線材有幾項先決條件:

  • 長度為2米(主要為家居用)
  • 黑色(個人喜好)
  • 支援快充(或聲稱支援快充)

以下是來自三個品牌的四款線材(順序從右至左):

  • Momax Elite Link Type-C to USB Cable DA18
  • ZMI Premium USB-C to USB-A Cable
  • Ugreen Type-C Cable (3A Max)
  • Ugreen 5A Supercharge USB C Cable

接著我會從包裝及價錢、線材質量以及充電三方面比較一下。

包裝及價錢

從上圖可以看到,Ugreen兩款線材都是袋裝形式包裝,而Momax和ZMI則以紙盒包裝,相對地比較優勝,能夠吸引購買者的注意,不過以實際使用為考慮的話,包裝實在是非常次要。

至於價錢方面,四款產品都是在天貓店購入,價錢分別是:

  • Momax:¥39
  • ZMI:¥39.9
  • Ugreen 3A:¥19.9
  • Ugreen 5A:¥28

最貴的ZMI是最平的Ugreen 3A雙倍的價錢,以性價比來看Ugreen比較突出。

線材質量

四款接頭的質量都不錯,Momax接頭與線的接駁位置造工非常堅固,而ZMI在磨砂接頭上加上圓形金屬裝飾,手感非常好。相對地Ugreen就比較普通,特別是5A那款,光身塑膠加上絲印字感覺較低級。

而線材方面Momax和ZMI都是用上編織質感,粗度分別是5mm和4mm,個人認為這兩款比較硬身,相反雖然Ugreen兩款線材無論質感(磨砂膠質)或者粗度(大約3.8mm)好像沒那麼好,但我比較喜歡軟身膠線,比較容易卷起來。

充電

最後當然要測試充電效果。這次分別使用兩個三星(5V 2A/9V 1.67A),Tronsmart WC1T QC3.0充電器以及ZMI QC 2.0 PowerPack 10000 mAh外置電源作測試。

另外這次只用我的三星Note 8作測試,所以快充的效果只針對三星手機系列的Adaptive Fast Charging。

測試結果令我覺得有點意外,因為Momax和Ugreen支援5A輸出的線材,在所有電源上都不能以快速充電方式為三星Note 8充電。而ZMI和Ugreen另一條最大3A輸出的線材卻在所有電源上能夠以快速充電方式充電。

結論

這個小小測試只是為自己需要而作,不是專業評測亦沒有任何贊助,更不是為品牌作打手,只是在科技範疇有時小品牌也有好用的產品,就像這次四款線材,最低價的Ugreen 3A卻最能滿足我的要求。

另外ZMI的品牌定位亦做得相當不錯,雖然它屬於小米生態鏈旗下,但產品設計比較高級,對外形有要求的用家是個不錯的選擇。

運用Spark AR Studio自制Instagram AR濾鏡

最近在Corridor Crew YouTube頻道看到他們所製作的IG AR濾鏡,於是下載了Spark AR Studio試作一下。

AR濾鏡主要是利用臉部辨認技術分析用家頭部及五官位置,再將各種圖案甚至立體物件加到相片或者影片中,亦可以與用家互動。

開啟Spark AR Studio後就會看到很多預設的範例,可以給初學者作參考。看過The Verge的文章後就製作了簡單的Pizza Time!濾鏡。

你可以在手機按這裡,或瀏覽 https://www.instagram.com/a/r/?effect_id=546985639403334 就可以開始試用。

最後附上Corridor Crew的影片。

簡易JS Instagram hashtag牆

在API還未流行之時,開發人員不用申請戶口就可以使用如Google Map或Instagram的API call。今日做research時發現原來有方法可以回到從前,只用URL就可以讀取Instagram指定hashtag的最新帖文JSON。

方法其實很簡單,只要瀏覽:

https://www.instagram.com/explore/tags/cats/?__a=1

就可以讀取#cats最新帖文的JSON檔。以下就用Javascript做了一個小小的Instagram帖文牆。

See the Pen Latest IG posts with specific hashtag by Terry Tong (@terrytongcc) on CodePen.dark

AWS入門 – 使用EC2建設WordPress網站

這篇blog主要是在AWS EC2上建設Wordpress的小小筆記,詳細內容都是連到AWS文件,一來官方教學會持續更新,二來兼容上應該會是最好,所以鼓勵大家多看官方文件哦。

步驟一:在 Amazon Linux 2 上安裝 LAMP Web 伺服器
步驟二:使用 Amazon Linux 託管 WordPress 部落格
步驟三:在 Amazon Linux 2 上設定 Apache Web 伺服器以使用 SSL/TLS

在Amazon Linux產生Private Key和CSR檔案

我負責管理的其中一個網站出現SSL憑證過期問題,檢查後發現是憑證檔案過期,但之前的私有金鑰(Private Key)和簽署要求(Certificate Signing Request)檔案已經找不到,所以需要重做一次,然後再到GoDaddy更新資料。

今次是在Amazon Linux上進行,其他版本的Linux只要有OpenSSL也可以使用。首先SSH到server,再輸入以下指令:

openssl req -new -newkey rsa:2048 -nodes -keyout mysite.key -out mysite.csr

之後需要按指示輸入相關資料,完成後會產生兩個檔案,mysite.key是私有金鑰,而mysite.csr是簽署要求,接著只要複製mysite.csr內的內容再到GoDaddy按指示更新資料便可。

Python網頁抓取 – 讀取網址並存檔

網頁抓取(Web scraping)是一個非常實用的技術,能夠幫助我們讀取網頁內的資料然後加以利用,所以今次使用Python作一個簡單的抓取程式。

首先我們將需要抓取的網址放在urls.txt中,一行一個網址:

https://www.python.org/
https://www.google.com/
https://www.bloomberg.com/

程式碼將會讀取這個檔案,然後一行一行地處理。

然後看看抓取網頁的程式碼:

import urllib.request
import time
import os

doc_folder = "files"

if not os.path.exists(doc_folder):
    os.makedirs(doc_folder)

with open('urls.txt') as my_urls:
	for my_url in my_urls:
		try:
			timestamp = str(int(round(time.time() * 1000)))
			print("Fetching URL: "+my_url.rstrip())
			my_url_res = urllib.request.urlopen(my_url.rstrip())
			my_url_raw = my_url_res.read()
			my_url_str = my_url_raw.decode("utf8")
			my_url_res.close()
			local_file = open('files/'+timestamp+'.txt','w+')
			local_file.write(my_url_str)
			local_file.close()
		except Exception as e:
			print('Exception: '+ str(e))

Python其中一個優點是簡潔,如果你是開發人員但未接觸過Python,相信只要點時間就可以明白。

首先我們引入需用的程式庫:

import urllib.request
import time
import os

urllib.request是用來讀取網頁之用,而time和os則是時間和系統相關的程式庫。

doc_folder = "files"

if not os.path.exists(doc_folder):
    os.makedirs(doc_folder)

接著我們會建立一個資料夾,如果已經存在就會略過。

with open('urls.txt') as my_urls:
	for my_url in my_urls:
		try:
			timestamp = str(int(round(time.time() * 1000)))
			print("Fetching URL: "+my_url.rstrip())
			my_url_res = urllib.request.urlopen(my_url.rstrip())
			my_url_raw = my_url_res.read()
			my_url_str = my_url_raw.decode("utf8")
			my_url_res.close()
			local_file = open('files/'+timestamp+'.txt','w+')
			local_file.write(my_url_str)
			local_file.close()
		except Exception as e:
			print('Exception: '+ str(e))

這段是抓取的核心程式碼,首先用with… as去打開urls.txt,然後用for… in逐行讀取網址並儲存在my_url中。
接著我們用urllib.request.urlopen去打開網址,my_url.rstrip()能夠將my_url尾段的空格符號移除。
之後程式會讀取網頁的內容然後設定為UTF8編碼並儲存在my_url_str,接著在files資料夾中創建一個新的檔案並將網頁資料儲存到檔案中。

在這個例子中我們只是將網頁內容存入檔案,你可以根據不同狀況將讀取的網頁內容存入資料庫又或者抽取其中的一些數據。

如何解決MySQL出現Error 1118: row size too large (> 8126)問題

IT人每天都要面對突發狀況,就算是再有經驗的IT專才也不能幸免。正所謂“我今日真係學咗好多嘢”,今次要記錄一下發生在MySQL的小狀況。

有天收到客戶的電郵,說在我們自家製的小型CMS上有一項記錄不能更新資料。在檢查時發現用來測試的記錄能夠順利更新,但在客戶所說的那一項卻不能,而前端沒有回報有任何錯誤。

之後用MySQL Workbench連到DB Server嘗試直接修改,結果出現了“Error 1118: row size too large (> 8126)”的錯誤信息。總算有點頭緒了。🤨

Google一下後了解到這是和Innodb的Row size上限有關。在MySQL 5.6以前,Innodb預設的File format是最原始的Antelope,它會把VARCHAR和TEXT之類的彈性長度Column的頭768 bytes放在Index record中作快速搜尋之用,而Innodb的預設Row size limit大約是8KB,所以當table裡面有很多BLOB或TEXT column,這8KB就會很快用完而產生row size too large的問題。

因為專案還在進行中,所以最後決定採用了將File format轉為Barracuda的方案。Barracuda是最新的Innodb file format,支援Compressed和Dynamic兩種row format,而我今次所選用的Compressed會為index page作壓縮處理從而解決Row size過大的問題。

首先檢查MySQL的版本,因為在5.7之後Barracuda已經成為預設,所以如果你的MySQL版本是5.6或以下,首先進到MySQL CLI執行以下指令:

mysql> show variables like "%innodb_file%";

畫面將會列出有關innodb的系統變數,如果出現了Antelope:

+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
| innodb_file_per_table    | OFF      |
+--------------------------+----------+

那就要執行以下三行指令:

SET GLOBAL innodb_file_format = Barracuda;
SET GLOBAL innodb_file_format_max = Barracuda;
SET GLOBAL innodb_file_per_table="ON";

完成後再檢查一次innodb系統變數:

+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Barracuda |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+

另外還需要在my.cnf中加入以下的設定:

innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix = 1

完成後restart MySQL的服務便可。

下一步是更新table的row format,進到MySQL CLI後執行:

mysql> ALTER TABLE test_table ROW_FORMAT=COMPRESSED;
/* 請修改test_table成為你的table名字 */

然後執行以下指令查看table狀態:

mysql> SHOW TABLE STATUS IN test_db\G
/* 請修改test_db成為你的table所在的database名字 */
*************************** 1. row ***************************
           Name: test_table
         Engine: InnoDB
        Version: 10
     Row_format: Compressed

Row format已經成功轉為Compressed,之後就可以測試一下以確認不再出現row size too large的問題。

6個好用Sublime 3 Package

轉用Sublime 3已經有三四年,除了支援Windows和Mac之外,另一個我很喜愛Sublime的原因就是擴充性超強。關於這點一定要提到Package Control。它是一個管理Package的工具,安裝了之後就可以輕鬆使用不同的Package加強Sublime的功能。

這次要介紹6個我覺得非常好用的Sublime Package:

1. Terminal

這個Package可以快速在開啟中檔案的位置打開Terminal。

2. Side​Bar​Enhancements

這個Package加強Sidebar的功能,例如在Sidebar上按滑鼠右鍵出現新增檔案/資料夾、更改檔案名稱等功能,非常方便。

3. Synced​Side​Bar

這個Package可以自動將Sidebar移到正在使用的檔案所在的資料夾,方便打開其他相關檔案。

4. HTML-CSS-JS Prettify

可以使用這個Package將HTML/CSS/JS排列好,方便閱讀。

5. Compare Side-By-Side

這個Package可以將兩個檔案同時打開作對比,並且提示那裡有所不同。

6. Generate Password

這個Package可以自動產生不同長度的隨機字串。

7. Theme – Sodarized

不是介紹6個嗎?為什麼還有第7個?

那是因為要介紹的這個Package並不是功能性的Package而是更改外觀的。

這個是將Solarized配色套用到Sublime的Package。對於整天coding的開發人員來說,這個配色可以減低對眼睛的負擔,當然適當的休息亦很重要哦。

WordPress不定時Timeout問題

最近在工作項目上遇到一個奇怪的問題:

情況是,在一個全新的Ubuntu 14.04.5 LTS的server上安裝Apache/PHP/MySQL/Wordpress,全部正常運作,但不知什麼原因令到載入網頁時會出現10秒左右的延遲,而這情況大約每一分鐘出現一次。

嘗試關閉所有外掛、轉回預設的主題、在另一個位置安裝新的wordpress、甚至在新的server重新安裝一次,還是出現這個問題…

後來安裝了Health Check & Troubleshooting外掛,發現其中一個項目“Loopback request”出現了問題。

新的server亦出現同樣狀況,似乎問題是Loopback request不成功引致timeout。因為不能修改server所在網絡的設定,所以只可以嘗試關閉Wordpress的WP-Cron。結果是… 不再出現10秒timeout的問題!😄

建議:如果不需要使用Schedule post之類的功能,可以在wp-config.php中加入:

define('DISABLE_WP_CRON', true);

就能夠關掉WP-Cron。