A Pragmatist Story

重點節錄， utf8mb4 的 mb4 即 most bytes 4。
若你的 MySQL 字串欄位要使用 emoji 時，建議使用 utf8mb4 編碼。

若你使用 Django 開發時，在字串欄位驗證，只會做到長度驗證，而不是 bytes 驗證，在制定長度時，要非常小心！

1
2
3

a = u'😀'
print len(a) # 1 -> 1 of length
print repr(a) # u'\U0001f600' -> 8 byte

當在 django 的 model 為如下：

1
2

class Broadcast(models.Model):
    subject = models.CharField(max_length=20, help_text=_(u'限制 20 個字'))

當輸入 20 個 emoji 時，雖然長度上是小於等於 20，但是儲存在 DB 時，卻會是 80 bytes 唷！

ref: http://seanlook.com/2016/10/23/mysql-utf8mb4/

如果公司是使用 Slack 之類的辦公聊天軟體，當在制定「包含 emoji 的文案」時，想直接從 Slack 的對話框複製到網站上做發佈時，可能遇到狀況如下：「你好:ok_hand:」而不是「你好👌」。

可能需要如下工具來操作：

ref: http://www.iemoji.com/
ref: https://apps.timwhitlock.info/emoji/tables/unicode

When Amy makes a comment in Taiwan at 20:00(GMT+8), his friend Tom in Japan should sees the comment is at at 21:00(GMT+9).

Best Practice:

1. Please remember using datetime.datetime.utcnow() to express object’s created time
2. Recommend that pytz is awesome libary to handle timezone

uid 在 ElasticSearch 是一個 meta data 的資訊欄位，而且是 字串 屬性，不是由 mapping 可定義的資料結構。

當開發人員把資料從 MySQL/PostgreSQL/MongoDB 倒入至 ElasticSearch 時，可以把資料的 primary key 註記為 document 的 uid。

但是作為排序的對象的話，可能會慘不忍睹…。(掩面)

參考討論： https://discuss.elastic.co/t/how-does-sorting-on--id-work/21854/2

當時想做一個「精準廣播」的功能，把符合資格的裝置名單，建立成一個 AWS 的 SNS topic 作為發送對象。
目前使用了 python 的 mutiplethread/mutipleporcess 和 celery 幾種方案做了比較，仍然不是感到很滿意。
結論是，如果使用的機器的運算能力沒有這麼強大或數量龐大，當面對的推送對象很大時，需要在操作機制上來繞過這個捆擾。

從 Celery 的 task signal 了解其工作生命周期如何運作。

當 sender 到 message queue，再到 receiver 的傳遞過程。

當有一個 request 的是 /api/v3/banners/?zones=tw-app-feature-1,tw-app-feature-5,tw-app-feature-3,tw-app-feature-4,tw-app-feature-2 必須符合 query string 的順序時，這邊有實作 ORM 和 MySQL built-in function 兩種處理方式，可供提供比較。

這邊先講結論：使用 ORM 擁有較高的 python 可讀性，畢竟是用 python 描述；而使用 MySQL built-in function 得要做字串併接，可讀性不高。

https://www.facebook.com/xdite/posts/10156252803748552

ref:

1
2
3
4
5
6
7
8
9
10
11
12
13

我覺得在中國交朋友與在台灣交朋友。
很大的差別在於是否有「將時間計價」的概念。
1. 因為競爭很激烈的關係。所以時間往往是很貴的。
2. 因為路途遙遠的關係，所以通常不會約出來談，而是傾向在微信上談定。
3. 因為時間很貴的關係，如果在微信上 5-20 分鐘沒有結論。直接說再評估，那就是謝謝再聯絡。
4. 因為人太多的原因，通常你好不容易加到名人 contact，不會亂騷擾對方問基礎問題。比如說「可不可以請教怎麼樣入門XXXXX？」否則拉黑你這輩子再也沒有機會加到他。
5. 如果朋友幫你簽線拉群，最好在拉群的五分鐘內，把你想幹嘛，要什麼，願意給多少錢講清楚。不管有沒有談成發個紅包謝謝介紹人。有談成，至少撥個5% 以上 profit 謝謝介紹人。
6. 如果真要開個會，大家會以本會是要「拿結論」「至少拿下什麼結論」（假設要談10樣，我們可以談下哪3樣為最少目標）。如果約出來只是要 say hello，就是 credit 降低。
7. 自己要交陌生朋友前，會先算自己時間價值多少，對方時間價值多少。對方太高的不會莫名打擾，也不會大費周章約到只 say hello。否則連中間人都會拉黑你。
8. 萬物都有個 price，而且通常是合理的。因為大家都希望有下次合作機會。第一次通常會讓利，因為第一次就獅子太開口，沒有人會想跟你做生意。除非你說的出來為什麼你貴。談錢不打緊，重要是別把人當傻逼。
9. 知識都是用錢買。絕對不會出現這種：「想要把人約出來，請人吃個飯就想讓自己聽內線賺大錢」的無腦行為。
10. 大家合作做一件事，態度先是把這件事情做成。而不是道德綁架。如果確定要做，當場就簽。否則就是多聊聊幾家多發發幾個紅包，先搞清楚狀況。
對比之下，真的差很多。。。。。。

如果你是 Ubuntu 使用者，在 Git gui 是選用 SmartGit，希望能給你幫助。

解決目標是：SmartGit 的免費方案使用期間為 30 天，若要再次使用則需要從路徑中刪除 SmartGit 的設定檔。

於是我撰寫了一個 script 腳本，省略其瑣碎的步驟並達到快速刪除，參考如下：

1
2
3
4
5
6
7
8
9

TAGERT_FILE="settings.xml"
SMARTGIT_PATH="${HOME}/.smartgit"

VERSION_REGEX="^[0-9]+$"
LATEST_VERSION=`ls ${SMARTGIT_PATH} | grep -P ${VERSION_REGEX} | sort -n -r -k 1 | head -1`

TAGERT_FILEPATH="${SMARTGIT_PATH}/${LATEST_VERSION}/${TAGERT_FILE}"

rm ${TAGERT_FILEPATH}

Reference on StackOverflow: How to change SmartGit’s licensing option after 30 days of commercial use on ubuntu?

yoyo~