Slack archive

cofacts

Month: 2018-02

2018-02-02

mrorz 00:41:14
@ggm https://github.com/cofacts/rumors-line-bot/issues/40 這個好像沒修好耶
現在 production 的 LINE bot 確實會擋過短字串，但只輸入網址的話是不會擋的囧

GitHub

Query string only contains a single url · Issue #40 · cofacts/rumors-line-bot

擋掉然後回應：「這是單純的網址，不是轉傳訊息，請從網址擷取出相關的文字資訊。」

ggm 01:09:21
這麼神秘 我試試看
ggm 01:13:30
你打什麼網址呀？我試都可以捏
ggm 01:14:32
你會不會打的網址是原本就搜的到內容的？
mrorz 01:31:47
啊可能是耶
mrorz 01:32:16
然後我按「這裡沒有一篇是我傳的訊息」
然後就可以送出資料庫了
mrorz 01:32:37
如果太短的話不應該要有「這裡沒有一篇是我傳的訊息」
或者是按了之後跟他說太短
mrorz 01:33:14
這裡有一個使用者案例：
https://cofacts.g0v.tw/article/AWFR5jVChutQxxU6tq00
bil 12:14:12
bil 12:15:20
那如果不讓他搜內容呢？@@
mrorz 12:20:44
那之前針對該連結寫的回應就白費了呢
既然要修這個 bug 就正面修好它，在按下「這裡沒有一篇是我傳的訊息」按鈕時檢查長度。
bil 12:31:57
那可以在修好這個bug之前不讓他搜嗎?
ggm 18:18:54
噢這是之前討論到的，最早的時候是擋在搜尋前面，後來討論說要擋在搜尋後面。

但是漏掉了，他可以透過「這裡沒有一篇是我傳的訊息」來新增文章
ggm 18:20:49
我覺得不是按下的時候擋下他，而是把那張卡片顯示成。「你輸入的OOOO太短，所以 XXOXOX 不能新增噢」之類的文字。
mrorz 18:23:08
好唷就照著 ggm 說的這麼做吧
ggm 18:23:39
ok go
mrorz 00:56:26
是說 DB schema 有個 change 希望 @ggm @darkbtf review 一下唷
https://github.com/cofacts/rumors-db/pull/12

GitHub

Add omitted fields by MrOrz · Pull Request #12 · cofacts/rumors-db

Add normalArticleReplyCount so that we can list articles by number of replies. I failed to find a way to filter by nested object count, and there are others suggesting adding such field for efficie...

ggm 18:23:53
ok 我今天晚點看

2018-02-03

mrorz 18:14:00
剛好有個空就順手擋掉了 URL 的 issue，目前放到 staging 上了，大家可以測測～

staging LINE bot QR code: https://line.me/R/ti/p/%40nkq3195z
(ID: @nkq3195z )

請 @ggm Review 唷
https://github.com/cofacts/rumors-line-bot/pull/52

GitHub

Block nonsense text from submitting through search results by MrOrz · Pull Request #52 · cofacts/rumors-line-bot

rumors-line-bot - Line bot that checks if a message contains internet rumor.

ggm 18:29:03
ok

2018-02-04

@null 14:23:08

Log event

2018-02-04 06:20:37.536 94 <190>1 2018-02-04T06:20:37.079467+00:00 app web.1 - - 2018-02-04 06:20:37.536 116 <190>1 2018-02-04T06:20:37.079562+00:00 app web.1 - - [App:heroku-line-bot] 2018-02-04 06:20:37.536 165 <190>1 2018-02-04T06:20:37.079563+00:00 app web.1 - - ||LOG||"actions":[{"type":"postback","label":"選擇","data":"{\"input\ 2018-02-04 06:20:37.536 94 <190>1 2018-02-04T06:20:37.079565+00:00 app web.1 - - 2018-02-04 06:20:37.536 116 <190>1 2018-02-04T06:20:37.079650+00:00 app web.1 - - [App:heroku-line-bot] 2018-02-04 06:20:37.536 142 <190>1 2018-02-04T06:20:37.079652+00:00 app web.1 - - ||LOG||":0,\"issuedAt\":1517725236073}"}]}]}}]}} 2018-02-04 06:20:37.536 94 <190>1 2018-02-04T06:20:37.079654+00:00 app web.1 - - 2018-02-04 06:20:37.536 116 <190>1 2018-02-04T06:20:37.079741+00:00 app web.1 - - [App:heroku-line-bot] 2018-02-04 06:20:37.536 112 <190>1 2018-02-04T06:20:37.079743+00:00 app web.1 - - ||LOG||----------> 2018-02-04 06:20:37.536 94 <190>1 2018-02-04T06:20:37.079744+00:00 app web.1 - -

ggm 23:29:09
窩操
ggm 19:49:45
THE typo sticker
https://line.me/S/sticker/1930824

LINE STORE

THE typo sticker – LINE stickers | LINE STORE

THE typo sticker

mrorz 11:59:21
這也能出
mrorz 12:01:16
嘲諷度爆表 w
ggm 23:29:09
窩操

2018-02-05

mrorz 12:12:22
@ggm
https://github.com/cofacts/rumors-line-bot/issues/35 這個失敗了，signature mismatch 依然在發生 Orz

GitHub

checkSignature() causing incoming requests gets 401 · Issue #35 · cofacts/rumors-line-bot

mrorz 00:25:11
我覺得應該是我 captureRawBody 硬塞進utf8字串導致錯誤
尤其好發於超長訊息
由於訊息字串常常會被 encode 成 `\uXXXX`
而我原本的塞法，可能會導致 `\uXXXX` 被分兩次塞進 utf8 陣列，造成解譯錯誤，這樣一來算出來的 signature 就會跟傳進來的不同。

我發了一個 https://github.com/cofacts/rumors-line-bot/pull/54 ， deploy 到 staging
也附上了常常會觸發 production 上的 signature mismatch 的 sample。

目前試了幾個字串，同時轉傳給 production 與 staging line bot，前者不回話，而後者會回，看起來似乎會 work。

再麻煩 @ggm review 了！
ggm 13:45:22
噢噢我好奇，所以 `raw-body` 是多做什麼事情呀？先確認 `ctx.request.charset` 之類的嗎
mrorz 13:49:16
`ctx.req` 是 node http `Stream` 但 `checkSignature` 吃 node `Buffer` 或 string
`raw-body` 可以 http stream 轉 buffer
mrorz 13:53:46
ctx.req 是這個 https://nodejs.org/api/http.html#http_class_http_incomingmessage （implements Readable Stream interface）
mrorz 13:55:15
buffer 是監聽 stream 的 events 然後一個一個 chunk 吃進來擺進陣列的那個陣列
mrorz 13:56:45
所以你也是可以說我不要 raw-body
原本的 `captureRawBody` 的 string 改 buffer 啦
但同一份 stream 被 `captureRawBody` 弄一次，然後被 `body-parser` 也弄一次，實在滿蠢的
所以就一起拔掉了
mrorz 13:58:22
其實精確來說 body-parser 內部也是用 raw-body
我們的 use case 裡面，只需要 stream 轉 raw buffer 就好，不需要 body-parser 其他那些 content-type detection、轉 html 轉 json 轉 text 那些碗糕
所以就去掉 body-parser 只取 raw-body 囉
mrorz 14:12:09
Deployed to production on 2pm
let's see if there is any such exceptions...
ggm 14:24:20
對啊接 buffer 好像是比較萬無一失，哈哈
ggm 15:27:20
慘 .. qq
mrorz 16:03:44
今天收到一個老謠言
發現他的解答被刪掉了 QQ

55 人回報呢

https://cofacts.g0v.tw/article/5361365130068-rumor
mrorz 16:08:08
我看原本的回應挺好的，就補回去囉

2018-02-06

henry30270 15:47:34
@henry30270 has joined the channel

2018-02-07

mrorz 00:25:11
我覺得應該是我 captureRawBody 硬塞進utf8字串導致錯誤
尤其好發於超長訊息
由於訊息字串常常會被 encode 成 `\uXXXX`
而我原本的塞法，可能會導致 `\uXXXX` 被分兩次塞進 utf8 陣列，造成解譯錯誤，這樣一來算出來的 signature 就會跟傳進來的不同。

我發了一個 https://github.com/cofacts/rumors-line-bot/pull/54 ， deploy 到 staging
也附上了常常會觸發 production 上的 signature mismatch 的 sample。

目前試了幾個字串，同時轉傳給 production 與 staging line bot，前者不回話，而後者會回，看起來似乎會 work。

再麻煩 @ggm review 了！

GitHub

Implements signature middleware by MrOrz · Pull Request #54 · cofacts/rumors-line-bot

This is another attempt to fix #35 . We suspect that the implementation of captureRawBody, which records request stream into a string, is the source of signature mismatch. This PR completely gets r...

ttcat (not_staff) 17:03:53
哈囉你們今天開完會了？
mrorz 19:02:08
還沒呀上面是今晚預計要討論的呢
ttcat (not_staff) 17:04:22
想跟大家討論幾件事，另外 LINE 官方帳號那邊解決了嗎
mrorz 19:02:16
沒 orz
bil 19:03:13
歡迎阿端來喔，line官方帳號那裡還沒有解決
ggm 21:25:17
還沒我剛寄信催了一波！
ttcat (not_staff) 15:27:46
QQ 結果 slack 沒跳出來所以我錯過了
ttcat (not_staff) 15:27:54
你們還有什麼時候會在啊？
delightfullychaotic 17:07:57
2/10 小聚
ttcat (not_staff) 17:26:54
orz 那天要帶外國人出遊
ggm 15:39:42
那就要等到過年後囉！

2018-02-08

zoe770 07:25:40
@zoe770 has joined the channel
bess 18:13:51
嗨，想問，你們週六小聚會有人拍照記錄活動嗎？
delightfullychaotic 18:22:03
自己會記錄～有幫手嗎www
bess 18:22:47
那個……不然我也可以帶相機去，手冊要加你們的部分 2 頁，很 需 要 照 片
bess 18:23:18
多 多 益 善
mrorz 18:23:51
好唷請帶請帶
mrorz 18:24:03
我們 Facebook 有之前的活動紀錄說
bess 18:24:34
那好像不用帶了（咦）
有原檔連結嗎？手冊要印刷用的檔案
mrorz 18:24:46
等等，好像沒放相簿 QAQ
mrorz 18:25:03
我回去傳 google photos 連結給你～
bess 18:25:10
好喔感恩

2018-02-09

2018-02-10

mrorz 11:48:54
現在撰寫回應，有新的功能囉！

如果「現有回應」頁籤沒有找到你要的回應，但你記得之前 Cofacts 有回應可以拿來用的話，現在可以切到「搜尋」頁籤輸入關鍵字，搜尋過去的回應並且直接加到文章囉！
新功能：搜尋現有回應
mrorz 12:28:16
因為今天就是小聚了，所以我把 bot 下面的 menu 更新囉
也改成不會預設打開了

2018-02-12

johan 18:18:15
@johan has joined the channel

2018-02-13

delightfullychaotic 09:02:19
看到這個很無奈＝＝
hazelwei 10:02:04
Hackfolder是不是壞掉了？
mrorz 11:47:09
Yes, 後來 #general 有人回報囉
au 在修～
ronnywang 14:51:39
回來了
bil 11:36:18
Line帳號跟貼圖那裡要想別的辦法囉，大家有什麼建議嗎
mrorz 12:10:29
原案好像是上架賣
只是就要改合約
然後重新談拆帳怎麼做這件事情
bil 13:59:23
意思是acho跟設計師那裡要道歉跟重新寫合約對嗎？
mrorz 14:53:18
如果採原案的話是這樣的沒錯 QQ
bil 15:27:48
能先試著寄信給adam或monica他們試試嗎？
ggm 15:55:49
就道歉然後重擬合約吧？
ggm 15:57:25
接著其實還有也很麻煩的事情，就是 LINE@ 的申請開公司弄嗎？還是要掛在 ocf，這樣就要他們幫我們申請商標，然後再註冊。還有之後我們上架貼圖，金流也會進 ocf 這樣會拆帳拆帳再拆帳也會有點麻煩，所以需要討論一下怎做比較好
mrorz 16:18:58
尋求另一個部門的協助也不失為一個辦法沒錯
ggm 18:55:26
噢噢對也是，那就要繼續等待回應
ttcat (not_staff) 23:41:51
如果有這種已經被拆帳過又不需要 ocf 再開發票收據的 case，可專案來談折扣
ttcat (not_staff) 23:40:34
明晚還會開會嗎？
bil 23:47:41
明晚小年夜沒有開會唷
ttcat (not_staff) 23:46:58
或是能否跟大家約線上呢

2018-02-14

mrorz 01:29:51
但我已經約了牙醫 QQ

2018-02-15

mrorz 00:34:04
RightsCon 投稿上了呢
ttcat (not_staff) 12:29:41
那 @mrorz 要跟我們去了嗎？ya~
ttcat (not_staff) 12:30:40
我其中一個跟 cofact 有關的也上了，就再 merge 吧
mrorz 12:49:37
go
mrorz 15:12:23
一起住大學宿舍呀 XD
ttcat (not_staff) 21:23:10
你有申請到機票補助嗎？我們可能有經費，但四月才知道
mrorz 02:22:09
沒有呢
我的visa金融卡準備好了 (?)
mrorz 15:12:31
不知道有沒有 airbnb
mrorz 19:01:51
我們目前在搜尋引擎不會是前幾名
好像是 https://github.com/cofacts/rumors-site/issues/67 的影響

由於我們全站的 structured data 除了 website 之外就剩下 claimreview
所以先試著拿掉 claimreview 看看是否可以改善
麻煩 @lucien @sunrise91.t3 review 一下 https://github.com/cofacts/rumors-site/pull/81

GitHub

Removing ClaimReview tags for now by MrOrz · Pull Request #81 · cofacts/rumors-site

Because they might be the cause of "spammy markup" Fixes #67

ttcat (not_staff) 21:07:18
因為一直沒時間跟大家約，我直接先把想跟大家討論的事列這邊：
mrorz 02:15:57
要注意的是 slackarchive 掛掉很久了，所以一週內這些訊息很可能會消失唷 QAQ
ttcat (not_staff) 21:09:36
1. 上次談到把 cofacts 包裝一下讓其它東南亞有在用 LINE 的像泰國、印尼當地關注 fake news 的公民倡議團體可以用，這部分可能有經費支持
ttcat (not_staff) 21:12:17
2. 6/26-27 OCF 這邊會辦一個針對 combating disinformation 給台灣與東亞公民社會的 workshop，想邀 cofacts 來合辦，例如協助規劃議程、host 部分 sessions 或有沒有其它你們覺得可以邀的單位？
mrorz 02:11:20
1. 媒體觀察教育基金會
2. MyGoPen
3. 蘭姆酒吐司
mrorz 02:12:31
然後有辦法邀到 Google News Lab APAC 嗎
ttcat (not_staff) 16:16:30
I can try!
ttcat (not_staff) 21:15:43
3. 今年 4 月中，TICTeC 在葡萄亞里斯本，我們會去參加，對方邀請我們分享 cofacts 20 分鐘，但目前還沒有找到直接經費贊助，想問是否有人能自費隨團？若不能，是否能跟大家約個時間討論可以分享那些內容？從目前的回報資料庫是否有一些新的 Insight?
mrorz 02:15:18
我的部分
5 月中要去 RightsCon
6 月下旬希望可以去 Global Fact V (Poynter 辦的，主題 100% 吻合)
4 月中還去的話覺得有點太頻繁了 QAQ

不知道有沒有其他成員有興趣呢？
ttcat (not_staff) 21:17:59
4. 之前大松 mrorz 好像提到，今年要再推一次比較大的宣傳，但缺設計師 or UI？（我印象有點模糊）看是不是請揪松也幫忙找人推坑，或能不能用 1) 的經費來協助
mrorz 02:16:56
@lucien 說年節會出 UI design 唷～
ttcat (not_staff) 21:18:46
5. 更新 LINE 官方帳號的進度以及討論我們可能的協助
ttcat (not_staff) 21:19:00
以上，大家新年快樂:tada:
ttcat (not_staff) 21:19:34
看是不是有 email 群組來 follow 這些討論，或年後我再去你們的會議

2018-02-16

mrorz 02:20:24
年後應該是 2/21 開會唷
mrorz 02:21:14
是說我終於把 API refactor 完了
最後一個 bug 卡了我 7 天囧

但改了 87 個檔案，這個 PR 我在想要不要直接上惹⋯⋯
https://github.com/cofacts/rumors-api/pull/62

GitHub

[WIP] 201712 mappings refactor by MrOrz · Pull Request #62 · cofacts/rumors-api

rumors-api - GraphQL API server for clients like rumors-site and rumors-line-bot

mrorz 15:24:25
現在要來針對 staging site 做 DB migration process
( https://github.com/cofacts/rumors-db/issues/7#issuecomment-352262625 )
mrorz 20:20:32
Staging DB & API with new schema 上線囉

http://bit.ly/2GiMGjK

之後就可以支援先照 article reply count 排、再照 last requested at 的時間排了
mrorz 22:19:14
先照 article reply count 排、再照 last requested at 的時間排：
http://bit.ly/2GiIoZX

2018-02-17

mrorz 22:58:40
@lucien @sunrise91.t3
我這裡先送了一包小的 PR，改環境變數讓 rumors-site 可以支援 staging 環境。
https://github.com/cofacts/rumors-site/pull/82

GitHub

Add support for staging env by MrOrz · Pull Request #82 · cofacts/rumors-site

Now the staging site available at <https://cofacts.hacktabl.org> with API connecting to <https://cofacts-api.hacktabl.org>

mrorz 23:03:37
現在點進去應該會遇到一些 GraphQL error
那是因為 staging API 有改欄位所致
明天會把欄位那些改成新的

那一包 PR 就會很大了呢⋯⋯
mrorz 20:42:06
今天成功把 staging API 與 staging site 接起來囉：
https://github.com/cofacts/rumors-site/pull/83
mrorz 20:42:21
@sunrise91.t3 @lucien 求 review

2018-02-18

mrorz 20:42:06
今天成功把 staging API 與 staging site 接起來囉：
https://github.com/cofacts/rumors-site/pull/83

GitHub

201712 mappings refactor by MrOrz · Pull Request #83 · cofacts/rumors-site

Make necessary changes to make the UI compatible with API after 201712-mappings-refactor. Since we are having low test coverage in this repository, I am doing minimal changes to support the new API...

mrorz 20:54:49
這個是新版 DB mappings 的測試站（staging），歡迎大家戳戳他
https://cofacts.hacktabl.org/

大家可以測的東西有

文章頁面：
- 回應
- 幫回應評分
- 把現有回應加到文章裡
- 搜尋回應之後把回應加到文章裡
- 刪除回應

回應頁面：
- 幫回應評分
- 刪除回應

已知問題：
- 刪除回應之後文章回應數要重新整理才會變 --> 這個在 UI 改版時重寫就好
- 第一次註冊好像會出現 “Unauthorized”，重新整理之後才會註冊 --> 原因不明 orz
mrorz 20:55:43
除了已知問題之外，請回報遇到的其他問題唷

2018-02-19

mrorz 14:20:03
@ggm @acerxp511 我稍微統一了一下 unit test 的 syntax （請見 PR description）請 review 一下～
https://github.com/cofacts/rumors-line-bot/pull/56

GitHub

Improve unit test styles by MrOrz · Pull Request #56 · cofacts/rumors-line-bot

Use async-await to drop verbose promise then() handling Use es-modules syntax in fixtures to drop verbose export default {...} at the bottom of the file Use jest manual mocks to reduce the lines-of...

mrorz 15:26:20
另外，
Mappings refactor 最後的修改：LINE bot API calls 調整
在這裡完成囉
https://github.com/cofacts/rumors-line-bot/pull/57
ggm 01:11:00
ok
mrorz 15:29:40
「真的假的-staging」LINE bot 現在上面的是 mappings refactor 過後版本的程式唷。
LINE ID: @nkq3195z

歡迎大家戳戳他！

他接的資料庫跟測試站（ https://cofacts.hacktabl.org/ ） 相同，在 staging 的 bot 送出的 article 會在 https://cofacts.hacktabl.org/ 被列出。測試站資料庫跟主站分開，所以不會污染到 http://cofacts.g0v.tw|cofacts.g0v.tw。
mrorz 15:31:06
大家可以測的東西有：

- 傳送過短訊息
- 傳一篇超長文章送進資料庫（不用擔心送垃圾進去，資料庫跟主站是分開的）
- 去 https://cofacts.hacktabl.org/ 找一篇沒回過的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇只有 1 個回應的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇有很多回應、很多類似的文章去問 line bot
sunrise91.t3 17:59:16
我現在rumors-site測試台自己的回覆「刪除回應」沒顯示、「是否有幫助」是自己可點選的狀態。應該是資料格式改動的關係吧，但local我checkout到201712-mappings-refactor再merge staging-env跑run dev是正常的耶～ 我其實有點搞不清楚是怎麼回事～:sweat_smile:
mrorz 18:30:53
測試站的 appId 跟 local 的 appId 應該不太一樣
mrorz 18:31:20
所以可能會被 API 判斷成不同人
mrorz 18:35:56
不過 https://cofacts.hacktabl.org/replies 一排的「有人」（user 只拿到 `null`）應該也不太正常 orz
mrorz 21:02:36
這一點我知道為什麼啦～～

因為 migration script 根本就忘記了 users 這個 index
所以 staging 上面的 users 表其實一片空白～～
這也是為什麼大家 staging 都像沒註冊過一樣
囧

https://github.com/cofacts/rumors-db/blob/master/db/migrations/201712-001-reindex.js <-- 完全沒 reindex `users`
mrorz 18:37:13
理論上你在 staging site 自己發的訊息，他應該會認得得才是正常的
mrorz 18:38:07
我可能要 trace 一下 API 那裡到底發生什麼事 QQ
sunrise91.t3 18:38:52
了解～ 晚點再試試～

2018-02-20

mrorz 00:01:37
staging db 被我弄壞了 orz
修理中
mrorz 00:30:04
Fixed

2018-02-21

mrorz 09:37:03
我們今天晚上 8pm 開會唷，請問 @ttcat 會來嗎
ttcat (not_staff) 11:56:58
今天爆炸，晚上有 community hangout
ttcat (not_staff) 11:57:15
我橋一下看八點跟你們 hangout?
ttcat (not_staff) 12:02:11
八點準點
ttcat (not_staff) 14:11:40
那就拜託嚕 :slightly_smiling_face:
ggm 20:37:12
https://protostar.line.me/zh-tw/

LINE

LINE新星計劃

新創公司可藉由新星計劃在LINE平台上建立應用程式，並因此拓展業務到所有的LINE用戶。

ggm 20:48:33
http://rich01.com/linesop1/

Mr.Market市場先生

Line貼圖怎麼上架？超詳細製作SOP，1分鐘學會每月「微加薪」 - Mr.Market市場先生

「市場先生，你覺得畫Line貼圖能賺錢嗎?」 「要爆紅才行吧，不過有畫才有機會！」 上次和一位美術系的學生， …

2018-02-22

mrorz 01:02:06
LINE bot 與網站均已下線
開始進行 migration
@null 01:10:41

Log event

2018-02-21 15:31:37.826 420 &lt;134&gt;1 2018-02-21T15:30:37+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.055 sample#load-avg-5m=0.065 sample#load-avg-15m=0.07 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468kB sample#memory-free=12690532kB sample#memory-cached=1215400kB sample#memory-redis=13176056bytes sample#hit-rate=0.95682 sample#evicted-keys=0 2018-02-21 16:14:16.671 418 &lt;134&gt;1 2018-02-21T16:13:49+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.04 sample#load-avg-5m=0.07 sample#load-avg-15m=0.06 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468kB sample#memory-free=12691324kB sample#memory-cached=1215484kB sample#memory-redis=13177896bytes sample#hit-rate=0.95682 sample#evicted-keys=0 2018-02-21 16:21:34.606 418 &lt;134&gt;1 2018-02-21T16:21:11+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.09 sample#load-avg-5m=0.08 sample#load-avg-15m=0.06 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468kB sample#memory-free=12690064kB sample#memory-cached=1215500kB sample#memory-redis=13177896bytes sample#hit-rate=0.95682 sample#evicted-keys=0 2018-02-21 16:23:53.748 420 &lt;134&gt;1 2018-02-21T16:22:34+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.055 sample#load-avg-5m=0.08 sample#load-avg-15m=0.065 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468kB sample#memory-free=12691324kB sample#memory-cached=1215500kB sample#memory-redis=13177896bytes sample#hit-rate=0.95682 sample#evicted-keys=0 2018-02-21 16:56:51.756 310 &lt;158&gt;1 2018-02-21T16:56:51.519753+00:00 heroku router - - at=info method=POST path="/callback" host=<http://rumors-line-bot.herokuapp.com|rumors-line-bot.herokuapp.com> request_id=e74707d8-6783-4f70-80f7-3d721ff226b9 fwd="203.104.146.156" dyno=web.1 connect=1ms service=6ms status=200 bytes=137 protocol=https 2018-02-21 17:01:35.489 142 &lt;45&gt;1 2018-02-21T17:01:34.513534+00:00 app api - - Release v64 created by user <mailto:johnsonliang7@gmail.com|johnsonliang7@gmail.com> 2018-02-21 17:01:35.866 106 &lt;45&gt;1 2018-02-21T17:01:35.564137+00:00 heroku web.1 - - Restarting 2018-02-21 17:01:43.011 137 &lt;45&gt;1 2018-02-21T17:01:42.685904+00:00 heroku web.1 - - Starting process with command `npm start` 2018-02-21 17:01:48.617 142 &lt;190&gt;1 2018-02-21T17:01:48.235048+00:00 app web.1 - - PM2 and application has been succesfully started 2018-02-21 17:01:48.693 121 &lt;190&gt;1 2018-02-21T17:01:48.286877+00:00 app web.1 - - [PM2] Log streaming started

mrorz 02:39:49
migration 已經完成囉！
mrorz 10:19:59
是說昨天 migration 一陣慌忙，忘記換 production server 的 docker engine 版本
現在版本是 1.12 超舊，連 `docker prune` 指令都沒有，然後硬碟快滿了 Orz
mrorz 21:52:32
關於這個功能在技術上怎麼實做，我在思考一件事情：
https://github.com/cofacts/rumors-api/issues/65

1. 目前每個 article 都有 `userId` 與 `appId` 欄位，可以用 `userId` + `appId` 查詢到這個人之前發過的文。API 只要增加 `userId` 與 `appId` 欄位，就可以查一個人的文章。

2. `appId` 是預留給未來開放第三方 app 申請 appId 之後，讓第三方 app 可以在不註冊使用者的狀況下送入資料用的。目前我們 LINE bot 的 `appId` 是固定的一個常數值（https://github.com/cofacts/rumors-api/blob/master/src/checkHeaders.js#L8 ）， `userId` 則是直接拿使用者在我們 LINE channel 的 `userId`。

3. 問題在於如果我們想要在官網做「顯示此文作者送過的文章」功能，那我們就得要把 `userId` 給 expose 到外面來，例如說這個列表頁面就要拿 `userId` 作為 URL param 之一，並且要做成超連結放在文章頁面讓大家都能任意點入。但 `userId` 可能是個資的一部份；未來開放第三方 app，第三方可能會把更敏感的東西（如 email）當成 `userId` 傳入資料庫。

GitHub

List submitted articles of a LINE user · Issue #65 · cofacts/rumors-api

As discussed in 20180207 It can be used in: When the user is banned, other users can see what kind of article will cause one being banned Can have a list of article called "I submitted before"

nonumpa 09:12:36
不能直接用articleID當url param找userID和appID嗎?
mrorz 14:15:13
有道理耶，這招不錯。

雖然會要多撈一次資料庫（在 API 裡先拿 `articleId` 撈 `userId` + `appId`）但我覺得不會太 costy。

拿 `articleId` 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 `articleId` 會是個相當合適的解。
nonumpa 17:28:41
後來想想正確的解法應該是要避免 `userId` 用敏感資料來表示。
這樣如果未來用會到email的話，就要再建一張 `userId` 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。
mrorz 17:40:53
其實如果是網站的使用者（有經過 FB / Twitter / Github 註冊），就會記在 `users` 資料表裡了，此時 `userId` 是 `users` 資料表的 ID，不是敏感資料。不過 LINE 的使用者（ `userId` + `appId`）是沒有在 `users` 資料表裡的。

之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 `users` 資料表新增 line user id 欄位的方式。
mrorz 21:54:21
如果我不想 expose `userId` 出來，又要能夠 expose 個東西放進 URL，最好的方法是用個 key 來加密嗎？

2018-02-23

2018-02-24

chewei 02:01:06
@chewei has joined the channel

2018-02-25

mrorz 01:36:13
飛機都不來
google 與 FB 上不了
只好來發 PR
求 review

https://github.com/cofacts/rumors-api/pull/68
https://github.com/cofacts/rumors-db/pull/13

GitHub

Add author related filter input for ListArticles by MrOrz · Pull Request #68 · cofacts/rumors-api

This PR enables ListArticles to show only articles by a specified author. For spec please see #65 . Fixes #65

GitHub

Add fields required for reply request reason &amp; voting reason by MrOrz · Pull Request #13 · cofacts/rumors-db

In order to implement cofacts/rumors-api#67 , we should add these fields to DB. Existing reply request does not have reason fields. They can't be given feedbacks anyway, thus I think we don't need ...

2018-02-27

mrorz 05:12:02
@lucien @sunrise91.t3 我想測測看這到底會不會對 SEO 有影響
所以就 merge 囉
https://github.com/cofacts/rumors-site/pull/81

GitHub

Removing ClaimReview tags for now by MrOrz · Pull Request #81 · cofacts/rumors-site

Because they might be the cause of "spammy markup" Fixes #67

mrorz 06:12:52
糟糕，旅館速度太慢沒辦法 deploy Orz
mrorz 03:17:37
結果我的 reconsideration request 收到了 rejection QAQ

說問題一樣是 spammy markup

https://support.google.com/webmasters/answer/3498001?ctx=MAC
pofeng 11:01:15
orz , 又來了一個謠言查證網站 ... http://www.rumtoast.com/

蘭姆酒吐司

蘭姆酒吐司｜真相與謠言的水乳交融

蘭姆酒吐司 蘭姆酒（RUM）是來自謠言(RUMOR)的字首，吐司則是取自真相（TRUTH)的諧音，我們的使命就是專門擊破網路謠言，還原真相，並督促各位繼續享受生命中的美好事物。

delightfullychaotic 11:08:10
其實這個已經有點時間了，是 cofacts 的好朋友
pofeng 12:16:38
原來如此