#cofacts
2018-02-02
@ggm https://github.com/cofacts/rumors-line-bot/issues/40 這個好像沒修好耶
現在 production 的 LINE bot 確實會擋過短字串，但只輸入網址的話是不會擋的囧
現在 production 的 LINE bot 確實會擋過短字串，但只輸入網址的話是不會擋的囧
GitHub
擋掉然後回應：「這是單純的網址，不是轉傳訊息，請從網址擷取出相關的文字資訊。」
這麼神秘 我試試看
你打什麼網址呀？我試都可以捏
你會不會打的網址是原本就搜的到內容的？
啊可能是耶
然後我按「這裡沒有一篇是我傳的訊息」
然後就可以送出資料庫了
然後就可以送出資料庫了
如果太短的話不應該要有「這裡沒有一篇是我傳的訊息」
或者是按了之後跟他說太短
或者是按了之後跟他說太短
那如果不讓他搜內容呢？@@
那之前針對該連結寫的回應就白費了呢
既然要修這個 bug 就正面修好它，在按下「這裡沒有一篇是我傳的訊息」按鈕時檢查長度。
既然要修這個 bug 就正面修好它，在按下「這裡沒有一篇是我傳的訊息」按鈕時檢查長度。
那可以在修好這個bug之前不讓他搜嗎?
噢這是之前討論到的，最早的時候是擋在搜尋前面，後來討論說要擋在搜尋後面。
但是漏掉了，他可以透過「這裡沒有一篇是我傳的訊息」來新增文章
但是漏掉了，他可以透過「這裡沒有一篇是我傳的訊息」來新增文章
我覺得不是按下的時候擋下他，而是把那張卡片顯示成。「你輸入的OOOO太短，所以 XXOXOX 不能新增噢」之類的文字。
好唷就照著 ggm 說的這麼做吧
ok go
是說 DB schema 有個 change 希望 @ggm @darkbtf review 一下唷
https://github.com/cofacts/rumors-db/pull/12
https://github.com/cofacts/rumors-db/pull/12
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...
ok 我今天晚點看
這麼神秘 我試試看
你打什麼網址呀？我試都可以捏
你會不會打的網址是原本就搜的到內容的？
啊可能是耶
然後我按「這裡沒有一篇是我傳的訊息」
然後就可以送出資料庫了
然後就可以送出資料庫了
如果太短的話不應該要有「這裡沒有一篇是我傳的訊息」
或者是按了之後跟他說太短
或者是按了之後跟他說太短
那如果不讓他搜內容呢？@@
那之前針對該連結寫的回應就白費了呢
既然要修這個 bug 就正面修好它，在按下「這裡沒有一篇是我傳的訊息」按鈕時檢查長度。
既然要修這個 bug 就正面修好它，在按下「這裡沒有一篇是我傳的訊息」按鈕時檢查長度。
那可以在修好這個bug之前不讓他搜嗎?
噢這是之前討論到的，最早的時候是擋在搜尋前面，後來討論說要擋在搜尋後面。
但是漏掉了，他可以透過「這裡沒有一篇是我傳的訊息」來新增文章
但是漏掉了，他可以透過「這裡沒有一篇是我傳的訊息」來新增文章
我覺得不是按下的時候擋下他，而是把那張卡片顯示成。「你輸入的OOOO太短，所以 XXOXOX 不能新增噢」之類的文字。
好唷就照著 ggm 說的這麼做吧
ok go
ok 我今天晚點看
2018-02-03
剛好有個空就順手擋掉了 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
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
rumors-line-bot - Line bot that checks if a message contains internet rumor.
- 💯1
ok
ok
2018-02-04
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 - -
窩操
LINE STORE
窩操
2018-02-05
這也能出
嘲諷度爆表 w
@ggm
https://github.com/cofacts/rumors-line-bot/issues/35 這個失敗了，signature mismatch 依然在發生 Orz
https://github.com/cofacts/rumors-line-bot/issues/35 這個失敗了，signature mismatch 依然在發生 Orz
我覺得應該是我 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 了！
尤其好發於超長訊息
由於訊息字串常常會被 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 了！
噢噢我好奇，所以 `raw-body` 是多做什麼事情呀？先確認 `ctx.request.charset` 之類的嗎
`ctx.req` 是 node http `Stream` 但 `checkSignature` 吃 node `Buffer` 或 string
`raw-body` 可以 http stream 轉 buffer
`raw-body` 可以 http stream 轉 buffer
ctx.req 是這個 https://nodejs.org/api/http.html#http_class_http_incomingmessage （implements Readable Stream interface）
buffer 是監聽 stream 的 events 然後一個一個 chunk 吃進來擺進陣列的那個陣列
所以你也是可以說我不要 raw-body
原本的 `captureRawBody` 的 string 改 buffer 啦
但同一份 stream 被 `captureRawBody` 弄一次，然後被 `body-parser` 也弄一次，實在滿蠢的
所以就一起拔掉了
原本的 `captureRawBody` 的 string 改 buffer 啦
但同一份 stream 被 `captureRawBody` 弄一次，然後被 `body-parser` 也弄一次，實在滿蠢的
所以就一起拔掉了
其實精確來說 body-parser 內部也是用 raw-body
我們的 use case 裡面，只需要 stream 轉 raw buffer 就好，不需要 body-parser 其他那些 content-type detection、轉 html 轉 json 轉 text 那些碗糕
所以就去掉 body-parser 只取 raw-body 囉
我們的 use case 裡面，只需要 stream 轉 raw buffer 就好，不需要 body-parser 其他那些 content-type detection、轉 html 轉 json 轉 text 那些碗糕
所以就去掉 body-parser 只取 raw-body 囉
Deployed to production on 2pm
let's see if there is any such exceptions...
let's see if there is any such exceptions...
對啊接 buffer 好像是比較萬無一失，哈哈
慘 .. qq
我看原本的回應挺好的，就補回去囉
我看原本的回應挺好的，就補回去囉
2018-02-06
@henry30270 has joined the channel
2018-02-07
Replied to a thread: 2018-02-05 12:12:22
我覺得應該是我 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 了！
尤其好發於超長訊息
由於訊息字串常常會被 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 了！
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...
噢噢我好奇，所以 `raw-body` 是多做什麼事情呀？先確認 `ctx.request.charset` 之類的嗎
`ctx.req` 是 node http `Stream` 但 `checkSignature` 吃 node `Buffer` 或 string
`raw-body` 可以 http stream 轉 buffer
`raw-body` 可以 http stream 轉 buffer
ctx.req 是這個 https://nodejs.org/api/http.html#http_class_http_incomingmessage （implements Readable Stream interface）
buffer 是監聽 stream 的 events 然後一個一個 chunk 吃進來擺進陣列的那個陣列
所以你也是可以說我不要 raw-body
原本的 `captureRawBody` 的 string 改 buffer 啦
但同一份 stream 被 `captureRawBody` 弄一次，然後被 `body-parser` 也弄一次，實在滿蠢的
所以就一起拔掉了
原本的 `captureRawBody` 的 string 改 buffer 啦
但同一份 stream 被 `captureRawBody` 弄一次，然後被 `body-parser` 也弄一次，實在滿蠢的
所以就一起拔掉了
其實精確來說 body-parser 內部也是用 raw-body
我們的 use case 裡面，只需要 stream 轉 raw buffer 就好，不需要 body-parser 其他那些 content-type detection、轉 html 轉 json 轉 text 那些碗糕
所以就去掉 body-parser 只取 raw-body 囉
我們的 use case 裡面，只需要 stream 轉 raw buffer 就好，不需要 body-parser 其他那些 content-type detection、轉 html 轉 json 轉 text 那些碗糕
所以就去掉 body-parser 只取 raw-body 囉
Deployed to production on 2pm
let's see if there is any such exceptions...
let's see if there is any such exceptions...
對啊接 buffer 好像是比較萬無一失，哈哈
哈囉你們今天開完會了？
還沒呀上面是今晚預計要討論的呢
想跟大家討論幾件事，另外 LINE 官方帳號那邊解決了嗎
沒 orz
歡迎阿端來喔，line官方帳號那裡還沒有解決
還沒我剛寄信催了一波！
QQ 結果 slack 沒跳出來所以我錯過了
你們還有什麼時候會在啊？
2/10 小聚
orz 那天要帶外國人出遊
那就要等到過年後囉！
還沒呀上面是今晚預計要討論的呢
沒 orz
歡迎阿端來喔，line官方帳號那裡還沒有解決
還沒我剛寄信催了一波！
2018-02-08
@zoe770 has joined the channel
QQ 結果 slack 沒跳出來所以我錯過了
你們還有什麼時候會在啊？
2/10 小聚
orz 那天要帶外國人出遊
嗨，想問，你們週六小聚會有人拍照記錄活動嗎？
自己會記錄～有幫手嗎www
那個……不然我也可以帶相機去，手冊要加你們的部分 2 頁，很 需 要 照 片
多 多 益 善
好唷請帶請帶
我們 Facebook 有之前的活動紀錄說
那好像不用帶了（咦）
有原檔連結嗎？手冊要印刷用的檔案
有原檔連結嗎？手冊要印刷用的檔案
等等，好像沒放相簿 QAQ
我回去傳 google photos 連結給你～
好喔感恩
自己會記錄～有幫手嗎www
那個……不然我也可以帶相機去，手冊要加你們的部分 2 頁，很 需 要 照 片
多 多 益 善
好唷請帶請帶
我們 Facebook 有之前的活動紀錄說
那好像不用帶了（咦）
有原檔連結嗎？手冊要印刷用的檔案
有原檔連結嗎？手冊要印刷用的檔案
等等，好像沒放相簿 QAQ
我回去傳 google photos 連結給你～
好喔感恩
2018-02-09
那就要等到過年後囉！
2018-02-10
現在撰寫回應，有新的功能囉！
如果「現有回應」頁籤沒有找到你要的回應，但你記得之前 Cofacts 有回應可以拿來用的話，現在可以切到「搜尋」頁籤輸入關鍵字，搜尋過去的回應並且直接加到文章囉！
如果「現有回應」頁籤沒有找到你要的回應，但你記得之前 Cofacts 有回應可以拿來用的話，現在可以切到「搜尋」頁籤輸入關鍵字，搜尋過去的回應並且直接加到文章囉！
因為今天就是小聚了，所以我把 bot 下面的 menu 更新囉
也改成不會預設打開了
也改成不會預設打開了
2018-02-12
@johan has joined the channel
2018-02-13
看到這個很無奈＝＝
- 🤷2
Hackfolder是不是壞掉了？
Yes, 後來 #general 有人回報囉
au 在修～
au 在修～
回來了
Line帳號跟貼圖那裡要想別的辦法囉，大家有什麼建議嗎
原案好像是上架賣
只是就要改合約
然後重新談拆帳怎麼做這件事情
只是就要改合約
然後重新談拆帳怎麼做這件事情
意思是acho跟設計師那裡要道歉跟重新寫合約對嗎？
如果採原案的話是這樣的沒錯 QQ
能先試著寄信給adam或monica他們試試嗎？
就道歉然後重擬合約吧？
接著其實還有也很麻煩的事情，就是 LINE@ 的申請開公司弄嗎？還是要掛在 ocf，這樣就要他們幫我們申請商標，然後再註冊。還有之後我們上架貼圖，金流也會進 ocf 這樣會拆帳拆帳再拆帳也會有點麻煩，所以需要討論一下怎做比較好
尋求另一個部門的協助也不失為一個辦法沒錯
噢噢對也是，那就要繼續等待回應
如果有這種已經被拆帳過又不需要 ocf 再開發票收據的 case，可專案來談折扣
Yes, 後來 #general 有人回報囉
au 在修～
au 在修～
原案好像是上架賣
只是就要改合約
然後重新談拆帳怎麼做這件事情
只是就要改合約
然後重新談拆帳怎麼做這件事情
意思是acho跟設計師那裡要道歉跟重新寫合約對嗎？
回來了
- 🎉1
如果採原案的話是這樣的沒錯 QQ
能先試著寄信給adam或monica他們試試嗎？
就道歉然後重擬合約吧？
接著其實還有也很麻煩的事情，就是 LINE@ 的申請開公司弄嗎？還是要掛在 ocf，這樣就要他們幫我們申請商標，然後再註冊。還有之後我們上架貼圖，金流也會進 ocf 這樣會拆帳拆帳再拆帳也會有點麻煩，所以需要討論一下怎做比較好
尋求另一個部門的協助也不失為一個辦法沒錯
噢噢對也是，那就要繼續等待回應
明晚還會開會嗎？
明晚小年夜沒有開會唷
如果有這種已經被拆帳過又不需要 ocf 再開發票收據的 case，可專案來談折扣
或是能否跟大家約線上呢
明晚小年夜沒有開會唷
2018-02-14
但我已經約了牙醫 QQ
2018-02-15
RightsCon 投稿上了呢
- 💯5
4- 🐳4
那 @mrorz 要跟我們去了嗎？ya~
我其中一個跟 cofact 有關的也上了，就再 merge 吧
go
一起住大學宿舍呀 XD
你有申請到機票補助嗎？我們可能有經費，但四月才知道
沒有呢
我的visa金融卡準備好了 (?)
我的visa金融卡準備好了 (?)
不知道有沒有 airbnb
我們目前在搜尋引擎不會是前幾名
好像是 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
好像是 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
Because they might be the cause of "spammy markup" Fixes #67
1
因為一直沒時間跟大家約，我直接先把想跟大家討論的事列這邊：
要注意的是 slackarchive 掛掉很久了，所以一週內這些訊息很可能會消失唷 QAQ
1. 上次談到把 cofacts 包裝一下讓其它東南亞有在用 LINE 的像泰國、印尼當地關注 fake news 的公民倡議團體可以用，這部分可能有經費支持
2. 6/26-27 OCF 這邊會辦一個針對 combating disinformation 給台灣與東亞公民社會的 workshop，想邀 cofacts 來合辦，例如協助規劃議程、host 部分 sessions 或有沒有其它你們覺得可以邀的單位？
1. 媒體觀察教育基金會
2. MyGoPen
3. 蘭姆酒吐司
2. MyGoPen
3. 蘭姆酒吐司
然後有辦法邀到 Google News Lab APAC 嗎
I can try!
3. 今年 4 月中，TICTeC 在葡萄亞里斯本，我們會去參加，對方邀請我們分享 cofacts 20 分鐘，但目前還沒有找到直接經費贊助，想問是否有人能自費隨團？若不能，是否能跟大家約個時間討論可以分享那些內容？從目前的回報資料庫是否有一些新的 Insight?
我的部分
5 月中要去 RightsCon
6 月下旬希望可以去 Global Fact V (Poynter 辦的，主題 100% 吻合)
4 月中還去的話覺得有點太頻繁了 QAQ
不知道有沒有其他成員有興趣呢？
5 月中要去 RightsCon
6 月下旬希望可以去 Global Fact V (Poynter 辦的，主題 100% 吻合)
4 月中還去的話覺得有點太頻繁了 QAQ
不知道有沒有其他成員有興趣呢？
4. 之前大松 mrorz 好像提到，今年要再推一次比較大的宣傳，但缺設計師 or UI？（我印象有點模糊）看是不是請揪松也幫忙找人推坑，或能不能用 1) 的經費來協助
@lucien 說年節會出 UI design 唷～
5. 更新 LINE 官方帳號的進度以及討論我們可能的協助
以上，大家新年快樂🎉
看是不是有 email 群組來 follow 這些討論，或年後我再去你們的會議
你有申請到機票補助嗎？我們可能有經費，但四月才知道
2018-02-16
1. 媒體觀察教育基金會
2. MyGoPen
3. 蘭姆酒吐司
2. MyGoPen
3. 蘭姆酒吐司
然後有辦法邀到 Google News Lab APAC 嗎
我的部分
5 月中要去 RightsCon
6 月下旬希望可以去 Global Fact V (Poynter 辦的，主題 100% 吻合)
4 月中還去的話覺得有點太頻繁了 QAQ
不知道有沒有其他成員有興趣呢？
5 月中要去 RightsCon
6 月下旬希望可以去 Global Fact V (Poynter 辦的，主題 100% 吻合)
4 月中還去的話覺得有點太頻繁了 QAQ
不知道有沒有其他成員有興趣呢？
要注意的是 slackarchive 掛掉很久了，所以一週內這些訊息很可能會消失唷 QAQ
@lucien 說年節會出 UI design 唷～
年後應該是 2/21 開會唷
是說我終於把 API refactor 完了
最後一個 bug 卡了我 7 天囧
但改了 87 個檔案，這個 PR 我在想要不要直接上惹⋯⋯
https://github.com/cofacts/rumors-api/pull/62
最後一個 bug 卡了我 7 天囧
但改了 87 個檔案，這個 PR 我在想要不要直接上惹⋯⋯
https://github.com/cofacts/rumors-api/pull/62
rumors-api - GraphQL API server for clients like rumors-site and rumors-line-bot
- 😮3
沒有呢
我的visa金融卡準備好了 (?)
我的visa金融卡準備好了 (?)
現在要來針對 staging site 做 DB migration process
( https://github.com/cofacts/rumors-db/issues/7#issuecomment-352262625 )
( https://github.com/cofacts/rumors-db/issues/7#issuecomment-352262625 )
Staging DB & API with new schema 上線囉
http://bit.ly/2GiMGjK
之後就可以支援先照 article reply count 排、再照 last requested at 的時間排了
http://bit.ly/2GiMGjK
之後就可以支援先照 article reply count 排、再照 last requested at 的時間排了
先照 article reply count 排、再照 last requested at 的時間排：
http://bit.ly/2GiIoZX
http://bit.ly/2GiIoZX
I can try!
Staging DB & API with new schema 上線囉
http://bit.ly/2GiMGjK
之後就可以支援先照 article reply count 排、再照 last requested at 的時間排了
http://bit.ly/2GiMGjK
之後就可以支援先照 article reply count 排、再照 last requested at 的時間排了
先照 article reply count 排、再照 last requested at 的時間排：
http://bit.ly/2GiIoZX
http://bit.ly/2GiIoZX
2018-02-17
@lucien @sunrise91.t3
我這裡先送了一包小的 PR，改環境變數讓 rumors-site 可以支援 staging 環境。
https://github.com/cofacts/rumors-site/pull/82
我這裡先送了一包小的 PR，改環境變數讓 rumors-site 可以支援 staging 環境。
https://github.com/cofacts/rumors-site/pull/82
Now the staging site available at <https://cofacts.hacktabl.org> with API connecting to <https://cofacts-api.hacktabl.org>
現在點進去應該會遇到一些 GraphQL error
那是因為 staging API 有改欄位所致
明天會把欄位那些改成新的
那一包 PR 就會很大了呢⋯⋯
那是因為 staging API 有改欄位所致
明天會把欄位那些改成新的
那一包 PR 就會很大了呢⋯⋯
今天成功把 staging API 與 staging site 接起來囉：
https://github.com/cofacts/rumors-site/pull/83
https://github.com/cofacts/rumors-site/pull/83
@sunrise91.t3 @lucien 求 review
現在點進去應該會遇到一些 GraphQL error
那是因為 staging API 有改欄位所致
明天會把欄位那些改成新的
那一包 PR 就會很大了呢⋯⋯
那是因為 staging API 有改欄位所致
明天會把欄位那些改成新的
那一包 PR 就會很大了呢⋯⋯
2018-02-18
Replied to a thread: 2018-02-17 22:58:40
今天成功把 staging API 與 staging site 接起來囉：
https://github.com/cofacts/rumors-site/pull/83
https://github.com/cofacts/rumors-site/pull/83
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...
@sunrise91.t3 @lucien 求 review
這個是新版 DB mappings 的測試站（staging），歡迎大家戳戳他
https://cofacts.hacktabl.org/
大家可以測的東西有
文章頁面：
- 回應
- 幫回應評分
- 把現有回應加到文章裡
- 搜尋回應之後把回應加到文章裡
- 刪除回應
回應頁面：
- 幫回應評分
- 刪除回應
已知問題：
- 刪除回應之後文章回應數要重新整理才會變 --> 這個在 UI 改版時重寫就好
- 第一次註冊好像會出現 “Unauthorized”，重新整理之後才會註冊 --> 原因不明 orz
https://cofacts.hacktabl.org/
大家可以測的東西有
文章頁面：
- 回應
- 幫回應評分
- 把現有回應加到文章裡
- 搜尋回應之後把回應加到文章裡
- 刪除回應
回應頁面：
- 幫回應評分
- 刪除回應
已知問題：
- 刪除回應之後文章回應數要重新整理才會變 --> 這個在 UI 改版時重寫就好
- 第一次註冊好像會出現 “Unauthorized”，重新整理之後才會註冊 --> 原因不明 orz
- 👍1
除了已知問題之外，請回報遇到的其他問題唷
- 👌1
2018-02-19
@ggm @acerxp511 我稍微統一了一下 unit test 的 syntax （請見 PR description）請 review 一下～
https://github.com/cofacts/rumors-line-bot/pull/56
https://github.com/cofacts/rumors-line-bot/pull/56
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...
- 🔎1
另外，
Mappings refactor 最後的修改：LINE bot API calls 調整
在這裡完成囉
https://github.com/cofacts/rumors-line-bot/pull/57
Mappings refactor 最後的修改：LINE bot API calls 調整
在這裡完成囉
https://github.com/cofacts/rumors-line-bot/pull/57
ok
另外，
Mappings refactor 最後的修改：LINE bot API calls 調整
在這裡完成囉
https://github.com/cofacts/rumors-line-bot/pull/57
Mappings refactor 最後的修改：LINE bot API calls 調整
在這裡完成囉
https://github.com/cofacts/rumors-line-bot/pull/57
Removes deprecated versions field from GetReply invocation. Replace replyConnections with articleReplies Reads positiveFeedbackCount and negativeFeedbackCount directly from API Renames CreateOrUpda...
「真的假的-staging」LINE bot 現在上面的是 mappings refactor 過後版本的程式唷。
LINE ID: @nkq3195z
歡迎大家戳戳他！
他接的資料庫跟測試站（ https://cofacts.hacktabl.org/ ） 相同，在 staging 的 bot 送出的 article 會在 https://cofacts.hacktabl.org/ 被列出。測試站資料庫跟主站分開，所以不會污染到 cofacts.g0v.tw。
LINE ID: @nkq3195z
歡迎大家戳戳他！
他接的資料庫跟測試站（ https://cofacts.hacktabl.org/ ） 相同，在 staging 的 bot 送出的 article 會在 https://cofacts.hacktabl.org/ 被列出。測試站資料庫跟主站分開，所以不會污染到 cofacts.g0v.tw。
- 🐳1
大家可以測的東西有：
- 傳送過短訊息
- 傳一篇超長文章送進資料庫（不用擔心送垃圾進去，資料庫跟主站是分開的）
- 去 https://cofacts.hacktabl.org/ 找一篇沒回過的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇只有 1 個回應的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇有很多回應、很多類似的文章去問 line bot
- 傳送過短訊息
- 傳一篇超長文章送進資料庫（不用擔心送垃圾進去，資料庫跟主站是分開的）
- 去 https://cofacts.hacktabl.org/ 找一篇沒回過的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇只有 1 個回應的文章去問 line bot
- 去 https://cofacts.hacktabl.org/ 找一篇有很多回應、很多類似的文章去問 line bot
我現在rumors-site測試台自己的回覆「刪除回應」沒顯示、「是否有幫助」是自己可點選的狀態。應該是資料格式改動的關係吧，但local我checkout到201712-mappings-refactor再merge staging-env跑run dev是正常的耶～ 我其實有點搞不清楚是怎麼回事～😅
測試站的 appId 跟 local 的 appId 應該不太一樣
所以可能會被 API 判斷成不同人
- 👌1
不過 https://cofacts.hacktabl.org/replies 一排的「有人」（user 只拿到 `null`）應該也不太正常 orz
這一點我知道為什麼啦～～
因為 migration script 根本就忘記了 users 這個 index
所以 staging 上面的 users 表其實一片空白～～
這也是為什麼大家 staging 都像沒註冊過一樣
囧
https://github.com/cofacts/rumors-db/blob/master/db/migrations/201712-001-reindex.js <-- 完全沒 reindex `users`
因為 migration script 根本就忘記了 users 這個 index
所以 staging 上面的 users 表其實一片空白～～
這也是為什麼大家 staging 都像沒註冊過一樣
囧
https://github.com/cofacts/rumors-db/blob/master/db/migrations/201712-001-reindex.js <-- 完全沒 reindex `users`
理論上你在 staging site 自己發的訊息，他應該會認得得才是正常的
我可能要 trace 一下 API 那裡到底發生什麼事 QQ
了解～ 晚點再試試～
這一點我知道為什麼啦～～
因為 migration script 根本就忘記了 users 這個 index
所以 staging 上面的 users 表其實一片空白～～
這也是為什麼大家 staging 都像沒註冊過一樣
囧
https://github.com/cofacts/rumors-db/blob/master/db/migrations/201712-001-reindex.js <-- 完全沒 reindex `users`
因為 migration script 根本就忘記了 users 這個 index
所以 staging 上面的 users 表其實一片空白～～
這也是為什麼大家 staging 都像沒註冊過一樣
囧
https://github.com/cofacts/rumors-db/blob/master/db/migrations/201712-001-reindex.js <-- 完全沒 reindex `users`
2018-02-20
staging db 被我弄壞了 orz
修理中
修理中
Fixed
2018-02-21
ok
我們今天晚上 8pm 開會唷，請問 @ttcat 會來嗎
今天爆炸，晚上有 community hangout
我橋一下看八點跟你們 hangout?
八點準點
- 👍4
那就拜託嚕 🙂
hackmd.io 
Mr.Market市場先生
「市場先生，你覺得畫Line貼圖能賺錢嗎?」 「要爆紅才行吧，不過有畫才有機會！」 上次和一位美術系的學生， …
2018-02-22
LINE bot 與網站均已下線
開始進行 migration
開始進行 migration
2018-02-21 15:31:37.826 420 <134>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 <134>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 <134>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 <134>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 <158>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 <45>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 <45>1 2018-02-21T17:01:35.564137+00:00 heroku web.1 - - Restarting 2018-02-21 17:01:43.011 137 <45>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 <190>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 <190>1 2018-02-21T17:01:48.286877+00:00 app web.1 - - [PM2] Log streaming started
migration 已經完成囉！
是說昨天 migration 一陣慌忙，忘記換 production server 的 docker engine 版本
現在版本是 1.12 超舊，連 `docker prune` 指令都沒有，然後硬碟快滿了 Orz
現在版本是 1.12 超舊，連 `docker prune` 指令都沒有，然後硬碟快滿了 Orz
關於這個功能在技術上怎麼實做，我在思考一件事情：
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` 傳入資料庫。
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` 傳入資料庫。
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"
不能直接用articleID當url param找userID和appID嗎?
有道理耶，這招不錯。
雖然會要多撈一次資料庫（在 API 裡先拿 `articleId` 撈 `userId` + `appId`）但我覺得不會太 costy。
拿 `articleId` 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 `articleId` 會是個相當合適的解。
雖然會要多撈一次資料庫（在 API 裡先拿 `articleId` 撈 `userId` + `appId`）但我覺得不會太 costy。
拿 `articleId` 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 `articleId` 會是個相當合適的解。
後來想想正確的解法應該是要避免 `userId` 用敏感資料來表示。
這樣如果未來用會到email的話，就要再建一張 `userId` 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。
這樣如果未來用會到email的話，就要再建一張 `userId` 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。
其實如果是網站的使用者（有經過 FB / Twitter / Github 註冊），就會記在 `users` 資料表裡了，此時 `userId` 是 `users` 資料表的 ID，不是敏感資料。不過 LINE 的使用者（ `userId` + `appId`）是沒有在 `users` 資料表裡的。
之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 `users` 資料表新增 line user id 欄位的方式。
之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 `users` 資料表新增 line user id 欄位的方式。
如果我不想 expose `userId` 出來，又要能夠 expose 個東西放進 URL，最好的方法是用個 key 來加密嗎？
2018-02-23
不能直接用articleID當url param找userID和appID嗎?
有道理耶，這招不錯。
雖然會要多撈一次資料庫（在 API 裡先拿 `articleId` 撈 `userId` + `appId`）但我覺得不會太 costy。
拿 `articleId` 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 `articleId` 會是個相當合適的解。
雖然會要多撈一次資料庫（在 API 裡先拿 `articleId` 撈 `userId` + `appId`）但我覺得不會太 costy。
拿 `articleId` 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 `articleId` 會是個相當合適的解。
後來想想正確的解法應該是要避免 `userId` 用敏感資料來表示。
這樣如果未來用會到email的話，就要再建一張 `userId` 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。
這樣如果未來用會到email的話，就要再建一張 `userId` 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。
其實如果是網站的使用者（有經過 FB / Twitter / Github 註冊），就會記在 `users` 資料表裡了，此時 `userId` 是 `users` 資料表的 ID，不是敏感資料。不過 LINE 的使用者（ `userId` + `appId`）是沒有在 `users` 資料表裡的。
之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 `users` 資料表新增 line user id 欄位的方式。
之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 `users` 資料表新增 line user id 欄位的方式。
2018-02-24
@chewei has joined the channel
2018-02-25
飛機都不來
google 與 FB 上不了
只好來發 PR
求 review
https://github.com/cofacts/rumors-api/pull/68
https://github.com/cofacts/rumors-db/pull/13
google 與 FB 上不了
只好來發 PR
求 review
https://github.com/cofacts/rumors-api/pull/68
https://github.com/cofacts/rumors-db/pull/13
This PR enables ListArticles to show only articles by a specified author. For spec please see #65 . Fixes #65
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 ...
- 🚀1
2018-02-27
@lucien @sunrise91.t3 我想測測看這到底會不會對 SEO 有影響
所以就 merge 囉
https://github.com/cofacts/rumors-site/pull/81
所以就 merge 囉
https://github.com/cofacts/rumors-site/pull/81
Because they might be the cause of "spammy markup" Fixes #67
- 👍1
糟糕，旅館速度太慢沒辦法 deploy Orz
結果我的 reconsideration request 收到了 rejection QAQ
說問題一樣是 spammy markup
https://support.google.com/webmasters/answer/3498001?ctx=MAC
說問題一樣是 spammy markup
https://support.google.com/webmasters/answer/3498001?ctx=MAC
糟糕，旅館速度太慢沒辦法 deploy Orz
- 😅1
orz , 又來了一個謠言查證網站 ... http://www.rumtoast.com/
蘭姆酒吐司
蘭姆酒吐司 蘭姆酒（RUM）是來自謠言(RUMOR)的字首，吐司則是取自真相（TRUTH)的諧音，我們的使命就是專門擊破網路謠言，還原真相，並督促各位繼續享受生命中的美好事物。
其實這個已經有點時間了，是 cofacts 的好朋友
原來如此
其實這個已經有點時間了，是 cofacts 的好朋友
- 👍3
原來如此
hey all, 上禮拜討論的事情後續有結論嗎
Hello 阿端，不好意思回覆晚了。有關6/26-6/27的Combating Disinformation workshop，我們很願意協助，不過因為有提到是「合辦」，有幾點想要請問一下：
1. 「合辦」的想像是到什麼樣的程度呢？是包括議程設計、單位邀約、課程設計與行銷等等嗎？
2. OCF對於這次的workshop是否已經有一些討論議題上的想像呢？
3. 除了Cofact之外，是否也會有其他不同領域「合辦」的夥伴呢？那麼預計分工會是什麼呢？
我們覺得這是很有意義的一場活動，所以更希望能確認能在其中扮演什麼樣的角色，也要請阿端幫忙解惑了！
感謝！！
1. 「合辦」的想像是到什麼樣的程度呢？是包括議程設計、單位邀約、課程設計與行銷等等嗎？
2. OCF對於這次的workshop是否已經有一些討論議題上的想像呢？
3. 除了Cofact之外，是否也會有其他不同領域「合辦」的夥伴呢？那麼預計分工會是什麼呢？
我們覺得這是很有意義的一場活動，所以更希望能確認能在其中扮演什麼樣的角色，也要請阿端幫忙解惑了！
感謝！！
1. 參與整體議程的設計過程、設計一堂專門針對 Cofacts 的課程，參與我們最後決定補助哪些團體來與會的過程
2. 有，還不太多，可另開頻道再一起共筆
3. 會，目前想到可能主要的合作夥伴會是 SEAPA (South East Asia Press Alliance)、EngageMedia、Innovation for Change East Asia
預計的分工是除了共同參與議程設計之外，也請他們協助各自負擔 1個 sessions，然後幫我們向東亞的參與者宣傳
所以關於 1. 英文 & 包裝 cofacts for east asia 這個大家想做嗎？2. LINE 帳號需要我們協助嗎？
Hihi 阿端，不好意思現在才發現訊息沒有傳回去給你。三件事情更新
1. 有關工作坊，我們這邊願意幫忙，可以協助分享我們的執行經驗與依據議程協助邀請適合的分享對象。不知道議程部分是否已經有相關進度了嘛？
2. 英文包裝這部分，是否提供多一點的資訊，我們比較能著手評估有哪些工作事項。
3. Line的部分接洽中，目前有一點進展，謝謝阿端
1. 有關工作坊，我們這邊願意幫忙，可以協助分享我們的執行經驗與依據議程協助邀請適合的分享對象。不知道議程部分是否已經有相關進度了嘛？
2. 英文包裝這部分，是否提供多一點的資訊，我們比較能著手評估有哪些工作事項。
3. Line的部分接洽中，目前有一點進展，謝謝阿端
關於 1 與 2 下週三晚上我去找大家當面聊？
另外為了里斯本的會議我也需要另外訪談一下大家
另外，柏峰說個人也可以申請商標（但如果要透過 ocf 去申請 line 認證帳號，我想可能商標的 ownership 必須是在 OCF，我們做也ＯＫ）
Hello 阿端，不好意思回覆晚了。有關6/26-6/27的Combating Disinformation workshop，我們很願意協助，不過因為有提到是「合辦」，有幾點想要請問一下：
1. 「合辦」的想像是到什麼樣的程度呢？是包括議程設計、單位邀約、課程設計與行銷等等嗎？
2. OCF對於這次的workshop是否已經有一些討論議題上的想像呢？
3. 除了Cofact之外，是否也會有其他不同領域「合辦」的夥伴呢？那麼預計分工會是什麼呢？
我們覺得這是很有意義的一場活動，所以更希望能確認能在其中扮演什麼樣的角色，也要請阿端幫忙解惑了！
感謝！！
1. 「合辦」的想像是到什麼樣的程度呢？是包括議程設計、單位邀約、課程設計與行銷等等嗎？
2. OCF對於這次的workshop是否已經有一些討論議題上的想像呢？
3. 除了Cofact之外，是否也會有其他不同領域「合辦」的夥伴呢？那麼預計分工會是什麼呢？
我們覺得這是很有意義的一場活動，所以更希望能確認能在其中扮演什麼樣的角色，也要請阿端幫忙解惑了！
感謝！！
1. 參與整體議程的設計過程、設計一堂專門針對 Cofacts 的課程，參與我們最後決定補助哪些團體來與會的過程
2. 有，還不太多，可另開頻道再一起共筆
3. 會，目前想到可能主要的合作夥伴會是 SEAPA (South East Asia Press Alliance)、EngageMedia、Innovation for Change East Asia
預計的分工是除了共同參與議程設計之外，也請他們協助各自負擔 1個 sessions，然後幫我們向東亞的參與者宣傳
所以關於 1. 英文 & 包裝 cofacts for east asia 這個大家想做嗎？2. LINE 帳號需要我們協助嗎？
2018-02-28
Replied to a thread: 2018-02-27 05:12:02
結果我的 reconsideration request 收到了 rejection QAQ
說問題一樣是 spammy markup
https://support.google.com/webmasters/answer/3498001?ctx=MAC
說問題一樣是 spammy markup
https://support.google.com/webmasters/answer/3498001?ctx=MAC
support.google.com
If you see this message on the Manual Actions page, it means that Google has detected some of the markup on your pages may be using techniques that are outside our
不知道大家還記不記得
之前大家拿謠言去 google，cofacts 永遠會在第一頁這件事情
但最近都比較少出現了呢
我懷疑就是 spammy markup 造成的
I think it’s bad.
之前大家拿謠言去 google，cofacts 永遠會在第一頁這件事情
但最近都比較少出現了呢
我懷疑就是 spammy markup 造成的
I think it’s bad.
