#cofacts
2020-04-01
cofacts 好厲害！ https://cacm.acm.org/magazines/2020/4/243640-detecting-fake-news-in-social-media/fulltext
cacm.acm.org
Many of the latest techniques to automatically debunk fake news were initiated in the Asia and Oceania region.
- 🐳4
感謝分享~~~
文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
Gan不都是生圖像，生文章可以嗎
文章可能還有點難，詩和句子的話有：https://www.ai-fragments.com/
寫小說的有 不過就是沒有中文的 而且有時候前後文不太有關聯
Replied to a thread: 2020-04-01 00:40:19
感謝分享~~~
文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
- 😂1
- 🐛1
話說 GAN 不是 deep fake 的核心技術之一嗎
那 GAN 生成的針對 deep fake 的闢謠
484 該叫 deep fake fake (?)
那 GAN 生成的針對 deep fake 的闢謠
484 該叫 deep fake fake (?)
Deep fact如何 XD
可是這種迭代本身就是 GAN 架構的一部份不是嗎 😅
對 lol
Gan不都是生圖像，生文章可以嗎
AI Fragments 
對 lol
今天會議記錄：https://g0v.hackmd.io/IS6_Qg6pQFK6uorTtatZ7w
要決定小聚、還有 LINE bot 的一些 memory issue 討論。
我跟比鄰今天會在 Workis，然後也會開 Powercall ( https://tico.chat/powercall?room=cofactshack&type=timeFirst ) 唷。
要決定小聚、還有 LINE bot 的一些 memory issue 討論。
我跟比鄰今天會在 Workis，然後也會開 Powercall ( https://tico.chat/powercall?room=cofactshack&type=timeFirst ) 唷。
tico.chat
The considerate messenger. Chat with whom you care about always at the best moments and times
我今天要請假，我公司今天要趕東西上線
好喔平安
今天晚上開會嗎？
我今天要請假，我公司今天要趕東西上線
開會唷
好喔平安
剛才電腦斷電
現在回來惹
現在回來惹
@acerxp511 還在嗎 ~~
@acerxp511 還在嗎 ~~
Figma
我有聽到聲音
法人名字規定
https://m.facebook.com/story.php?story_fbid=227849687561011&substory_index=0&id=203494753329838
過去的討論串
https://beta.hackfoldr.org/cofacts/https%3A%2F%2Fhackmd.io%2Fs%2FH1we3AgTg
https://github.com/cofacts/rumors-api/issues/28
- 真的假的研究會
- 台灣公民科技協作查核協進會 / 協核會
https://m.facebook.com/story.php?story_fbid=227849687561011&substory_index=0&id=203494753329838
過去的討論串
https://beta.hackfoldr.org/cofacts/https%3A%2F%2Fhackmd.io%2Fs%2FH1we3AgTg
https://github.com/cofacts/rumors-api/issues/28
- 真的假的研究會
- 台灣公民科技協作查核協進會 / 協核會
m.facebook.com
【協會名稱】 取名時應注意： ＊若是地區性的，要加上台北市..等 ＊若是全國性的，要加上＂台灣＂或＂中華民國＂等字樣。 ＊在未立案前，先不需加上＂社團法人＂字樣，這是於立案完成後，再去法院申請的法人身份。 ＝＝＝＝＝＝＝＝ 內政部關於名稱的規則如下： ＊名稱得使用部分非中國文字或部分簡稱(如：E時代)，但仍以使用中文全稱並開頭冠以組織區域為宜。...
2020-04-02
@mchen15 has joined the channel
`協核會` 😄
十劦木亥協會
鞋盒會
寫小說的有 不過就是沒有中文的 而且有時候前後文不太有關聯
Deep fact如何 XD
spark joy
目前 LINE bot state diagram 長這樣：https://docs.google.com/drawings/d/1GIuprSEGpthMW6KuCgawMky5Nnxm7P7mlxeODPdA-lI/edit
根據 3/25 的討論，我們會用 LIFF 來詢問文章來源與理由。
重新設計之後，新的 LINE bot state diagram 會像這樣：https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit
幾個重點：
• 共有三種 LIFF： LIFF asking source (詢問文章來源)、reason LIFF (送出文章理由)、feedback LIFF (覺得回應有用的建議或沒用的理由)
• 送出 article, reply request 與 feedback 的流程思維改變：從先問理由(選填)才送出，改成先送出、才問理由。回到 `__INIT__` state 時，也能叫出 LIFF 修改 reason / feedback。這也導致了 state diagram 的簡化，直接刪除了 `ASKING_XXX_REASON` 的 2 個 state。
• 在 LIFF 裡的動作（選擇選項、送出文字）都會透過 LIFF send message API 傳回聊天視窗做紀錄；同時 chatbot server 也會把握這個機會拿到新的 reply token 送新東西（也就是 state diagram action 裡的 “reply with” 敘述）
• 光是顯示 LIFF 是無法回應使用者的，但可以在 LIFF 載入時打 API 進行動作（如 create feedback）
• 設計時需考量到使用者跳出 LIFF 之後怎麼回來接關。
根據 3/25 的討論，我們會用 LIFF 來詢問文章來源與理由。
重新設計之後，新的 LINE bot state diagram 會像這樣：https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit
幾個重點：
• 共有三種 LIFF： LIFF asking source (詢問文章來源)、reason LIFF (送出文章理由)、feedback LIFF (覺得回應有用的建議或沒用的理由)
• 送出 article, reply request 與 feedback 的流程思維改變：從先問理由(選填)才送出，改成先送出、才問理由。回到 `__INIT__` state 時，也能叫出 LIFF 修改 reason / feedback。這也導致了 state diagram 的簡化，直接刪除了 `ASKING_XXX_REASON` 的 2 個 state。
• 在 LIFF 裡的動作（選擇選項、送出文字）都會透過 LIFF send message API 傳回聊天視窗做紀錄；同時 chatbot server 也會把握這個機會拿到新的 reply token 送新東西（也就是 state diagram action 裡的 “reply with” 敘述）
• 光是顯示 LIFF 是無法回應使用者的，但可以在 LIFF 載入時打 API 進行動作（如 create feedback）
• 設計時需考量到使用者跳出 LIFF 之後怎麼回來接關。
- 🦒1
- 🐳1
- 🚀1
1. 個人頁技術上想實作使用者之間的 follow ，具體上功能 follower 可以看到主人的查核消息
2. 列表分頁根據現在的技術架構，決定使用 infinite scroll ，如果有餘力改成多頁 (offset )形式再試試
3. 等級名字重新徵求討論，因為我們接下來要來畫等級 badge ，有些看起來意義不明 https://github.com/cofacts/rumors-site/blob/dev/constants/levelNames.js
2. 列表分頁根據現在的技術架構，決定使用 infinite scroll ，如果有餘力改成多頁 (offset )形式再試試
3. 等級名字重新徵求討論，因為我們接下來要來畫等級 badge ，有些看起來意義不明 https://github.com/cofacts/rumors-site/blob/dev/constants/levelNames.js
GitHub
Rumors list / creation UI, with server-side rendering - cofacts/rumors-site
1
follow 可以用 RSS 訂閱就好ㄇ
缺點 (也不一定是缺點) 是不知道誰是 followee
想要介面上導入社交性，我覺得可以存mongodb
我自己是有遇過「這個編輯寫的東西不太 ok，所以他出東西我想要第一個知道」的需求，但這種時候我不想跟那個編輯交朋友 XD”
哈哈好
那RSS可以滿足你的需求
我現在要做的方向是強化編輯的主體性
所以之後組織帳號跟個人職業認證會慢慢導入
我覺得無可避免會需要新的資料庫
2020-04-03
follow 可以用 RSS 訂閱就好ㄇ
缺點 (也不一定是缺點) 是不知道誰是 followee
想要介面上導入社交性，我覺得可以存mongodb
我自己是有遇過「這個編輯寫的東西不太 ok，所以他出東西我想要第一個知道」的需求，但這種時候我不想跟那個編輯交朋友 XD”
哈哈好
那RSS可以滿足你的需求
我現在要做的方向是強化編輯的主體性
- 🐳1
所以之後組織帳號跟個人職業認證會慢慢導入
我覺得無可避免會需要新的資料庫
- 👌1
@jmonk has joined the channel
LINE bot server 的 GraphQL 與目錄結構也訂好了：
https://g0v.hackmd.io/860RnxUGTi6z2Kca6ojAbg?both#LIFF-API
為了因應增加 LIFF & GraphQL API，之後 rumors-line-bot 的目錄結構會調整如下：
- `/liff`: 資料夾位置不變，但裡頭改成 svelte client-side app config w/ Webpack
- `/i18n`: 資料夾位置不變。
- `/src`: Chatbot server 本體。
- `index`: koa server 進入點。
- `handleInput`, `handlers/`, `checkSignagureAndParse`, `lineClinet`: 移動到 `/src/webhook`，亦即 LINE messaging API webhook。`/src/webhook/index` 擺放目前在 `src/index` 裡的 `singleUserHandler()`、`groupHandler()`、`processText()` 邏輯，使 koa server 進入點不要放太複雜的 middleware logic.
- 新增 `src/graphql` 放 Apollo server 相關 typedefs；`src/graphql/index` 為 GraphQL API request handling middleware。
- `ga`, `gql`, `redisClient`, `rollbar`: `graphql` 與 `webhook` 共用的東西，移動到 `/src/lib`
https://g0v.hackmd.io/860RnxUGTi6z2Kca6ojAbg?both#LIFF-API
為了因應增加 LIFF & GraphQL API，之後 rumors-line-bot 的目錄結構會調整如下：
- `/liff`: 資料夾位置不變，但裡頭改成 svelte client-side app config w/ Webpack
- `/i18n`: 資料夾位置不變。
- `/src`: Chatbot server 本體。
- `index`: koa server 進入點。
- `handleInput`, `handlers/`, `checkSignagureAndParse`, `lineClinet`: 移動到 `/src/webhook`，亦即 LINE messaging API webhook。`/src/webhook/index` 擺放目前在 `src/index` 裡的 `singleUserHandler()`、`groupHandler()`、`processText()` 邏輯，使 koa server 進入點不要放太複雜的 middleware logic.
- 新增 `src/graphql` 放 Apollo server 相關 typedefs；`src/graphql/index` 為 GraphQL API request handling middleware。
- `ga`, `gql`, `redisClient`, `rollbar`: `graphql` 與 `webhook` 共用的東西，移動到 `/src/lib`
- 👍2
2020-04-04
Replied to a thread: 2020-04-03 17:20:48
As planned in redesign doc, we are restructuring files to make room for GraphQL APIs. This is the prerequisite for #144 . Changes include: Introduce babel-plugin-module-resolver and pin resolve ro...
LINE bot server GraphQL: https://github.com/cofacts/rumors-line-bot/pull/168
因為 LIFF API 要 auth 比較複雜，所以先寫了不用 auth 的東西（之前提到的公開 insight API）來建立 LINE bot graphql server 與 unit test 架構，請過目。
PR base 暫時戳進 #167 的 branch，這樣 code diff 比較單純、比較好 review；167 進了之後這個 PR 也會把 base 改到 `dev`。
因為 LIFF API 要 auth 比較複雜，所以先寫了不用 auth 的東西（之前提到的公開 insight API）來建立 LINE bot graphql server 與 unit test 架構，請過目。
PR base 暫時戳進 #167 的 branch，這樣 code diff 比較單純、比較好 review；167 進了之後這個 PR 也會把 base 改到 `dev`。
This PR adds simple APIs that do not need nonce, and adds unit tests setup. Fixes #155 Input { insights { messageDelivery(date: "20200401") { status broadcast targ...
```// Export for custom resolveEdges() and resolveLastCursor()
//
export function getCursor(cursor) {
return Buffer.from(JSON.stringify(cursor)).toString('base64');
}
export function getSearchAfterFromCursor(cursor) {
if (!cursor) return undefined;
return JSON.parse(Buffer.from(cursor, 'base64').toString('utf8'));
}```
//
export function getCursor(cursor) {
return Buffer.from(JSON.stringify(cursor)).toString('base64');
}
export function getSearchAfterFromCursor(cursor) {
if (!cursor) return undefined;
return JSON.parse(Buffer.from(cursor, 'base64').toString('utf8'));
}```
@mrorz 為什麼要做 base64 的 serialize 呀？elasticsearch 不是直接丟 array 進去嗎？
我的 articleCategoriesByCategoryIdLoaderFactory 的 pagination 是直接吃 array 進去，我有點不懂為什麼要轉 base64 XD
然後我不確定 Category.articleCategories 不知道要不要用 loader，或是維持現在就好
然後 PR 我也更新了 https://github.com/cofacts/rumors-api/pull/156
@ggm cursor 加 base64 是 Facebook 官方推薦這麼做的：
> As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
> As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
其他用到 cursor 的都有這麼作呢
雖然可能比較正規的做法是寫個 custom scalar 給 `Cursor`
parse value / serialize 的時候就直接 base64 轉進轉出
就可以不用在 resolver 裡面處理這個了
parse value / serialize 的時候就直接 base64 轉進轉出
就可以不用在 resolver 裡面處理這個了
噢噢原來是 graphql 的建議
PR 又更新啦～
我的 articleCategoriesByCategoryIdLoaderFactory 的 pagination 是直接吃 array 進去，我有點不懂為什麼要轉 base64 XD
然後我不確定 Category.articleCategories 不知道要不要用 loader，或是維持現在就好
然後 PR 我也更新了 https://github.com/cofacts/rumors-api/pull/156
@ggm cursor 加 base64 是 Facebook 官方推薦這麼做的：
> As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
> As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
graphql.org
GraphQL provides a complete description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
其他用到 cursor 的都有這麼作呢
雖然可能比較正規的做法是寫個 custom scalar 給 `Cursor`
parse value / serialize 的時候就直接 base64 轉進轉出
就可以不用在 resolver 裡面處理這個了
parse value / serialize 的時候就直接 base64 轉進轉出
就可以不用在 resolver 裡面處理這個了
噢噢原來是 graphql 的建議
LINE bot server GraphQL 加上 user context API 與 auth 邏輯囉：
https://github.com/cofacts/rumors-line-bot/pull/169
https://github.com/cofacts/rumors-line-bot/pull/169
This PR implements a GraphQL API, Query.context, that will replace the current /context/:userId API endpoint. As designed in design doc, we authenticate the user by Authorization header. When userI...
2020-04-05
昨天想到，使用者選到一則沒回應的訊息有兩種情形：
1. 有複數篇訊息符合搜尋，而使用者點到沒有回應的那篇
2. 只有一篇訊息符合搜尋
2 的行為，現在是直接跳到「沒有回應噎，請按『我也想知道』」這一步。
我思考了一下，原本 （3/25 會議時提出的） 1 直接打開 LIFF 的設計，其實也要處理「把使用者選了這一則訊息（`selectedArticleId`）存進 context」這件事。但是，目前 chatbot webhook 的設計都是「回應時一併 mutate state 與 context」，但這個設計會需要在不改 state 的情形之下修改 context，我覺得設計上不是很好。況且，2 「只有一篇訊息符合」的 case 也無法解決，因為我們沒辦法在回應訊息時直接打開 LIFF，無論如何都要吐一個按鈕出去讓使用者點才行。
因此我還是把 `ASKING_REPLY_REQUEST_REASON` 這個 state 加回來了：
https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit
• `CHOOSING_ARTICLE` 下，不管是上面 1 還是 2 的狀況，都會轉移到 `ASKING_REPLY_REQUEST_REASON` state 並且設定 `selectedArticleId`
• state 轉移的當下就會送出 reply request。
• 作為 reply，我們會告訴使用者「抱歉『ooooo』這一篇還沒有回應，已經幫你提交需求」、並且問使用者願不願意提供更多資訊幫助編輯闢謠（一個按鈕）；按鈕會展開 LIFF asking source。
• 續上，使用者在 `CHOOSING_ARTICLE` 下到底選了「哪一篇」在對話視窗裡面就會有個紀錄（LIFF 下比較麻煩還要 `sendMessage`）
這樣一來，整個流程也會與流程圖右邊的 `ASKING_ARTICLE_SUBMISSION_CONSENT` 更為接近，但差異是 reply request 會在進入`ASKING_REPLY_REQUEST_REASON` 之前就會觸發（加速 1 人回報 --> N 人回報的過程，反應實際流傳度 ），而送出文章是在離開 `ASKING_ARTICLE_SUBMISSION_CONSENT` state 的時候才會觸發。
1. 有複數篇訊息符合搜尋，而使用者點到沒有回應的那篇
2. 只有一篇訊息符合搜尋
2 的行為，現在是直接跳到「沒有回應噎，請按『我也想知道』」這一步。
我思考了一下，原本 （3/25 會議時提出的） 1 直接打開 LIFF 的設計，其實也要處理「把使用者選了這一則訊息（`selectedArticleId`）存進 context」這件事。但是，目前 chatbot webhook 的設計都是「回應時一併 mutate state 與 context」，但這個設計會需要在不改 state 的情形之下修改 context，我覺得設計上不是很好。況且，2 「只有一篇訊息符合」的 case 也無法解決，因為我們沒辦法在回應訊息時直接打開 LIFF，無論如何都要吐一個按鈕出去讓使用者點才行。
因此我還是把 `ASKING_REPLY_REQUEST_REASON` 這個 state 加回來了：
https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit
• `CHOOSING_ARTICLE` 下，不管是上面 1 還是 2 的狀況，都會轉移到 `ASKING_REPLY_REQUEST_REASON` state 並且設定 `selectedArticleId`
• state 轉移的當下就會送出 reply request。
• 作為 reply，我們會告訴使用者「抱歉『ooooo』這一篇還沒有回應，已經幫你提交需求」、並且問使用者願不願意提供更多資訊幫助編輯闢謠（一個按鈕）；按鈕會展開 LIFF asking source。
• 續上，使用者在 `CHOOSING_ARTICLE` 下到底選了「哪一篇」在對話視窗裡面就會有個紀錄（LIFF 下比較麻煩還要 `sendMessage`）
這樣一來，整個流程也會與流程圖右邊的 `ASKING_ARTICLE_SUBMISSION_CONSENT` 更為接近，但差異是 reply request 會在進入`ASKING_REPLY_REQUEST_REASON` 之前就會觸發（加速 1 人回報 --> N 人回報的過程，反應實際流傳度 ），而送出文章是在離開 `ASKING_ARTICLE_SUBMISSION_CONSENT` state 的時候才會觸發。
他們倒站吧
他們倒站吧
LIFF 用 mutation API 的 PR:
https://github.com/cofacts/rumors-line-bot/pull/170
mutation API 砍到剩兩隻。
其實我覺得 `submitArticle` 應該也沒有需要，使用者 LIFF 裡點擊 source 之後會 send message，我們應該在這個 send message 的 webhook 裡面送出文章就好，不需要透過 GraphQL。 因為送出 article 需要 article ID 才能產出 webhook 回應，不如直接在 webhook 裡送出文章拿 article ID，會比做在 LIFF 直接。
https://github.com/cofacts/rumors-line-bot/pull/170
mutation API 砍到剩兩隻。
其實我覺得 `submitArticle` 應該也沒有需要，使用者 LIFF 裡點擊 source 之後會 send message，我們應該在這個 send message 的 webhook 裡面送出文章就好，不需要透過 GraphQL。 因為送出 article 需要 article ID 才能產出 webhook 回應，不如直接在 webhook 裡送出文章拿 article ID，會比做在 LIFF 直接。
This PR implements submitArticle and voteReply mutation, which are invoked directly in LIFF.
想了想還是砍掉 `submitArticle` 讓 API 單純些。
想了想還是砍掉 `submitArticle` 讓 API 單純些。
2020-04-06
十劦木亥協會
2020-04-07
@fiona.hgworld has joined the channel
PR 又更新啦～
2020-04-08
category API 可以 merge 了！！
不過有個大問題：UI 端的 article list category filter PR 一定會跟 @yanglin5689446 正在實作的 article list 撞⋯⋯
https://github.com/cofacts/rumors-site/pull/218
這裏有什麼進行 merge 的想法嗎 QQ
不過有個大問題：UI 端的 article list category filter PR 一定會跟 @yanglin5689446 正在實作的 article list 撞⋯⋯
https://github.com/cofacts/rumors-site/pull/218
這裏有什麼進行 merge 的想法嗎 QQ
Implements part of #213 . This PR also moves ArticleListPage components to under components/ArticleListPage, so that article list logics are not mixed up with component implementation in pages/art...
- ❤️1
- 🦒1
- 🐳1
我在想是不是該直接丟掉這個 article list PR 然後直上 @yanglin5689446 的 article list
然後還沒拉皮的 article detail 可以 merge (但沒人 review 囧)
https://github.com/cofacts/rumors-site/pull/234
https://github.com/cofacts/rumors-site/pull/234
Implements Article page UI in #213. List article categories under article text & reply request list. The person adding the category (canUpdateStatus === true) can remove category (has delete b...
conflict resolved, 求 review
另外，這裡有升級 next.js 來修正 vulnerability 的 PR。
升級時也同時有丟掉一些 polyfill
https://github.com/cofacts/rumors-site/pull/245
升級時也同時有丟掉一些 polyfill
https://github.com/cofacts/rumors-site/pull/245
This PR contains the following updates: Package Type Update Change next (source) dependencies minor 9.1.2 -> 9.3.2 GitHub Vulnerability Alerts CVE-2020-5284 Impact Not affected: Deplo...
這個先 merge 了，我其他 PR 要用裡面的東西
衝撞可以我 merge 或 rebase
如果你 article list 已經開工了的話那理論上我 article list 那個 PR 應該可以不用進
你可以看看有沒有什麼 refactor 值得揀進你的 branch 裡，然後我的 article list PR 就直接 close without merge?
你可以看看有沒有什麼 refactor 值得揀進你的 branch 裡，然後我的 article list PR 就直接 close without merge?
- 👌1
好那我 cherry pick 進來改
article page 的倒是可以 review 一下，沒問題就進
navbar ui 的 PR 只差修 conflict 囉
@ggm category API 要 work 的話，至少會需要把新的 article category feedback, category 等空 index migrate 到 production DB
會需要一個 migration script 建立這些欄位與 index 呢
會需要一個 migration script 建立這些欄位與 index 呢
這個先 merge 了，我其他 PR 要用裡面的東西
Replied to a thread: 2020-04-08 00:02:13
conflict resolved, 求 review
Channel access token API 更新
https://developers.line.biz/zh-hant/news/2020/04/06/channel-access-token-apis-v2-1/
https://developers.line.biz/zh-hant/news/2020/04/06/channel-access-token-apis-v2-1/
developers.line.biz
We released the latest version of the channel access token. This new version lets the user specify the expiration date and also provides security enhancements by switching to using a JSON Web Token (J...
@oguzhan has joined the channel
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A2019
@lucien @yanglin5689446 @mrorz 本週主要針對搜尋頁面做補強
有任何問題麻煩隨時跟我說唷～
@lucien @yanglin5689446 @mrorz 本週主要針對搜尋頁面做補強
有任何問題麻煩隨時跟我說唷～
- ❤️3
- 🦒1
- 👍1
2020-04-09
LINE user 呈現在網站上的頭像與假名生成
https://g0v.hackmd.io/7ERem43XREWJPOjjdE28SQ
https://g0v.hackmd.io/7ERem43XREWJPOjjdE28SQ
那個名字生成出來好像會變得有些中二
這…. 出現手繪賓果機
對呀我覺得他們的 generator 字典很棒
只是不知道能不能直接拿來用 XDD
只是不知道能不能直接拿來用 XDD
我記得他們固定是用「來自${place}的${adj}${name}」
repo 沒有 LICENSE 哭哭
那個名字生成出來好像會變得有些中二
- 😂1
這…. 出現手繪賓果機
A novel debate platform with intuitive opinion visualization. - PlatoForum/PlatoForum
對呀我覺得他們的 generator 字典很棒
只是不知道能不能直接拿來用 XDD
只是不知道能不能直接拿來用 XDD
我記得他們固定是用「來自${place}的${adj}${name}」
repo 沒有 LICENSE 哭哭
https://github.com/PlatoForum/PlatoForum/blob/2cdc807a6ec54f68e0479787ccb865f0e89aed50/utils/pseudonym_gen/import_heroku.sh mongodb 帳號密碼耶 @@
A novel debate platform with intuitive opinion visualization. - PlatoForum/PlatoForum
@housemanfang has joined the channel
Svelte LIFF 設定也好囉
https://github.com/cofacts/rumors-line-bot/pull/171
https://github.com/cofacts/rumors-line-bot/pull/171
These are included in the PR: Svelte localhost & production build i18n extraction and resolution integration (ttag requires webpack, cannot use rollup) Material design component (via svelte-ma...
- 👍2
2020-04-10
求救為什麼我照 argument 跑會出這個錯 QQ
這個 API 的回傳是一個 articleReply
articleReply 本來就沒有 vote，只有 articleReplyFeedback 有～
原本是為了利用 apollo-client 的 automatic cache update 來更新被評價的 articleReply
只是我讀了這篇才知道
我們 mutation 回傳值設計其實還可以更好
只是我讀了這篇才知道
我們 mutation 回傳值設計其實還可以更好
所以那個 body 裡面要用 ownVote 囉？
`ownVote` 跟 `vote` 不一樣呀 @@
• `vote`: `articleReplyFeedback` 的欄位，紀錄「下了這個 `articleReplyFeedback` 的人」的那個 `vote`。
• `ownVote`: `articleReply` 的欄位，紀錄目前登入的使用者（呼叫 API 的人）針對這則 `articleReply` 的 `vote`。API 的 resolver 裡頭，他其實背後是去把當下使用者針對這則 `articleReply` 的 `articleReplyFeedback` 撈出來然後回傳他的 `vote`。這個欄位的存在，就是為了讓 UI 不用大老遠把所有 `articleReplyFeedback` 透過 API server 弄到瀏覽器來過濾，而可以直接拿到一個值用來判斷「目前此使用者，覺得這則 articleReply 是有用還沒用」。
• `vote`: `articleReplyFeedback` 的欄位，紀錄「下了這個 `articleReplyFeedback` 的人」的那個 `vote`。
• `ownVote`: `articleReply` 的欄位，紀錄目前登入的使用者（呼叫 API 的人）針對這則 `articleReply` 的 `vote`。API 的 resolver 裡頭，他其實背後是去把當下使用者針對這則 `articleReply` 的 `articleReplyFeedback` 撈出來然後回傳他的 `vote`。這個欄位的存在，就是為了讓 UI 不用大老遠把所有 `articleReplyFeedback` 透過 API server 弄到瀏覽器來過濾，而可以直接拿到一個值用來判斷「目前此使用者，覺得這則 articleReply 是有用還沒用」。
因為目前 `CreateOrUpdateArticleReplyFeedback` 回傳的是被評分的 `ArticleReply`，所以 body 裡面有的是 `ownReply` 欄位。
喔喔
我回家再看一下 schema XD
右邊有 schema 按鈕，欄位有 description 可以看～
這裡也有列出 schema definition，只是沒有 syntax highlight XD
這裡也有列出 schema definition，只是沒有 syntax highlight XD
我知道 只是我現在用公司工作機沒環境 XD
我自己兩邊都裝一樣的環境，VS code 還用 settings sync 把設定與 extension sync 起來 XD
這個 API 的回傳是一個 articleReply
articleReply 本來就沒有 vote，只有 articleReplyFeedback 有～
原本是為了利用 apollo-client 的 automatic cache update 來更新被評價的 articleReply
只是我讀了這篇才知道
我們 mutation 回傳值設計其實還可以更好
只是我讀了這篇才知道
我們 mutation 回傳值設計其實還可以更好
Medium
Design principles for building effective GraphQL mutation systems that can evolve over time
所以那個 body 裡面要用 ownVote 囉？
`ownVote` 跟 `vote` 不一樣呀 @@
• `vote`: `articleReplyFeedback` 的欄位，紀錄「下了這個 `articleReplyFeedback` 的人」的那個 `vote`。
• `ownVote`: `articleReply` 的欄位，紀錄目前登入的使用者（呼叫 API 的人）針對這則 `articleReply` 的 `vote`。API 的 resolver 裡頭，他其實背後是去把當下使用者針對這則 `articleReply` 的 `articleReplyFeedback` 撈出來然後回傳他的 `vote`。這個欄位的存在，就是為了讓 UI 不用大老遠把所有 `articleReplyFeedback` 透過 API server 弄到瀏覽器來過濾，而可以直接拿到一個值用來判斷「目前此使用者，覺得這則 articleReply 是有用還沒用」。
• `vote`: `articleReplyFeedback` 的欄位，紀錄「下了這個 `articleReplyFeedback` 的人」的那個 `vote`。
• `ownVote`: `articleReply` 的欄位，紀錄目前登入的使用者（呼叫 API 的人）針對這則 `articleReply` 的 `vote`。API 的 resolver 裡頭，他其實背後是去把當下使用者針對這則 `articleReply` 的 `articleReplyFeedback` 撈出來然後回傳他的 `vote`。這個欄位的存在，就是為了讓 UI 不用大老遠把所有 `articleReplyFeedback` 透過 API server 弄到瀏覽器來過濾，而可以直接拿到一個值用來判斷「目前此使用者，覺得這則 articleReply 是有用還沒用」。
因為目前 `CreateOrUpdateArticleReplyFeedback` 回傳的是被評分的 `ArticleReply`，所以 body 裡面有的是 `ownReply` 欄位。
喔喔
我回家再看一下 schema XD
右邊有 schema 按鈕，欄位有 description 可以看～
這裡也有列出 schema definition，只是沒有 syntax highlight XD
這裡也有列出 schema definition，只是沒有 syntax highlight XD
我知道 只是我現在用公司工作機沒環境 XD
我自己兩邊都裝一樣的環境，VS code 還用 settings sync 把設定與 extension sync 起來 XD
@zxc140zxc140 has joined the channel
2020-04-11
想問一下要怎麼手動更新 graphql cache
我現在用 useMutation ` CreateOrUpdateArticleReplyFeedback` 成功創建了回應
但是 reply feedback count 並不會更新
我現在用 useMutation ` CreateOrUpdateArticleReplyFeedback` 成功創建了回應
但是 reply feedback count 並不會更新
咦，我們的 article list 會用到跟 article reply feedback 相關的東西嗎？filter？
因為在新版的 lastest replies page
每個 article 下面有 replies
每個 reply 可以給 feedback
所以應該是都串在一起了？
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A144
每個 article 下面有 replies
每個 reply 可以給 feedback
所以應該是都串在一起了？
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A144
「articles list 並不會自己更新」的部分是說，下頭每個 reply 的 feedback count 沒有更新嗎
啊我有點說錯
應該說對應的 reply 的 positiveFeedbackCount 不會跟著更新
應該說對應的 reply 的 positiveFeedbackCount 不會跟著更新
是的
`CreateOrUpdateArticleReplyFeedback` 會回傳 `ArticleReply`
這裏建議 body 裡面拿一下 `articleId` 與 `replyId`
這樣 apollo-client 的 automatic cache update 機制，才能拼出 `ArticleReply` 的 ID 來更新 normalized `ArticleReply` cache
這裏建議 body 裡面拿一下 `articleId` 與 `replyId`
這樣 apollo-client 的 automatic cache update 機制，才能拼出 `ArticleReply` 的 ID 來更新 normalized `ArticleReply` cache
https://github.com/cofacts/rumors-site/blob/feature/latest-replies-page-ui/components/ReplyItem.js#L172
目前是有拿 但還是沒更新
所以我在想是不是還遺漏了什麼
目前是有拿 但還是沒更新
所以我在想是不是還遺漏了什麼
Reference:
• Apollo-client mutation 的 automatic cache update 機制，需要 id： https://www.apollographql.com/docs/react/caching/cache-configuration/#automatic-cache-updates
• 但我們 Article reply 其實沒有 ID，所以我在 rumors-site 告訴 apollo-client，遇到 article reply 請拿他的 articleId 與 replyId 拼成 ID 來 normalize
• Apollo-client mutation 的 automatic cache update 機制，需要 id： https://www.apollographql.com/docs/react/caching/cache-configuration/#automatic-cache-updates
• 但我們 Article reply 其實沒有 ID，所以我在 rumors-site 告訴 apollo-client，遇到 article reply 請拿他的 articleId 與 replyId 拼成 ID 來 normalize
> 所以我在想是不是我遺漏了什麼
了解，看起來 ID 是拼得成了。
但你沒有拿 `positiveFeedbackCount` 耶，這樣 apollo cache 自然不知道新的 `positiveFeedbackCount`
了解，看起來 ID 是拼得成了。
但你沒有拿 `positiveFeedbackCount` 耶，這樣 apollo cache 自然不知道新的 `positiveFeedbackCount`
合理
我好笨 orz
我好笨 orz
另外，文件裡也有寫
> ne nice way to take advantage of this property as much as possible is to make your mutation results have all of the data necessary to update the queries previously fetched. A simple trick for this is to use fragments to share fields between the query and the mutation that affects it.
所以如果你 article list 顯示 vote count 的 component 有 export fragment 出來（官網 colocating fragment），那在 mutation 這裡就可以直接塞 fragment 進去，那該 component 所有用到的 article reply 欄位就都能被更新了。
> ne nice way to take advantage of this property as much as possible is to make your mutation results have all of the data necessary to update the queries previously fetched. A simple trick for this is to use fragments to share fields between the query and the mutation that affects it.
所以如果你 article list 顯示 vote count 的 component 有 export fragment 出來（官網 colocating fragment），那在 mutation 這裡就可以直接塞 fragment 進去，那該 component 所有用到的 article reply 欄位就都能被更新了。
Apollo 真的做了太多神奇的事情，一開始用都會卡在奇怪的地方 ＸＤ
最後記得裝一下 https://github.com/apollographql/apollo-client-devtools
我覺得比較有用的只有 “Store” 還是 “cache” tab
debug 的時候，直接看他 cache 有沒有更新，比較能明白畫面沒更新到底是 apollo 問題還是 react 哪裡沒接到
我覺得比較有用的只有 “Store” 還是 “cache” tab
debug 的時候，直接看他 cache 有沒有更新，比較能明白畫面沒更新到底是 apollo 問題還是 react 哪裡沒接到
我也這麼覺得，cache 機制靠id一開始超容易忽略
咦，我們的 article list 會用到跟 article reply feedback 相關的東西嗎？filter？
因為在新版的 lastest replies page
每個 article 下面有 replies
每個 reply 可以給 feedback
所以應該是都串在一起了？
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A144
每個 article 下面有 replies
每個 reply 可以給 feedback
所以應該是都串在一起了？
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A144
「articles list 並不會自己更新」的部分是說，下頭每個 reply 的 feedback count 沒有更新嗎
啊我有點說錯
應該說對應的 reply 的 positiveFeedbackCount 不會跟著更新
應該說對應的 reply 的 positiveFeedbackCount 不會跟著更新
是的
`CreateOrUpdateArticleReplyFeedback` 會回傳 `ArticleReply`
這裏建議 body 裡面拿一下 `articleId` 與 `replyId`
這樣 apollo-client 的 automatic cache update 機制，才能拼出 `ArticleReply` 的 ID 來更新 normalized `ArticleReply` cache
這裏建議 body 裡面拿一下 `articleId` 與 `replyId`
這樣 apollo-client 的 automatic cache update 機制，才能拼出 `ArticleReply` 的 ID 來更新 normalized `ArticleReply` cache
https://github.com/cofacts/rumors-site/blob/feature/latest-replies-page-ui/components/ReplyItem.js#L172
目前是有拿 但還是沒更新
所以我在想是不是還遺漏了什麼
目前是有拿 但還是沒更新
所以我在想是不是還遺漏了什麼
Rumors list / creation UI, with server-side rendering - cofacts/rumors-site
Reference:
• Apollo-client mutation 的 automatic cache update 機制，需要 id： https://www.apollographql.com/docs/react/caching/cache-configuration/#automatic-cache-updates
• 但我們 Article reply 其實沒有 ID，所以我在 rumors-site 告訴 apollo-client，遇到 article reply 請拿他的 articleId 與 replyId 拼成 ID 來 normalize
• Apollo-client mutation 的 automatic cache update 機制，需要 id： https://www.apollographql.com/docs/react/caching/cache-configuration/#automatic-cache-updates
• 但我們 Article reply 其實沒有 ID，所以我在 rumors-site 告訴 apollo-client，遇到 article reply 請拿他的 articleId 與 replyId 拼成 ID 來 normalize
Rumors list / creation UI, with server-side rendering - cofacts/rumors-site
> 所以我在想是不是我遺漏了什麼
了解，看起來 ID 是拼得成了。
但你沒有拿 `positiveFeedbackCount` 耶，這樣 apollo cache 自然不知道新的 `positiveFeedbackCount`
了解，看起來 ID 是拼得成了。
但你沒有拿 `positiveFeedbackCount` 耶，這樣 apollo cache 自然不知道新的 `positiveFeedbackCount`
- 😮1
合理
我好笨 orz
我好笨 orz
另外，文件裡也有寫
> ne nice way to take advantage of this property as much as possible is to make your mutation results have all of the data necessary to update the queries previously fetched. A simple trick for this is to use fragments to share fields between the query and the mutation that affects it.
所以如果你 article list 顯示 vote count 的 component 有 export fragment 出來（官網 colocating fragment），那在 mutation 這裡就可以直接塞 fragment 進去，那該 component 所有用到的 article reply 欄位就都能被更新了。
> ne nice way to take advantage of this property as much as possible is to make your mutation results have all of the data necessary to update the queries previously fetched. A simple trick for this is to use fragments to share fields between the query and the mutation that affects it.
所以如果你 article list 顯示 vote count 的 component 有 export fragment 出來（官網 colocating fragment），那在 mutation 這裡就可以直接塞 fragment 進去，那該 component 所有用到的 article reply 欄位就都能被更新了。
- 😮1
Apollo 真的做了太多神奇的事情，一開始用都會卡在奇怪的地方 ＸＤ
最後記得裝一下 https://github.com/apollographql/apollo-client-devtools
我覺得比較有用的只有 “Store” 還是 “cache” tab
debug 的時候，直接看他 cache 有沒有更新，比較能明白畫面沒更新到底是 apollo 問題還是 react 哪裡沒接到
我覺得比較有用的只有 “Store” 還是 “cache” tab
debug 的時候，直接看他 cache 有沒有更新，比較能明白畫面沒更新到底是 apollo 問題還是 react 哪裡沒接到
:christmas_tree: Chrome extension for Apollo Client developer tools - apollographql/apollo-client-devtools
- 👍1
我也這麼覺得，cache 機制靠id一開始超容易忽略
是不是沒有從 replies 找相似的 articles 的 API 啊 0.0
reply 與相似 article 的定義是什麼呢
還是 reply 找 similar reply?
應該會有滿多 duplicate replies XDD
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A2476
簡單來說就是最新查核搜尋的這個 UI
是不是只能從 ListReplies 去拿文章然後把他組合起來呢？
簡單來說就是最新查核搜尋的這個 UI
是不是只能從 ListReplies 去拿文章然後把他組合起來呢？
還是有辦法用 ListArticles 去拿到
這裡應該是 ListReplies 抓 list of reply + articleReplies + article
然後顯示的時候 article 在上面這樣而已
然後顯示的時候 article 在上面這樣而已
但其實上面的那些 filter
是針對 ListArticles 設計的
我在做這頁時也是用 ListArticles 的思維去設計
所以可能會有一點小麻煩？
是針對 ListArticles 設計的
我在做這頁時也是用 ListArticles 的思維去設計
所以可能會有一點小麻煩？
不然可能就是用 replies 搜尋出來的結果不要再有上面的 filter ?
@yanglin5689446 你是對的，search reply 沒辦法做這類「還未有效查核」「熱門回報」「熱門討論」「主題」等篩選，最多只能做「是否是自己回應的」、「reply type」以及時間等等 reply 上有的欄位。
cc/ @stbb1025 @lucien
cc/ @stbb1025 @lucien
@stbb1025 @lucien 這個問題再麻煩你們看一下囉
簡單來說現在的 filter 主要是針對 article
在 reply 的搜尋結果頁可能要用針對 reply 的 filter 或是移除
簡單來說現在的 filter 主要是針對 article
在 reply 的搜尋結果頁可能要用針對 reply 的 filter 或是移除
Hmm...
search reply 是照用 Latest reply filter
我對一下跟各位說
看起來就只能 「自己回應的」、被認為「含有…」以及時間做 filter 了
已更新 hackmd
reply 與相似 article 的定義是什麼呢
還是 reply 找 similar reply?
應該會有滿多 duplicate replies XDD
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A2476
簡單來說就是最新查核搜尋的這個 UI
是不是只能從 ListReplies 去拿文章然後把他組合起來呢？
簡單來說就是最新查核搜尋的這個 UI
是不是只能從 ListReplies 去拿文章然後把他組合起來呢？
還是有辦法用 ListArticles 去拿到
2020-04-12
這裡應該是 ListReplies 抓 list of reply + articleReplies + article
然後顯示的時候 article 在上面這樣而已
然後顯示的時候 article 在上面這樣而已
但其實上面的那些 filter
是針對 ListArticles 設計的
我在做這頁時也是用 ListArticles 的思維去設計
所以可能會有一點小麻煩？
是針對 ListArticles 設計的
我在做這頁時也是用 ListArticles 的思維去設計
所以可能會有一點小麻煩？
不然可能就是用 replies 搜尋出來的結果不要再有上面的 filter ?
@yanglin5689446 你是對的，search reply 沒辦法做這類「還未有效查核」「熱門回報」「熱門討論」「主題」等篩選，最多只能做「是否是自己回應的」、「reply type」以及時間等等 reply 上有的欄位。
cc/ @stbb1025 @lucien
cc/ @stbb1025 @lucien
Chatbot 這裡正在實作新的 state diagram
這個 scope 超大的，必須要拆 PR review
這是 state diagram 右路 (?) 的兩個 state 的 PR，請過目：
https://github.com/cofacts/rumors-line-bot/pull/172
這個 PR 同時也處理了一些跨 state 的東西，例如把每次 reply 都會變的 `issuedAt` 換成回到 _INIT_ 時才會變的 `sessionId` 等等。
在這同時會繼續進行中路 & 左路的實作更新。
這個 scope 超大的，必須要拆 PR review
這是 state diagram 右路 (?) 的兩個 state 的 PR，請過目：
https://github.com/cofacts/rumors-line-bot/pull/172
這個 PR 同時也處理了一些跨 state 的東西，例如把每次 reply 都會變的 `issuedAt` 換成回到 _INIT_ 時才會變的 `sessionId` 等等。
在這同時會繼續進行中路 & 左路的實作更新。
This PR rewrites initState handler, and creates askingArticleSubmissionConsent handler that replaces the original askingArticleSource handler. What's covered Chatbot Interactions within the red...
@qq7up8down has joined the channel
2020-04-13
想徵集 Cofacts 的經驗值名字，用於讓使用者更能有認同感。
舉例來說
噗浪是 karma
知乎是鹽值
Cofacts 我們可能是 公道值，請大家在以下留言討論
舉例來說
噗浪是 karma
知乎是鹽值
Cofacts 我們可能是 公道值，請大家在以下留言討論
英文的部分我覺得可以用比較中性的貢獻度 contribution
但確實是可以取一個有趣的名字
但確實是可以取一個有趣的名字
例如說蔥（單位=把）
幫回應按讚就是幫他加蔥 (欸
幫回應按讚就是幫他加蔥 (欸
Stackoverflow 是用 reputation (聲望)
蔥是什麼梗哈哈
@mrorz 我們現在沒有「我也想知道」的功能，而是需要輸入理由的我也想回報，所以我加了關注功能，這需要 db 另外開欄位存
Hmm OK
但 priority 上，可能這一兩個月做不到唷 QQ
但 priority 上，可能這一兩個月做不到唷 QQ
了解
英文的部分我覺得可以用比較中性的貢獻度 contribution
但確實是可以取一個有趣的名字
但確實是可以取一個有趣的名字
例如說蔥（單位=把）
幫回應按讚就是幫他加蔥 (欸
幫回應按讚就是幫他加蔥 (欸
- 😆2
Stackoverflow 是用 reputation (聲望)
- ➕1
Hmm OK
但 priority 上，可能這一兩個月做不到唷 QQ
但 priority 上，可能這一兩個月做不到唷 QQ
蔥是什麼梗哈哈
了解
@hepinjess has joined the channel
想問一下我用 GetUser 去 query 時可以拿到正確資料
但是從 cache name 一直都是 null
就算重新 fetch 也是
有可能是甚麼原因？
但是從 cache name 一直都是 null
就算重新 fetch 也是
有可能是甚麼原因？
可以看一下左邊 cache 分頁
找出 `User:你的id`
看看下面的 name
話說回來，我其實不知道這個工具的 GraphiQL 會不會存進 cache @@
找出 `User:你的id`
看看下面的 name
話說回來，我其實不知道這個工具的 GraphiQL 會不會存進 cache @@
我看到的 cache 就是 name: null
但是我實際發 request 是有拿到 name 的
所以才覺得很奇怪 @@
但是我實際發 request 是有拿到 name 的
所以才覺得很奇怪 @@
我也沒有頭緒 QQ
可以借看一下 code 裡面「實際發 request」的 code 嗎
可以借看一下 code 裡面「實際發 request」的 code 嗎
我這邊有遇過的 case 是 component 抓到的 `ownVote` 欄位一直 undefined
但我的 case 是， network response 與 cache 裡面明明有東西，但 component 拿不到
後來發現是因為 `useQuery` 從 cache 取東西的時候，一定只會拿 query 裡的東西
就算之後有其他 `useQuery` 幫抓其他欄位，原本的 `useQuery` call 傳回給 component 的欄位都是固定是 query 裡寫的
但我的 case 是， network response 與 cache 裡面明明有東西，但 component 拿不到
後來發現是因為 `useQuery` 從 cache 取東西的時候，一定只會拿 query 裡的東西
就算之後有其他 `useQuery` 幫抓其他欄位，原本的 `useQuery` call 傳回給 component 的欄位都是固定是 query 裡寫的
因為我遇到的問題是「cache 有東西 component 拿不到」
而 @yanglin5689446 是「network 有抓下來但 cache 是空的」
似乎是不同問題
而 @yanglin5689446 是「network 有抓下來但 cache 是空的」
似乎是不同問題
https://github.com/cofacts/rumors-site/blob/dev/components/AppLayout/AppLayout.js#L16
其實就是這邊 GetUser
我有注意到下面的 useLazyQuery 在從 cache 拿的時候 name 會不見
但其他欄位都在
非常神奇
其實就是這邊 GetUser
我有注意到下面的 useLazyQuery 在從 cache 拿的時候 name 會不見
但其他欄位都在
非常神奇
超怪的
我晚上試試看
我晚上試試看
我現在大致確定拿到的時候是對的
但是只要 cache 讀就會變 null
而且只有名字部分
我在猜會不會是因為編碼？
因為我從 FB 拿到的名字是中文的
但是只要 cache 讀就會變 null
而且只有名字部分
我在猜會不會是因為編碼？
因為我從 FB 拿到的名字是中文的
忘記 try 了
我可能週六小聚之後才有空處理 ><
我可能週六小聚之後才有空處理 ><
我沒想過編碼耶
我以為 Network 面板裡，如果資料有進來的話，那就應該是 cache 的問題
好奇 name 欄位被 query 了幾次
會不會是後來 query 到 name 的時候，API 回傳了 null 給他，導致 cache 被 update 成 null 之類的（just wild guess, did not see network devtool)
我以為 Network 面板裡，如果資料有進來的話，那就應該是 cache 的問題
好奇 name 欄位被 query 了幾次
會不會是後來 query 到 name 的時候，API 回傳了 null 給他，導致 cache 被 update 成 null 之類的（just wild guess, did not see network devtool)
這我有想過
不過其他 articleReply 裡的 user 也都有 name 欄位
cache 裡其他 user 也都有 name
所以滿神奇的
不過其他 articleReply 裡的 user 也都有 name 欄位
cache 裡其他 user 也都有 name
所以滿神奇的
後來我試了發現
CreateOrUpdateArticleReplyFeedback 的 feedback 回傳的 response 裡
user 的 name 就是 null
不太確定是後端沒有更新到還是怎樣(其他欄位都有)
有稍微看一下後端那段 code 可是沒看出什麼端倪@@
CreateOrUpdateArticleReplyFeedback 的 feedback 回傳的 response 裡
user 的 name 就是 null
不太確定是後端沒有更新到還是怎樣(其他欄位都有)
有稍微看一下後端那段 code 可是沒看出什麼端倪@@
今天又是了一下發現 `CreateOrUpdateArticleReplyFeedback` 應該確實是沒有更新 user name
後端那邊我看是用 upsert userId 的方式產生一個 articleReplyFeedback
不太確定 elasticsearch 的 upsert 是怎麼實作的 @@
後端那邊我看是用 upsert userId 的方式產生一個 articleReplyFeedback
不太確定 elasticsearch 的 upsert 是怎麼實作的 @@
看起來那一個 `articleReplyFeedback` 的作者，app ID 不是 `website` 而是 localhost 開發專用的 `DEVELOPMENT_FRONTEND`
我記得我哪裏好像有寫，要 match 人的時候一定要 user id 與 app id 都 match @@
我記得我哪裏好像有寫，要 match 人的時候一定要 user id 與 app id 都 match @@
所以這是只有 develop 才會發生的問題囉？
似乎是登入 localhost rumors-api 後做 insert 操作，才會有的問題
合理
因為那是我自己登入新增的 feedback
以前的 feedback 都沒 comment
因為那是我自己登入新增的 feedback
以前的 feedback 都沒 comment
de 這 bug de 好久 _(┐「ε:)_
但 localhost 的 rumors-api 接的好像是 localhost 的 DB，不是 staging?
不太確定你的意思
我是在 local 自己申請 fb develop app 登入然後新增 feedback 的
我是在 local 自己申請 fb develop app 登入然後新增 feedback 的
i see 所以是 localhost 的 rumors-api 與 elasticsearch DB
如果 staging API 有你要的東西
那看要不要把 localhost rumors-site 的 .env 裡的 API URL 指向到 staging ( https://cofacts-api.hacktabl.org/graphql )
理論上這樣 appId 就會跟其他 staging 上的資料一致，比較拉得到 user
機器上也可以不用開 elasticsearch DB 與 rumors-api，比較省資源
那看要不要把 localhost rumors-site 的 .env 裡的 API URL 指向到 staging ( https://cofacts-api.hacktabl.org/graphql )
理論上這樣 appId 就會跟其他 staging 上的資料一致，比較拉得到 user
機器上也可以不用開 elasticsearch DB 與 rumors-api，比較省資源
合理
我開著一堆 container 筆電一直在哀嚎 XD
我開著一堆 container 筆電一直在哀嚎 XD
可以看一下左邊 cache 分頁
找出 `User:你的id`
看看下面的 name
話說回來，我其實不知道這個工具的 GraphiQL 會不會存進 cache @@
找出 `User:你的id`
看看下面的 name
話說回來，我其實不知道這個工具的 GraphiQL 會不會存進 cache @@
2020-04-14
@hepinjess Hello!
我看到的 cache 就是 name: null
但是我實際發 request 是有拿到 name 的
所以才覺得很奇怪 @@
但是我實際發 request 是有拿到 name 的
所以才覺得很奇怪 @@
我也沒有頭緒 QQ
可以借看一下 code 裡面「實際發 request」的 code 嗎
可以借看一下 code 裡面「實際發 request」的 code 嗎
我這邊有遇過的 case 是 component 抓到的 `ownVote` 欄位一直 undefined
但我的 case 是， network response 與 cache 裡面明明有東西，但 component 拿不到
後來發現是因為 `useQuery` 從 cache 取東西的時候，一定只會拿 query 裡的東西
就算之後有其他 `useQuery` 幫抓其他欄位，原本的 `useQuery` call 傳回給 component 的欄位都是固定是 query 裡寫的
但我的 case 是， network response 與 cache 裡面明明有東西，但 component 拿不到
後來發現是因為 `useQuery` 從 cache 取東西的時候，一定只會拿 query 裡的東西
就算之後有其他 `useQuery` 幫抓其他欄位，原本的 `useQuery` call 傳回給 component 的欄位都是固定是 query 裡寫的
因為我遇到的問題是「cache 有東西 component 拿不到」
而 @yanglin5689446 是「network 有抓下來但 cache 是空的」
似乎是不同問題
而 @yanglin5689446 是「network 有抓下來但 cache 是空的」
似乎是不同問題
@yanglin5689446 我早上 merge 了 new-navbar-ui 進 dev
但 new-pages-ui 看起來跟 dev 有 conflict，導致他無法把 code diff 裡面屬於 new-navbar-ui 的變更 (現已在 dev) 排除，結果現在 code diff 很亂，review 不能 orz
可以麻煩把 new-pages-ui rebase 到 dev 上嗎～
但 new-pages-ui 看起來跟 dev 有 conflict，導致他無法把 code diff 裡面屬於 new-navbar-ui 的變更 (現已在 dev) 排除，結果現在 code diff 很亂，review 不能 orz
可以麻煩把 new-pages-ui rebase 到 dev 上嗎～
okok
泰國 Cofact 要跟 FNF Thailand 開直播囉
https://www.facebook.com/FNFSEEAsia/posts/10157313917211713
泰國 Cofact 是由 opendream 從 Cofacts codebase (舊) fork 出來之後自己經營的 collaborative fact checking platform，網址：https://cofact.org
#MilkTeaAlliance
https://www.facebook.com/FNFSEEAsia/posts/10157313917211713
泰國 Cofact 是由 opendream 從 Cofacts codebase (舊) fork 出來之後自己經營的 collaborative fact checking platform，網址：https://cofact.org
#MilkTeaAlliance
facebook.com
Happening shortly! Watch and listen to journalists from Southeast & East Asia as they discuss how to handle the infodemic in the region. Cofact together with Fnf Thailand will stream this live. The...
1
https://cofact.org/articles 外觀大改版耶
而且是粉紅色
而且是粉紅色
cofact.org
คนใกล้ชิดของคุณ อาจตกเป็นเหยื่อของข่าวลวง หรือ ส่งต่อข่าวลวงบนอินเทอร์เน็ตโดยไม่รู้ตัว
- 😮4
我覺得有爭議指標也不錯
那個好像是用回應 type 算的
我有點不敢這樣算 XDDD
我有點不敢這樣算 XDDD
我覺得問題是分段正確跟錯誤，這樣算很不準
標錯誤的回應有人覺得沒用的理由是「連結到不同的問題」
大概是答非所問的意思
大概是答非所問的意思
不太確定為什麼 XD
我覺得我們的理由常常爛爛的
我覺得我們的理由常常爛爛的
不過他們這樣的編排（在理由夠好的時候）可以讓上面是「被回報的訊息」、下面是「回應」的結構更為清楚
視覺上不會讓人讀了上面之後就以為這是一篇「事實」
忘了下面有查證區塊
忘了下面有查證區塊
新設計還會有這樣的感覺嗎？
第一眼其實不會覺得這是個查證網站的「謠言」區塊
會有點像內容農場 (?) 的主文
會有點像內容農場 (?) 的主文
因為非常多人會從 google 直接 land in 個別文章頁面。
所以如果他點進來，不知道上頭其實是「網友回報的可疑待查證訊息」，那就會變成內容農場了。
所以如果他點進來，不知道上頭其實是「網友回報的可疑待查證訊息」，那就會變成內容農場了。
這也是為什麼我前天會建議把「 N 人回報下面的訊息」放到上面，至少讓進入網頁的人知道
1. 下面開始，是引述網友轉傳的訊息
2. 這則到底多熱門
1. 下面開始，是引述網友轉傳的訊息
2. 這則到底多熱門
所以標題其實是重要的
或是需要一個夠 informative 的標題
其實現在志超那個版本我在讀的時候
我發現我會忽略那個大字囧
其實現在志超那個版本我在讀的時候
我發現我會忽略那個大字囧
我覺得最上面的標題有點冗
泰國版也確實是把人數放上面
我有想過要不要把他包成像是聊天室訊息
我晚上試試看志超跟你意見的版本
okok
1
https://github.com/cofacts/rumors-site/blob/dev/components/AppLayout/AppLayout.js#L16
其實就是這邊 GetUser
我有注意到下面的 useLazyQuery 在從 cache 拿的時候 name 會不見
但其他欄位都在
非常神奇
其實就是這邊 GetUser
我有注意到下面的 useLazyQuery 在從 cache 拿的時候 name 會不見
但其他欄位都在
非常神奇
Rumors list / creation UI, with server-side rendering - cofacts/rumors-site
Currently when user visit editor guide (/editor/guideline) line, the &quot;about&quot; and &quot;policy&quot; link in the footer will be linked to /editor/about and /editor/policy, which is incorre...
有搭上粉色口罩的時事耶
蠻可愛的
我覺得有爭議指標也不錯
那個好像是用回應 type 算的
我有點不敢這樣算 XDDD
我有點不敢這樣算 XDDD
我覺得問題是分段正確跟錯誤，這樣算很不準
標錯誤的回應有人覺得沒用的理由是「連結到不同的問題」
大概是答非所問的意思
大概是答非所問的意思
不太確定為什麼 XD
我覺得我們的理由常常爛爛的
我覺得我們的理由常常爛爛的
不過他們這樣的編排（在理由夠好的時候）可以讓上面是「被回報的訊息」、下面是「回應」的結構更為清楚
視覺上不會讓人讀了上面之後就以為這是一篇「事實」
忘了下面有查證區塊
忘了下面有查證區塊
這好像是他們分類的 UI，也是 crowd-sourced
分類我們現在只有建議，還沒有決定建議怎麼影響結果
現在 API 的實作是
• `articleCategory` 一但被蓋出來，他就是「被標成該分類」了，`ListArticles` 針對該 category 做 query 時是可以把它撈出來的。
• 任何人都可以針對該 `articleCategory` upvote 或 downvote
基本上跟 `articleReply` 一致。
• `articleCategory` 一但被蓋出來，他就是「被標成該分類」了，`ListArticles` 針對該 category 做 query 時是可以把它撈出來的。
• 任何人都可以針對該 `articleCategory` upvote 或 downvote
基本上跟 `articleReply` 一致。
很可愛
但我不敢直接用 reply type 顯示成 meter XD
但我不敢直接用 reply type 顯示成 meter XD
- 2
分類上，他們把 true 分成 all true 跟 some true
超怪的
我晚上試試看
我晚上試試看
請問 @darkbtf 與 @sayuan 有用過 elasticsearch 的 smartcn tokenizer 嗎
https://www.elastic.co/guide/en/elasticsearch/plugins/6.2/analysis-smartcn.html
https://www.elastic.co/guide/en/elasticsearch/plugins/6.2/analysis-smartcn.html
cofacts 用的是 smartcn analyzer 嗎？
分類我們現在只有建議，還沒有決定建議怎麼影響結果
現在 API 的實作是
• `articleCategory` 一但被蓋出來，他就是「被標成該分類」了，`ListArticles` 針對該 category 做 query 時是可以把它撈出來的。
• 任何人都可以針對該 `articleCategory` upvote 或 downvote
基本上跟 `articleReply` 一致。
• `articleCategory` 一但被蓋出來，他就是「被標成該分類」了，`ListArticles` 針對該 category 做 query 時是可以把它撈出來的。
• 任何人都可以針對該 `articleCategory` upvote 或 downvote
基本上跟 `articleReply` 一致。
新設計還會有這樣的感覺嗎？
第一眼其實不會覺得這是個查證網站的「謠言」區塊
會有點像內容農場 (?) 的主文
會有點像內容農場 (?) 的主文
因為非常多人會從 google 直接 land in 個別文章頁面。
所以如果他點進來，不知道上頭其實是「網友回報的可疑待查證訊息」，那就會變成內容農場了。
所以如果他點進來，不知道上頭其實是「網友回報的可疑待查證訊息」，那就會變成內容農場了。
這也是為什麼我前天會建議把「 N 人回報下面的訊息」放到上面，至少讓進入網頁的人知道
1. 下面開始，是引述網友轉傳的訊息
2. 這則到底多熱門
1. 下面開始，是引述網友轉傳的訊息
2. 這則到底多熱門
所以標題其實是重要的
或是需要一個夠 informative 的標題
其實現在志超那個版本我在讀的時候
我發現我會忽略那個大字囧
其實現在志超那個版本我在讀的時候
我發現我會忽略那個大字囧
我覺得最上面的標題有點冗
泰國版也確實是把人數放上面
我有想過要不要把他包成像是聊天室訊息
我晚上試試看志超跟你意見的版本
- 1
2020-04-15
@brayton.chiou has joined the channel
本日會議記錄，主要都是跟週末直播小聚有關～
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg
（note: 今天下午 2pm ~ 5pm g0v hackmd 升級，會無法使用）
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg
（note: 今天下午 2pm ~ 5pm g0v hackmd 升級，會無法使用）
@wtflink515 has joined the channel
朋友團隊的總統盃黑客松提案，想找我們合作聊聊
https://docs.google.com/presentation/d/1649XOm7XUzF-uDrO6yBXMY2VnWd-XYAsAaDihGkQbog/edit#slide=id.g7fa691e811_0_1261
https://docs.google.com/presentation/d/1649XOm7XUzF-uDrO6yBXMY2VnWd-XYAsAaDihGkQbog/edit#slide=id.g7fa691e811_0_1261
- 💰1
好有趣, 不實資訊的交易所 XDDD
cofacts 用的是 smartcn analyzer 嗎？
2020-04-16
Greeting from Thailand !
Thanks @au & @mrorz to help us get going from sometime ago!
As you guys know we Thais are trying to replicate Cofacts into Thailand misinformation fighting ecosystems, we just had our soft launch yesterday, many people are very interested, we have few hundreds articles/comments now, although from not many people yet, we are trying our best to grow theses collaborative fact-checking movement in Thailand.
Here are some updates and hope to share everything with you guys
Cofact Thailand (cofact.org)
Additional features and functionalities:
Data structure
- [Change] Article now have separate ‘Title’ and ‘Body’ field
- [Improvement] Comment labels now have ‘half-truth’ option.
- [New] Tags for article. Only admins can manage tags.
- [New] Alias for search keywords, eg. Different spellings and miss-spellings of COVID/Corona.
- [To be implemented] Upload photo + OCR
- [To be implemented] HTML output with ClaimReview data structure.
Interface and user interaction
- [Improvement] User-friendly front page with search box
- [Improvement] Better visual compartmentalisation of sections that has many sub-element such as each comment.
- [New] ‘Truth gauge’ for each article: The gauge displays weighted average value of all comment labels for that article, i.e. all-truth = 1, half-truth = 0.5, fake = 0, along with number of comments.
- [Change] New comment section’s default tab is changed to ‘Write comment’ tab instead of ‘Search’ tab.
- [Improvement] Add explanation and examples in some place such as ‘Reason’ box in create article page.
Our cofacts github repositories : https://github.com/search?q=topic%3Acofacts+fork%3Atrue+org%3Aopendream&type=Repositories
Thanks @au & @mrorz to help us get going from sometime ago!
As you guys know we Thais are trying to replicate Cofacts into Thailand misinformation fighting ecosystems, we just had our soft launch yesterday, many people are very interested, we have few hundreds articles/comments now, although from not many people yet, we are trying our best to grow theses collaborative fact-checking movement in Thailand.
Here are some updates and hope to share everything with you guys
Cofact Thailand (cofact.org)
Additional features and functionalities:
Data structure
- [Change] Article now have separate ‘Title’ and ‘Body’ field
- [Improvement] Comment labels now have ‘half-truth’ option.
- [New] Tags for article. Only admins can manage tags.
- [New] Alias for search keywords, eg. Different spellings and miss-spellings of COVID/Corona.
- [To be implemented] Upload photo + OCR
- [To be implemented] HTML output with ClaimReview data structure.
Interface and user interaction
- [Improvement] User-friendly front page with search box
- [Improvement] Better visual compartmentalisation of sections that has many sub-element such as each comment.
- [New] ‘Truth gauge’ for each article: The gauge displays weighted average value of all comment labels for that article, i.e. all-truth = 1, half-truth = 0.5, fake = 0, along with number of comments.
- [Change] New comment section’s default tab is changed to ‘Write comment’ tab instead of ‘Search’ tab.
- [Improvement] Add explanation and examples in some place such as ‘Reason’ box in create article page.
Our cofacts github repositories : https://github.com/search?q=topic%3Acofacts+fork%3Atrue+org%3Aopendream&type=Repositories
GitHub is where people build software. More than 40 million people use GitHub to discover, fork, and contribute to over 100 million projects.
- 👍2
- 🙌2
Hi, I’m Lucien, the designer at Cofacts.
It’s glad to see the you guys did lots significant progress. I like your pink style and new feature.
We are doing a big reversion now. We should share and learn from each other. Here is thing we are working now and some feedback about your new feature but we don’t have.
1. Tag system:
@ggm is leading to implement the auto label tag system by machine learning. In the interface, we allow users to add/delete tag and feedback the tag is labeled correct or not.
2. OCR: we have prototype by @acerxp511, which allow user forward image. However, it need more test.
3. ‘Title’ and ‘Body’ field
The reason that we don’t have is it required someone to add a title on the messages. Now we ask reporter has to report the reason why they doubt this message has truth or not, which is a candidate used as title. However, the result we got is not qualified as title.
4. Truth gauge and half-truth option
In stead give a half-truth option, We encourage user write one `contain truth` and one `contain false` fact check if you found this messages has part of truth and false. The reason of that is we eventually want editor can label which paragraph is he fact checked.
Furthermore, we hesitated use the truth gauge kind summary information because we think that will mislead reader that we have give a final judgement. But actually, we don’t do that. What we do is providing more people’s thought with their reference.
We doing the total new design here
[Figma](https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0&viewport=669%2C123%2C0.4207538962364197) You can check that. Finally thanks your improvement. we’ll reference it.
It’s glad to see the you guys did lots significant progress. I like your pink style and new feature.
We are doing a big reversion now. We should share and learn from each other. Here is thing we are working now and some feedback about your new feature but we don’t have.
1. Tag system:
@ggm is leading to implement the auto label tag system by machine learning. In the interface, we allow users to add/delete tag and feedback the tag is labeled correct or not.
2. OCR: we have prototype by @acerxp511, which allow user forward image. However, it need more test.
3. ‘Title’ and ‘Body’ field
The reason that we don’t have is it required someone to add a title on the messages. Now we ask reporter has to report the reason why they doubt this message has truth or not, which is a candidate used as title. However, the result we got is not qualified as title.
4. Truth gauge and half-truth option
In stead give a half-truth option, We encourage user write one `contain truth` and one `contain false` fact check if you found this messages has part of truth and false. The reason of that is we eventually want editor can label which paragraph is he fact checked.
Furthermore, we hesitated use the truth gauge kind summary information because we think that will mislead reader that we have give a final judgement. But actually, we don’t do that. What we do is providing more people’s thought with their reference.
We doing the total new design here
[Figma](https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0&viewport=669%2C123%2C0.4207538962364197) You can check that. Finally thanks your improvement. we’ll reference it.
Hello @sunitshrestha it’s great to hear from you!
Speaking of OCR, we currently implement OCR on chatbot side — it extracts text out of images and use that text to query the database.
The database itself does not support images yet, but we can support images with text to a certain extent with this method.
https://github.com/cofacts/rumors-line-bot/pull/147
Speaking of OCR, we currently implement OCR on chatbot side — it extracts text out of images and use that text to query the database.
The database itself does not support images yet, but we can support images with text to a certain extent with this method.
https://github.com/cofacts/rumors-line-bot/pull/147
@mrorz hey could you please invite patipat@opendream.co.th and chitpong@changefusion.org into this channel, they can't seems to get in, so they can collaborate more with you guys and answers few stuff here, also learn about our OCR implementation !
Weird, they should be able to get invitation letter via http://join.g0v.tw/
- 👍12
- 🙌2
- 🥛1
- 🍵1
@akasukilee has joined the channel
Replied to a thread: 2020-04-16 01:05:17
Hi, I’m Lucien, the designer at Cofacts.
It’s glad to see the you guys did lots significant progress. I like your pink style and new feature.
We are doing a big reversion now. We should share and learn from each other. Here is thing we are working now and some feedback about your new feature but we don’t have.
1. Tag system:
@ggm is leading to implement the auto label tag system by machine learning. In the interface, we allow users to add/delete tag and feedback the tag is labeled correct or not.
2. OCR: we have prototype by @acerxp511, which allow user forward image. However, it need more test.
3. ‘Title’ and ‘Body’ field
The reason that we don’t have is it required someone to add a title on the messages. Now we ask reporter has to report the reason why they doubt this message has truth or not, which is a candidate used as title. However, the result we got is not qualified as title.
4. Truth gauge and half-truth option
In stead give a half-truth option, We encourage user write one `contain truth` and one `contain false` fact check if you found this messages has part of truth and false. The reason of that is we eventually want editor can label which paragraph is he fact checked.
Furthermore, we hesitated use the truth gauge kind summary information because we think that will mislead reader that we have give a final judgement. But actually, we don’t do that. What we do is providing more people’s thought with their reference.
We doing the total new design here
[Figma](https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0&viewport=669%2C123%2C0.4207538962364197) You can check that. Finally thanks your improvement. we’ll reference it.
It’s glad to see the you guys did lots significant progress. I like your pink style and new feature.
We are doing a big reversion now. We should share and learn from each other. Here is thing we are working now and some feedback about your new feature but we don’t have.
1. Tag system:
@ggm is leading to implement the auto label tag system by machine learning. In the interface, we allow users to add/delete tag and feedback the tag is labeled correct or not.
2. OCR: we have prototype by @acerxp511, which allow user forward image. However, it need more test.
3. ‘Title’ and ‘Body’ field
The reason that we don’t have is it required someone to add a title on the messages. Now we ask reporter has to report the reason why they doubt this message has truth or not, which is a candidate used as title. However, the result we got is not qualified as title.
4. Truth gauge and half-truth option
In stead give a half-truth option, We encourage user write one `contain truth` and one `contain false` fact check if you found this messages has part of truth and false. The reason of that is we eventually want editor can label which paragraph is he fact checked.
Furthermore, we hesitated use the truth gauge kind summary information because we think that will mislead reader that we have give a final judgement. But actually, we don’t do that. What we do is providing more people’s thought with their reference.
We doing the total new design here
[Figma](https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0&viewport=669%2C123%2C0.4207538962364197) You can check that. Finally thanks your improvement. we’ll reference it.
Replied to a thread: 2020-04-16 01:05:17
Hello @sunitshrestha it’s great to hear from you!
Speaking of OCR, we currently implement OCR on chatbot side — it extracts text out of images and use that text to query the database.
The database itself does not support images yet, but we can support images with text to a certain extent with this method.
https://github.com/cofacts/rumors-line-bot/pull/147
Speaking of OCR, we currently implement OCR on chatbot side — it extracts text out of images and use that text to query the database.
The database itself does not support images yet, but we can support images with text to a certain extent with this method.
https://github.com/cofacts/rumors-line-bot/pull/147
Add tesseract-ocr to process image messages by nonumpa · Pull Request #147 · cofacts/rumors-line-bota. Add tesseract-ocr to process image messages Extract message_process statements to processText function. Save and process image files in tmp_image_process dir. Update README.md about tesseract-o...
是說之前給我的 esdata 沒有包含 category
所以現在要做 category filter 會有點麻煩
所以現在要做 category filter 會有點麻煩
其實現在也沒有 囧
理論上 @ggm 今天應該要來處理這件事情
理論上 @ggm 今天應該要來處理這件事情
拍謝 @yanglin5689446 我這一兩天會弄好 QQ 我這一兩天都只睡八小時十分昏沈
講錯了 我只醒著八小時⋯⋯
但現在還沒來 QQ
@yanglin5689446 想問關於 https://g0v.hackmd.io/ZZWHWi2BTuyhkSWzAvKLAw#%E9%81%8E%E6%BF%BE%E9%81%B8%E9%A0%85%EF%BC%9A 這裡提到的「還未有有效查核」「熱門討論」「回應中有「含有真實資訊」」「我查核過」的 filter
目前還沒有 API ㄇ
因為週末的小聚可能會需要「還未有有效查核」的功能
如果沒有的話我可以先做
目前還沒有 API ㄇ
因為週末的小聚可能會需要「還未有有效查核」的功能
如果沒有的話我可以先做
是的
ok 那我這裡這樣實作ㄛ
`ListArticles` 的 `filter` 我會增加一個 `hasPositiveFeedbackArticleReply: boolean`
1. 如果都不給，就不會 filter by 這個
2. 如果給 `true`，就會把「任何 articleReply 是 NORMAL 且正 feedback 多於負 feedback」放進 bool query 的 `must` 或 `filter` 裡。這樣 `ListArticles` 就會只列出「有任何一個正回饋 articleReply 的文章」
3. 如果給 `false`， ，就會把「任何 articleReply 是 NORMAL 且正 feedback 多於負 feedback」放進 bool query 的 `must_not` 裡。這樣 `ListArticles` 就會只列出「沒有半個正回饋 articleReply 的文章」
1. 如果都不給，就不會 filter by 這個
2. 如果給 `true`，就會把「任何 articleReply 是 NORMAL 且正 feedback 多於負 feedback」放進 bool query 的 `must` 或 `filter` 裡。這樣 `ListArticles` 就會只列出「有任何一個正回饋 articleReply 的文章」
3. 如果給 `false`， ，就會把「任何 articleReply 是 NORMAL 且正 feedback 多於負 feedback」放進 bool query 的 `must_not` 裡。這樣 `ListArticles` 就會只列出「沒有半個正回饋 articleReply 的文章」
@yanglin5689446 與 @lucien 覺得呢
不過現在的設計是每一種回應種類都會有一個 filter
如果照這樣設計的話是不是只有正向回饋可以 filter?
如果讓這個欄位改成一個 array 含有回應的種類 是可行的嗎？
如果照這樣設計的話是不是只有正向回饋可以 filter?
如果讓這個欄位改成一個 array 含有回應的種類 是可行的嗎？
`ListArticles` 的 `filter` 是 object，可以下複數個 `filter`
嗯嗯，可以串成其中一個，我看了覺得可以，雖然目前只會用到 false
@yanglin5689446 這裏的邏輯是
`filter` 有什麼，就往 bool query 裡塞什麼
https://github.com/cofacts/rumors-api/blob/master/src/graphql/queries/ListArticles.js#L146-L333
所以自然而然形成一個 AND 的概念
`filter` 有什麼，就往 bool query 裡塞什麼
https://github.com/cofacts/rumors-api/blob/master/src/graphql/queries/ListArticles.js#L146-L333
所以自然而然形成一個 AND 的概念
那如果是含有個人意見的會另開一個 filter 嗎
對對
但他們在 replies 裡應該是同一個欄位?
這樣分成兩個 filter 會不會有點怪啊
這樣分成兩個 filter 會不會有點怪啊
含有個人意見 是針對 `articleReplies.replyType`
我現在要實作的那個是針對 `articleReplies.positiveFeedbackCount-articleReplies.negativeFeedbackCount`
我現在要實作的那個是針對 `articleReplies.positiveFeedbackCount-articleReplies.negativeFeedbackCount`
欄位不同ㄛ
喔喔
`hasPositiveFeedbackArticleReply` 改成用 `hasArticleReplyWithMorePositiveFeedback` 好了
原本那個名字會讓人誤以為沒考慮 negative feedback count
原本那個名字會讓人誤以為沒考慮 negative feedback count
我在想要不要比照 `hasPositiveFeedbackArticleReply` ，在 `ListArticle` filter做一個 `hasMyArticleReply`
`true` 就是有，`false`就是沒有
不過之後 profile page 如果要列出某使用者的 `articleReply`，不知道是要改 `ListArticle` filter 還是要在 User 底下加 field 就是了⋯⋯
cc/ @lucien @yanglin5689446
`true` 就是有，`false`就是沒有
不過之後 profile page 如果要列出某使用者的 `articleReply`，不知道是要改 `ListArticle` filter 還是要在 User 底下加 field 就是了⋯⋯
cc/ @lucien @yanglin5689446
如果有座在 `ListArticle` 在 profile 就繼續用就可以了吧？
反正 query 會被 group 在一起發送？
反正 query 會被 group 在一起發送？
如果「某使用者的 `articleReply`」只會在 profile 之類的頁面使用，那確實是做在 User 底下比較合理，這樣 `ListArticle` filter 只要實作「有/沒有我的 articleReply」filter 即可
@yanglin5689446
其實主要是考量 `ListArticle` 這裡如果計算 `articleReply` 還要考慮是「哪個使用者發的 `articleReply`」那 API 就不能只是 boolean
而必須是個 boolean + user ID string，所以會從
```hasMyArticleReply: Boolean```
變成
```articleReplyFrom: { userId: String, appId: String, exists: Boolean }```
(想不到更好的取名 囧)
其實主要是考量 `ListArticle` 這裡如果計算 `articleReply` 還要考慮是「哪個使用者發的 `articleReply`」那 API 就不能只是 boolean
而必須是個 boolean + user ID string，所以會從
```hasMyArticleReply: Boolean```
變成
```articleReplyFrom: { userId: String, appId: String, exists: Boolean }```
(想不到更好的取名 囧)
@yanglin5689446 與 @lucien 覺得呢
- 👍1
Scripts for managing rumors db. Contribute to cofacts/rumors-db development by creating an account on GitHub.
不過現在的設計是每一種回應種類都會有一個 filter
如果照這樣設計的話是不是只有正向回饋可以 filter?
如果讓這個欄位改成一個 array 含有回應的種類 是可行的嗎？
如果照這樣設計的話是不是只有正向回饋可以 filter?
如果讓這個欄位改成一個 array 含有回應的種類 是可行的嗎？
`ListArticles` 的 `filter` 是 object，可以下複數個 `filter`
- 😮1
嗯嗯，可以串成其中一個，我看了覺得可以，雖然目前只會用到 false
@yanglin5689446 這裏的邏輯是
`filter` 有什麼，就往 bool query 裡塞什麼
https://github.com/cofacts/rumors-api/blob/master/src/graphql/queries/ListArticles.js#L146-L333
所以自然而然形成一個 AND 的概念
`filter` 有什麼，就往 bool query 裡塞什麼
https://github.com/cofacts/rumors-api/blob/master/src/graphql/queries/ListArticles.js#L146-L333
所以自然而然形成一個 AND 的概念
GraphQL API server for clients like rumors-site and rumors-line-bot - cofacts/rumors-api
那如果是含有個人意見的會另開一個 filter 嗎
對對
但他們在 replies 裡應該是同一個欄位?
這樣分成兩個 filter 會不會有點怪啊
這樣分成兩個 filter 會不會有點怪啊
含有個人意見 是針對 `articleReplies.replyType`
我現在要實作的那個是針對 `articleReplies.positiveFeedbackCount-articleReplies.negativeFeedbackCount`
我現在要實作的那個是針對 `articleReplies.positiveFeedbackCount-articleReplies.negativeFeedbackCount`
- 👌1
欄位不同ㄛ
喔喔
`hasPositiveFeedbackArticleReply` 改成用 `hasArticleReplyWithMorePositiveFeedback` 好了
原本那個名字會讓人誤以為沒考慮 negative feedback count
原本那個名字會讓人誤以為沒考慮 negative feedback count
/github unsubscribe cofacts/rumors-api
/github unsubscribe cofacts/rumors-api
/github subscribe cofacts
@mrorz hey could you please invite patipat@opendream.co.th and chitpong@changefusion.org into this channel, they can't seems to get in, so they can collaborate more with you guys and answers few stuff here, also learn about our OCR implementation !
Weird, they should be able to get invitation letter via http://join.g0v.tw/
This PR implements `hasArticleReplyWithMorePositiveFeedback` which: 1. When `true`, gives only the articles with at least 1 article reply whose `#(positive feedback) > #(negative feedback)` 2. When `false`, gives only the articles with no article reply, or all its article replies has `#(positive feedback) <= #(negative feedback)` I found that `normalArticleReplyCount` in `ListArticles` fixture actually does not match `normalArticleReplyCount`. This PR adjusts `ListArticles` fixtures so that • For all article fixtures, `normalArticleReplyCount` matches length of `articleReplies` array. • Preserve some of articles that has no article replies • Adds some deleted article replies, which should not affect any filter since they are deleted • Fetches the field that is being sorted / filtered in snapshot, so that the results can be easily verified by reading snapshot files directly • Removes excessive `pageInfo` and `totalCount` -- we just leaving a few `pageInfo` and `totalCount` in test cases is enough (prove that it works). For most other unit tests the two fields are like noise, so remove them from unit test.
這張與 https://github.com/cofacts/rumors-api/pull/161 都有點急，希望可以在明天晚上前就能上 production，不然*週六的小聚會開天窗囧*
https://github.com/cofacts/rumors-api/pull/161 這張是簡單的小 refactor，把殘留的 script query 換成 range query。
至於 162 那張就是實作上面提到的 `hasArticleReplyWithMorePositiveFeedback` filter，不過 unit test 那裡有些複雜。
主要是因為我發現原本的 `ListArticles` fixture 有諸多問題：
1. 沒有任何 article 是沒有 article reply 的，這樣測不出來 `hasArticleReplyWithMorePositiveFeedback` 會 cover 的 case
2. 沒有 deleted article reply
3. 有些 `normalArticleReplyCount` 跟 `articleReplies` 對不起來
4. `ListArticle` snapshot 非常難以閱讀——一個 `it()` 裡寫了太多 `matchSnapshot()` 變得很難對哪個測試是哪個，而且 snapshot 裡也沒有包含待測 filter / sort 欄位。
這個 PR 把上面的問題一次修光光惹
https://github.com/cofacts/rumors-api/pull/161 這張是簡單的小 refactor，把殘留的 script query 換成 range query。
至於 162 那張就是實作上面提到的 `hasArticleReplyWithMorePositiveFeedback` filter，不過 unit test 那裡有些複雜。
主要是因為我發現原本的 `ListArticles` fixture 有諸多問題：
1. 沒有任何 article 是沒有 article reply 的，這樣測不出來 `hasArticleReplyWithMorePositiveFeedback` 會 cover 的 case
2. 沒有 deleted article reply
3. 有些 `normalArticleReplyCount` 跟 `articleReplies` 對不起來
4. `ListArticle` snapshot 非常難以閱讀——一個 `it()` 裡寫了太多 `matchSnapshot()` 變得很難對哪個測試是哪個，而且 snapshot 裡也沒有包含待測 filter / sort 欄位。
這個 PR 把上面的問題一次修光光惹
ListArticles.js.snap 因為 snapshot 順序有換，所以 line diff 會對不起來，很難 review。
建議 clone 下來，直接與 fixture file 對照 review（test file 倒不用開，因為 filter 或 sort rule 都有寫在 snapshot 名字上）
或者是直接 review 整個檔案：
https://github.com/cofacts/rumors-api/blob/9da6cb7c9fea987f5da7c1d22e9b41663d32194d/src/graphql/queries/__tests__/__snapshots__/ListArticles.js.snap
建議 clone 下來，直接與 fixture file 對照 review（test file 倒不用開，因為 filter 或 sort rule 都有寫在 snapshot 名字上）
或者是直接 review 整個檔案：
https://github.com/cofacts/rumors-api/blob/9da6cb7c9fea987f5da7c1d22e9b41663d32194d/src/graphql/queries/__tests__/__snapshots__/ListArticles.js.snap
Replied to a thread: 2020-04-16 19:16:15
這張與 https://github.com/cofacts/rumors-api/pull/161 都有點急，希望可以在明天晚上前就能上 production，不然*週六的小聚會開天窗囧*
https://github.com/cofacts/rumors-api/pull/161 這張是簡單的小 refactor，把殘留的 script query 換成 range query。
至於 162 那張就是實作上面提到的 `hasArticleReplyWithMorePositiveFeedback` filter，不過 unit test 那裡有些複雜。
主要是因為我發現原本的 `ListArticles` fixture 有諸多問題：
1. 沒有任何 article 是沒有 article reply 的，這樣測不出來 `hasArticleReplyWithMorePositiveFeedback` 會 cover 的 case
2. 沒有 deleted article reply
3. 有些 `normalArticleReplyCount` 跟 `articleReplies` 對不起來
4. `ListArticle` snapshot 非常難以閱讀——一個 `it()` 裡寫了太多 `matchSnapshot()` 變得很難對哪個測試是哪個，而且 snapshot 裡也沒有包含待測 filter / sort 欄位。
這個 PR 把上面的問題一次修光光惹
https://github.com/cofacts/rumors-api/pull/161 這張是簡單的小 refactor，把殘留的 script query 換成 range query。
至於 162 那張就是實作上面提到的 `hasArticleReplyWithMorePositiveFeedback` filter，不過 unit test 那裡有些複雜。
主要是因為我發現原本的 `ListArticles` fixture 有諸多問題：
1. 沒有任何 article 是沒有 article reply 的，這樣測不出來 `hasArticleReplyWithMorePositiveFeedback` 會 cover 的 case
2. 沒有 deleted article reply
3. 有些 `normalArticleReplyCount` 跟 `articleReplies` 對不起來
4. `ListArticle` snapshot 非常難以閱讀——一個 `it()` 裡寫了太多 `matchSnapshot()` 變得很難對哪個測試是哪個，而且 snapshot 裡也沒有包含待測 filter / sort 欄位。
這個 PR 把上面的問題一次修光光惹
Replaces `getOperatorAndOperand` & `script` queries with `getRangeFieldParamFromArithmeticExpression` and `range` queries for all filters involving "GT", "LT", "EQ". Fixes <https://github.com/cofacts/rumors-api/issues/148|#148> by picking up all arithmetic operations left out in previous PR (<https://github.com/cofacts/rumors-api/pull/154|#154> )
ListArticles.js.snap 因為 snapshot 順序有換，所以 line diff 會對不起來，很難 review。
建議 clone 下來，直接與 fixture file 對照 review（test file 倒不用開，因為 filter 或 sort rule 都有寫在 snapshot 名字上）
或者是直接 review 整個檔案：
https://github.com/cofacts/rumors-api/blob/9da6cb7c9fea987f5da7c1d22e9b41663d32194d/src/graphql/queries/__tests__/__snapshots__/ListArticles.js.snap
建議 clone 下來，直接與 fixture file 對照 review（test file 倒不用開，因為 filter 或 sort rule 都有寫在 snapshot 名字上）
或者是直接 review 整個檔案：
https://github.com/cofacts/rumors-api/blob/9da6cb7c9fea987f5da7c1d22e9b41663d32194d/src/graphql/queries/__tests__/__snapshots__/ListArticles.js.snap
拍謝 @yanglin5689446 我這一兩天會弄好 QQ 我這一兩天都只睡八小時十分昏沈
講錯了 我只醒著八小時⋯⋯
2020-04-17
好有趣, 不實資訊的交易所 XDDD
今天洗澡的時候想到
「標記分類」（送出 article category）原本的設計是希望幫助編輯。或許我們可以在編輯送出回應的那一瞬間，跳出一個東西（視窗之類，但可以 ESC dismiss 掉，完全選填），列出這個當下，訊息被標注的 category 們，逐一問編輯：
> 「OOO」這個分類有幫助你發現這則訊息嗎？
> 幫大忙了／沒幫助／它標錯了吧
> Does the category OOO help you find this message?
> Yes, it’s helpful / Nope / Err it’s mislabeled
「幫大忙了」--> 給該分類一個 positive feedback
「沒幫助」--> do nothing
「他標錯了吧」 --> 給該分類一個 negative feedback
因為這個時候編輯應該是在一個「剛做完大事 = 回應」的狀態，而且送出訊息這個 request 本來就有要花一兩秒，所以可以利用這個 timing 送這份小問卷收 `articleCategoryFeedback` 。如果編輯真的有被分類幫到忙，我覺得編輯不會吝嗇給「幫大忙了」。
若 `aricleCategory` 的 positive feedback > negative feedback，我覺得可以拿來算在使用者的經驗值 / 公道值裡面，因為助攻成功。若 `articleCategory` 是 AI 標的，這也有助於 online learning 收 user feedback。
`articleCategory` 經驗值獎勵這裡可以有更細緻的操作，如：一則訊息要有被回應之後，才會把 `articleCategory` 的 feedback 計算到 `articleCategory` 作者的經驗值裡，比較能鼓勵真正對「回應作業」有幫助、讓編輯心生感謝 (?) 的 category 標記；又或者是，如果某個編輯回了某文章，也給了該文章的某 category 好評，那麼標註該 category 的人可以得到「神助攻」Badge 之類的 (????) 這些都是可以討論的 nice-to-have 細節。
上面這些針對分類標註（ `articleCategory` ）的獎勵邏輯，也可以套用在「我也想知道」（`replyRequest` ）上，因為「我也想知道」也有 upvote 與 downvote。不過我覺得「我也想知道」這個東西不需要特別在送出回應之後，開個跳窗來問，因為有用的「我也想知道」敘述真的很顯眼（例如說直接貼連結告訴你謠言配圖之類的），我看到都會直接 upvote 感謝大大無私分享，所以應該不用特別問 XD
「標記分類」（送出 article category）原本的設計是希望幫助編輯。或許我們可以在編輯送出回應的那一瞬間，跳出一個東西（視窗之類，但可以 ESC dismiss 掉，完全選填），列出這個當下，訊息被標注的 category 們，逐一問編輯：
> 「OOO」這個分類有幫助你發現這則訊息嗎？
> 幫大忙了／沒幫助／它標錯了吧
> Does the category OOO help you find this message?
> Yes, it’s helpful / Nope / Err it’s mislabeled
「幫大忙了」--> 給該分類一個 positive feedback
「沒幫助」--> do nothing
「他標錯了吧」 --> 給該分類一個 negative feedback
因為這個時候編輯應該是在一個「剛做完大事 = 回應」的狀態，而且送出訊息這個 request 本來就有要花一兩秒，所以可以利用這個 timing 送這份小問卷收 `articleCategoryFeedback` 。如果編輯真的有被分類幫到忙，我覺得編輯不會吝嗇給「幫大忙了」。
若 `aricleCategory` 的 positive feedback > negative feedback，我覺得可以拿來算在使用者的經驗值 / 公道值裡面，因為助攻成功。若 `articleCategory` 是 AI 標的，這也有助於 online learning 收 user feedback。
`articleCategory` 經驗值獎勵這裡可以有更細緻的操作，如：一則訊息要有被回應之後，才會把 `articleCategory` 的 feedback 計算到 `articleCategory` 作者的經驗值裡，比較能鼓勵真正對「回應作業」有幫助、讓編輯心生感謝 (?) 的 category 標記；又或者是，如果某個編輯回了某文章，也給了該文章的某 category 好評，那麼標註該 category 的人可以得到「神助攻」Badge 之類的 (????) 這些都是可以討論的 nice-to-have 細節。
上面這些針對分類標註（ `articleCategory` ）的獎勵邏輯，也可以套用在「我也想知道」（`replyRequest` ）上，因為「我也想知道」也有 upvote 與 downvote。不過我覺得「我也想知道」這個東西不需要特別在送出回應之後，開個跳窗來問，因為有用的「我也想知道」敘述真的很顯眼（例如說直接貼連結告訴你謠言配圖之類的），我看到都會直接 upvote 感謝大大無私分享，所以應該不用特別問 XD
這個我想一下，不過是 out of scope 週六先開票存起來
剛剛才看到這段討論，站在建模的角度這裡的建議很實際也很有幫助
舉個例子來說 如果AI標註 `articleCategory` 並且收到 positve 的 `articleCategoryFeedback` 這樣這筆資料可以回存回去我們的labeled data pool
這個pool越大 越可以讓模型訓練得越精準
更進階的可以在收到 negative 的 `articleCategoryFeedback` 時，再問看看他覺得的 `articleCategory` ，這樣就可以把AI預測錯誤的類別也大量收集進 labeled data pool
另外這邊的我也想知道這個功能我沒有發囉，不過如果是類似推薦相關東西的話，這類search、QA、IR的AI我自己有在做 算是小有經驗
前陣子也有幫美國的一間新創做了一個COVID-19 paper search QA site：https://covid19.askmiso.com/
如果想開深一點坑的話可以討論 XD
*<https://github.com/cofacts/rumors-api/compare/090dc7a5382f...11637f462d09|2 new commits> pushed to <https://github.com/cofacts/rumors-api/tree/master|`master`>* <https://github.com/cofacts/rumors-api/commit/17a2f56d86d2abbef505db138b0713cf001f9657|`17a2f56d`> - Use range query for all artihmetic filters <https://github.com/cofacts/rumors-api/commit/11637f462d09e50607822e5a5d8609a4a1fcd62d|`11637f46`> - Merge pull request #161 from cofacts/refactor-arithmetic-filters
Pushing <https://github.com/cofacts/rumors-api/pull/161|#161> to staging yields the following error: <https://user-images.githubusercontent.com/108608/79492409-8e391280-8052-11ea-981b-0de78612f135.png|image> The query variable sent by UI is: ``` {filter: {replyRequestCount: {GT: 1}, replyCount: {EQ: 0}}, orderBy: [{lastRequestedAt: "DESC"}]} ``` Note that `EQ: 0` makes `EQ` falsy and `getRangeFieldParamFromArithmeticExpression` does not properly handle the case, generating `replyCount: {eq: 0}` as a elasticsearch range query This PR fixes `getRangeFieldParamFromArithmeticExpression` and adds unit test addressing `getRangeFieldParamFromArithmeticExpression`. Notice that this does not overlap with existing API test, since the API test connects to DB, and the unit test included in this PR tests boundary conditions that is too trivial to prepare DB fixtures for an API test.
@claudia0316 has joined the channel
這個我想一下，不過是 out of scope 週六先開票存起來
我現在大致確定拿到的時候是對的
但是只要 cache 讀就會變 null
而且只有名字部分
我在猜會不會是因為編碼？
因為我從 FB 拿到的名字是中文的
但是只要 cache 讀就會變 null
而且只有名字部分
我在猜會不會是因為編碼？
因為我從 FB 拿到的名字是中文的
忘記 try 了
我可能週六小聚之後才有空處理 ><
我可能週六小聚之後才有空處理 ><
- 👌1
我沒想過編碼耶
我以為 Network 面板裡，如果資料有進來的話，那就應該是 cache 的問題
好奇 name 欄位被 query 了幾次
會不會是後來 query 到 name 的時候，API 回傳了 null 給他，導致 cache 被 update 成 null 之類的（just wild guess, did not see network devtool)
我以為 Network 面板裡，如果資料有進來的話，那就應該是 cache 的問題
好奇 name 欄位被 query 了幾次
會不會是後來 query 到 name 的時候，API 回傳了 null 給他，導致 cache 被 update 成 null 之類的（just wild guess, did not see network devtool)
這我有想過
不過其他 articleReply 裡的 user 也都有 name 欄位
cache 裡其他 user 也都有 name
所以滿神奇的
不過其他 articleReply 裡的 user 也都有 name 欄位
cache 裡其他 user 也都有 name
所以滿神奇的
- 🧙♀️1
雖然 code 還在 review，不過我在本機端 build 了一個特別的 `cofacts-19` tag 的 rumors-api image，然後 push 到 docker hub 並且 deploy 在 staging 了。
現在 staging API 的 `ListArticles` 可以用 `hasArticleReplyWithMorePositiveFeedback` ，如果 staging site ( https://cofacts.hacktabl.org/articles ) 沒啥問題的話我會把它 deploy 到 production。
大家可以踩踩看 staging site 看新 API 有沒有 bug。
現在 staging API 的 `ListArticles` 可以用 `hasArticleReplyWithMorePositiveFeedback` ，如果 staging site ( https://cofacts.hacktabl.org/articles ) 沒啥問題的話我會把它 deploy 到 production。
大家可以踩踩看 staging site 看新 API 有沒有 bug。
• Collects articles that are replied but don't have more positive feedback than negative feedback • Replied articles are only considered when there are "too few not-replied articles" • Adds status column indicating if it's new an article (no-reply) or having reply <https://user-images.githubusercontent.com/108608/79538611-46000b80-80b7-11ea-875f-c730eb5e2ba5.png|image>
這個 PR 是 for 明天的小聚
如果要生成的連結數量比未回應文章多，就會加入最近的「有回應但 positive feedback 沒有比 negative feedback 多」的文章
有回應的前面會標 🈶，沒回應的會標 🆕
我覺得讓編輯先看看別人回的東西是什麼樣的、再來自己實際編輯，其實應該挺不錯的
如果要生成的連結數量比未回應文章多，就會加入最近的「有回應但 positive feedback 沒有比 negative feedback 多」的文章
有回應的前面會標 🈶，沒回應的會標 🆕
我覺得讓編輯先看看別人回的東西是什麼樣的、再來自己實際編輯，其實應該挺不錯的
這個 PR 是 for 明天的小聚
如果要生成的連結數量比未回應文章多，就會加入最近的「有回應但 positive feedback 沒有比 negative feedback 多」的文章
有回應的前面會標 🈶，沒回應的會標 🆕
我覺得讓編輯先看看別人回的東西是什麼樣的、再來自己實際編輯，其實應該挺不錯的
如果要生成的連結數量比未回應文章多，就會加入最近的「有回應但 positive feedback 沒有比 negative feedback 多」的文章
有回應的前面會標 🈶，沒回應的會標 🆕
我覺得讓編輯先看看別人回的東西是什麼樣的、再來自己實際編輯，其實應該挺不錯的
另一個我覺得可以做的是， Instant 頁面可以加上計算「有正評回應的文章數」
這樣小聚時有人按 ⭕ 的時候，數字就會變多～
這樣小聚時有人按 ⭕ 的時候，數字就會變多～
像這樣～～
但如果有人看到現有回應不夠好，改成回新的回應的話，會無法被這個捕捉到。
不過我們可以修改 `/instant` 讓他列出所有 `repliedAt > 開始時間` 的文章數 XD
（感恩新 API 讚嘆新 API）
（感恩新 API 讚嘆新 API）
好了，這樣回應已經被回過的文章，也可以被捕捉了
直播的時候就顯示兩種 instant 數字：
• 回覆文章數
• 有效回應新覆蓋文章數
直播的時候就顯示兩種 instant 數字：
• 回覆文章數
• 有效回應新覆蓋文章數
Replied to a thread: 2020-04-13 20:33:35
後來我試了發現
CreateOrUpdateArticleReplyFeedback 的 feedback 回傳的 response 裡
user 的 name 就是 null
不太確定是後端沒有更新到還是怎樣(其他欄位都有)
有稍微看一下後端那段 code 可是沒看出什麼端倪@@
CreateOrUpdateArticleReplyFeedback 的 feedback 回傳的 response 裡
user 的 name 就是 null
不太確定是後端沒有更新到還是怎樣(其他欄位都有)
有稍微看一下後端那段 code 可是沒看出什麼端倪@@
- 😮1
但如果有人看到現有回應不夠好，改成回新的回應的話，會無法被這個捕捉到。
不過我們可以修改 `/instant` 讓他列出所有 `repliedAt > 開始時間` 的文章數 XD
（感恩新 API 讚嘆新 API）
（感恩新 API 讚嘆新 API）
好了，這樣回應已經被回過的文章，也可以被捕捉了
直播的時候就顯示兩種 instant 數字：
• 回覆文章數
• 有效回應新覆蓋文章數
直播的時候就顯示兩種 instant 數字：
• 回覆文章數
• 有效回應新覆蓋文章數
YouTube
剛剛才看到這段討論，站在建模的角度這裡的建議很實際也很有幫助
舉個例子來說 如果AI標註 `articleCategory` 並且收到 positve 的 `articleCategoryFeedback` 這樣這筆資料可以回存回去我們的labeled data pool
這個pool越大 越可以讓模型訓練得越精準
更進階的可以在收到 negative 的 `articleCategoryFeedback` 時，再問看看他覺得的 `articleCategory` ，這樣就可以把AI預測錯誤的類別也大量收集進 labeled data pool
另外這邊的我也想知道這個功能我沒有發囉，不過如果是類似推薦相關東西的話，這類search、QA、IR的AI我自己有在做 算是小有經驗
前陣子也有幫美國的一間新創做了一個COVID-19 paper search QA site：https://covid19.askmiso.com/
covid19.askmiso.com
Ask questions, get answers. We’ve built a Q&A Engine using the latest breakthroughs in Natural Language Understanding to help researchers, medical professionals and public health officials in the fight against COVID-19. Powered by 7.5K peer-review and pre-print research papers and guidelines from the CDC, WHO and leading health experts around the world.
如果想開深一點坑的話可以討論 XD
2020-04-18
*<https://github.com/cofacts/need-to-check-list-generator/compare/eccf49e10847...6bc3234dedfa|2 new commits> pushed to <https://github.com/cofacts/need-to-check-list-generator/tree/master|`master`>* <https://github.com/cofacts/need-to-check-list-generator/commit/80c398f0178318b93b8bb9b2ea0ab6618825b494|`80c398f0`> - Loads replied but not-enough-feedback articles when requesting amount exceeds no-reply message count <https://github.com/cofacts/need-to-check-list-generator/commit/6bc3234dedfadfc261c4dc82e9f6aa4bf2394231|`6bc3234d`> - Merge pull request #4 from cofacts/not-enough-feedback
https://www.facebook.com/cofacts.tw/videos/1099411597112523/
Cofacts正在進行雲上面的第19次編輯小聚，每15分鐘會有鄰鄰朗讀兩則謠言。
三點會有MrOrz新任務與頁面教學。(鄰鄰休息一次)
Cofacts正在進行雲上面的第19次編輯小聚，每15分鐘會有鄰鄰朗讀兩則謠言。
三點會有MrOrz新任務與頁面教學。(鄰鄰休息一次)
- 👍3
@df95111111 has joined the channel
2020-04-19
@yanglin5689446 關於 https://github.com/cofacts/rumors-site/pull/247/ 我注意到 `withData` HOC 從 page component (如 `ArticleListPage`) 被移動到 `<AppLayout>` 裡面的事情。
想問一下這個變更的考量是什麼呢？是說這樣 `withData` 裡的 `getInitialProps` 在 SSR 時會正常呼叫嗎？因為根據 Next.JS 文件，只有 page componet 的 `getInitialProps` 會被呼叫。
想問一下這個變更的考量是什麼呢？是說這樣 `withData` 裡的 `getInitialProps` 在 SSR 時會正常呼叫嗎？因為根據 Next.JS 文件，只有 page componet 的 `getInitialProps` 會被呼叫。
因為現在大部分的頁面都有類似的排版
所以我把共用的邏輯抽成一個 Components 讓每個頁面共用
`withData` 我倒是沒有注意到有沒有差別 @@
所以我把共用的邏輯抽成一個 Components 讓每個頁面共用
`withData` 我倒是沒有注意到有沒有差別 @@
了解
@stbb1025 article detail page的規格訂完了，再麻煩你調整一下
- ❤️1
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0
我也更新完囉，有一些細節想明天跟大家討論～
@lucien @mrorz @yanglin5689446
我也更新完囉，有一些細節想明天跟大家討論～
@lucien @mrorz @yanglin5689446
關於 article detail 資料來源的部分，其實有很多不同的樣態：
• 分段、一說明多 URL https://cofacts.g0v.tw/article/2jxmk2uww4sz
• 多則 ＵＲＬ https://cofacts.g0v.tw/article/36p22bx1xoxmg
之前討論的結果是大輸入框 + 輔助工具這樣，就不會限制一定要一筆一筆的
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg#%E8%A8%AD%E8%A8%88
• 分段、一說明多 URL https://cofacts.g0v.tw/article/2jxmk2uww4sz
• 多則 ＵＲＬ https://cofacts.g0v.tw/article/36p22bx1xoxmg
之前討論的結果是大輸入框 + 輔助工具這樣，就不會限制一定要一筆一筆的
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg#%E8%A8%AD%E8%A8%88
好唷，不過這樣的操作邏輯比較像工程師，對一般使用者負擔會不會有點大呢？
其實更簡單的做法是
沒有字的時候顯示淡淡的 placeholder 說可以這樣做
一但打字就消失這樣 XD
沒有字的時候顯示淡淡的 placeholder 說可以這樣做
一但打字就消失這樣 XD
可以看我的新設計
都已經考慮了
有快速輸入也有place holder
有我有看到哈哈，只是當時覺得放在同一個大框框裡視覺上不是很直覺
就先做成我做的那樣
但我的作法的確要放上多個url會比較多點擊，不過我想知道現在平均每篇回應放的url數量跟最多放的url數量是多少？
我原本設計比較像你做的
但後來討論後改掉了
但你這種設計還少了刪除跟新增的互動
我怎麼判斷要多加一欄跟刪除呢
新增就點上面加號囉
我原本是另外有新增跟刪除按鈕
刪除的話留空就是沒有
再來是因為line只能純文字顯示
這樣排版使用者無法預覽他的東西在line是怎麼排的
如果系統有統一整齊的排法，使用者不用去擔心在line是怎麼排的吧
而且即便是讓使用者去排版，網站上的輸入框也不會模擬出line上面呈現的樣子XD
但基本上是的哈哈
因為line就是純文字訊息
不過更重要是power user的編輯像是orz他們就不能用自由的方式編輯了
他們撐起很多的查核，不能限制他們的輸出
哈哈對啊這是需要衡量的地方，我其實覺得都可以。如果重心要在普羅大眾的話我會偏好我的版本，但我想你們上禮拜討論的應該是基於power user居多XD
如果大家都討論出來是自由度高的方式的話我覺得就以那個為主～
然後其實有一個想法是做兩個模式
但變成是原本的文字框版本還是要
已開發來說成本變高了
嗯嗯，我覺得順序而言還是先以power user優先好了
兩個選項的差異大概就像
wix 跟純原始碼開發網頁的差異XD
wix 跟純原始碼開發網頁的差異XD
我覺得先看看六月過後，有沒有時間再加
ok ok
不過 `withData` 做的事情其實跟 layout 不太相關，而是 data fetching
也有 SSR 的邏輯：https://github.com/adamsoffer/next-apollo/blob/master/src/withData.js
也有 SSR 的邏輯：https://github.com/adamsoffer/next-apollo/blob/master/src/withData.js
看 code 覺得這樣 SSR 應該是會整個壞掉 @@
我 pull 下來 try try
我 pull 下來 try try
這是 commit `852a8b7` 時，`/articles` 拿到的 HTML，可以看到 SSR 的文章列表
下一個 commit `bb9e685` 把 `withData` 從 articles.js 抽走之後，文章列表就已經不會 SSR 了，代表搜尋引擎看到的文章列表永遠是空的。
@yanglin5689446 我覺得 display component 如何重構是可以多方嘗試，但是 `withData` HOC 應該要拿回來到 page component 裏頭，因為他真的只能在 page component 才拿發揮作用。
@yanglin5689446 我覺得 display component 如何重構是可以多方嘗試，但是 `withData` HOC 應該要拿回來到 page component 裏頭，因為他真的只能在 page component 才拿發揮作用。
這是 commit `852a8b7` 時，`/articles` 拿到的 HTML，可以看到 SSR 的文章列表
下一個 commit `bb9e685` 把 `withData` 從 articles.js 抽走之後，文章列表就已經不會 SSR 了，代表搜尋引擎看到的文章列表永遠是空的。
@yanglin5689446 我覺得 display component 如何重構是可以多方嘗試，但是 `withData` HOC 應該要拿回來到 page component 裏頭，因為他真的只能在 page component 才拿發揮作用。
@yanglin5689446 我覺得 display component 如何重構是可以多方嘗試，但是 `withData` HOC 應該要拿回來到 page component 裏頭，因為他真的只能在 page component 才拿發揮作用。
- 👌1
看到有在改 `AppLayout`
想許個願：讓 footer 黏在螢幕底端 XD
可能要 style 一下 `#__next` 讓他變成 `min-height:100%` 的 column 方向 flex container
想許個願：讓 footer 黏在螢幕底端 XD
可能要 style 一下 `#__next` 讓他變成 `min-height:100%` 的 column 方向 flex container
- 👌1
@sandy051122 has joined the channel
嗨嗨 請問這裡有缺工程師嗎？我是Ish，以前做過NodeJs backend工程師，然後現在是全端 Java + AngularJS (主) / ReactJS
歡迎 @sandy051122 ~~
可以參考開發者首頁，
我們有整理 good first issue 唷
https://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252Fr1nfwTrgM
可以參考開發者首頁，
我們有整理 good first issue 唷
https://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252Fr1nfwTrgM
好喔 謝謝!
歡迎 @sandy051122 ~~
可以參考開發者首頁，
我們有整理 good first issue 唷
https://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252Fr1nfwTrgM
可以參考開發者首頁，
我們有整理 good first issue 唷
https://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252Fr1nfwTrgM
好喔 謝謝!
@yanglin5689446 https://github.com/cofacts/rumors-site/pull/247 看完了
我覺得若有餘裕的話，其實有些 component，例如說一些小 filter，其實可以在 storybook 裡面做一做之後就丟個 PR，會比較好 review 唷。
我覺得若有餘裕的話，其實有些 component，例如說一些小 filter，其實可以在 storybook 裡面做一做之後就丟個 PR，會比較好 review 唷。
☑︎ new article list UI ☑︎ new replies page UI ☑︎ search bar ☑︎ hoax for you page ☑︎ search result page(wip) ☐ paginator
- 👌1
OKOK
後面改善一些小東西的部分我應該會 PR 拆細一點
也比較好 review
這些頁面的部分 scope 比較大有點難拆
後面改善一些小東西的部分我應該會 PR 拆細一點
也比較好 review
這些頁面的部分 scope 比較大有點難拆
Paginator 我覺得就滿適合分個 PR XD
這個 PR 修掉 comment 裡面的東西就差不多囉
這個 PR 修掉 comment 裡面的東西就差不多囉
OKOK
後面改善一些小東西的部分我應該會 PR 拆細一點
也比較好 review
這些頁面的部分 scope 比較大有點難拆
後面改善一些小東西的部分我應該會 PR 拆細一點
也比較好 review
這些頁面的部分 scope 比較大有點難拆
1
Paginator 我覺得就滿適合分個 PR XD
這個 PR 修掉 comment 裡面的東西就差不多囉
這個 PR 修掉 comment 裡面的東西就差不多囉
2020-04-20
*<https://github.com/cofacts/rumors-db/compare/2a54a2bc98fb...8d899c733cde|3 new commits> pushed to <https://github.com/cofacts/rumors-db/tree/master|`master`>* <https://github.com/cofacts/rumors-db/commit/6a3ccd206485c13883cd927093d479d7a0760927|`6a3ccd20`> - Add migration script <https://github.com/cofacts/rumors-db/commit/0245ab6295b82e3f23c93a9a2cbf31af13ba99a5|`0245ab62`> - Use .env.sample <https://github.com/cofacts/rumors-db/commit/8d899c733cde5f35c1939f5b53ed1e3143204540|`8d899c73`> - Merge pull request #39 from cofacts/features/migrate-category
@taco625652 has joined the channel
*<https://github.com/cofacts/rumors-ai/compare/58ed6838c5fb...6d4053f5c4aa|1 new commit> pushed to <https://github.com/cofacts/rumors-ai/tree/master|`master`>* <https://github.com/cofacts/rumors-ai/commit/6d4053f5c4aa419b1a4ef89d58a5d19bb16da651|`6d4053f5`> - Add drafted repo structure and jupyter notebook version of Categorizer
今天 LINE bot 特別忙⋯⋯
都在查確診者足跡嗎
都在查確診者足跡嗎
1- 👣2
手動把 LINE bot 機器調成 1GB 的囉
如果是下午一點後可能噢
手動把 LINE bot 機器調成 1GB 的囉
- ✨1
- 🥇1
如果是下午一點後可能噢
@mrorz 想請教一個問題
假如我的 `ArticleReplyFeedbackData` 裡面有包含 feedbacks 的 field
這樣展開是可以的嗎？
```articleReplies(status: NORMAL) {
articleId
replyId
feedbacks {
...Feedback
}
...ArticleReplyFeedbackData
}```
假如我的 `ArticleReplyFeedbackData` 裡面有包含 feedbacks 的 field
這樣展開是可以的嗎？
```articleReplies(status: NORMAL) {
articleId
replyId
feedbacks {
...Feedback
}
...ArticleReplyFeedbackData
}```
他會自己 merge 與 dedup
可以
因為我之前在 `ArticleItem` 裡面有展開 `ReplyItem` 了
但是還是拿不到資料
我猜是因為 `ReplyItem` 是透過 `articleReplies` 去關聯資料
如果展開會變成
```Article {
articleReplies {
reply {
articleReplies {
...
}
}
}
}```
的關係？
但是還是拿不到資料
我猜是因為 `ReplyItem` 是透過 `articleReplies` 去關聯資料
如果展開會變成
```Article {
articleReplies {
reply {
articleReplies {
...
}
}
}
}```
的關係？
自問自答：是
自己把 articleReplies 的部分拆出去展開
自己把 articleReplies 的部分拆出去展開
對， article 的 articleReply 是那個 article 連到的 articleReply
reply 的 articleReply 是一個 reply 連到的 articleReply
因為 article 與 reply 多對多，所以相連的 article 與 reply，articleReply 只有在「除了彼此之外沒有再與其他篇連結」的狀況下有可能會相同
reply 的 articleReply 是一個 reply 連到的 articleReply
因為 article 與 reply 多對多，所以相連的 article 與 reply，articleReply 只有在「除了彼此之外沒有再與其他篇連結」的狀況下有可能會相同
自問自答：是
自己把 articleReplies 的部分拆出去展開
自己把 articleReplies 的部分拆出去展開
對， article 的 articleReply 是那個 article 連到的 articleReply
reply 的 articleReply 是一個 reply 連到的 articleReply
因為 article 與 reply 多對多，所以相連的 article 與 reply，articleReply 只有在「除了彼此之外沒有再與其他篇連結」的狀況下有可能會相同
reply 的 articleReply 是一個 reply 連到的 articleReply
因為 article 與 reply 多對多，所以相連的 article 與 reply，articleReply 只有在「除了彼此之外沒有再與其他篇連結」的狀況下有可能會相同
是說有些跟 svg 有關的細節沒上是因為有些設計上要讓 icon 能換顏色
我想說改成 svg 應該會方便些
不過現在的專案中好像沒有設定 svg loader?
我想說改成 svg 應該會方便些
不過現在的專案中好像沒有設定 svg loader?
在做的時候想說要弄的話不知道會不會影響到其他功能
結果忘記問ㄌ
結果忘記問ㄌ
next.js 沒有 svg loader 嗎驚
應該是沒有 inline svg 的東西就是了
應該是沒有 inline svg 的東西就是了
應該說要設定 webpack loader 吧
一般 svg 只會被當作 IMG 引入(?
一般 svg 只會被當作 IMG 引入(?
其實 next.js 後面應該也是用 url-loader 處理 svg file
所以最後不是 data-url 就是 path，不是 inline svg
所以最後不是 data-url 就是 path，不是 inline svg
我覺得 svg 應該直接複製檔案內容來包成 React component
這樣就用不靠任何 loader XD
也可以
這樣你也能亂塞 prop 進去
好像還可以用這個
https://material-ui.com/components/icons/#svgicon
把 `<svg viewBox="xxx">` 取代成 `<SvgIcon viewBox="xxx">`
https://material-ui.com/components/icons/#svgicon
把 `<svg viewBox="xxx">` 取代成 `<SvgIcon viewBox="xxx">`
看起來很不錯
在做的時候想說要弄的話不知道會不會影響到其他功能
結果忘記問ㄌ
結果忘記問ㄌ
next.js 沒有 svg loader 嗎驚
應該是沒有 inline svg 的東西就是了
應該是沒有 inline svg 的東西就是了
應該說要設定 webpack loader 吧
一般 svg 只會被當作 IMG 引入(?
一般 svg 只會被當作 IMG 引入(?
其實 next.js 後面應該也是用 url-loader 處理 svg file
所以最後不是 data-url 就是 path，不是 inline svg
所以最後不是 data-url 就是 path，不是 inline svg
我覺得 svg 應該直接複製檔案內容來包成 React component
- 👌1
這樣就用不靠任何 loader XD
也可以
這樣你也能亂塞 prop 進去
好像還可以用這個
https://material-ui.com/components/icons/#svgicon
把 `<svg viewBox="xxx">` 取代成 `<SvgIcon viewBox="xxx">`
https://material-ui.com/components/icons/#svgicon
把 `<svg viewBox="xxx">` 取代成 `<SvgIcon viewBox="xxx">`
material-ui.com
Guidance and suggestions for using icons with Material-UI.
看起來很不錯
2020-04-21
*<https://github.com/cofacts/rumors-api/compare/11637f462d09...62195028e592|2 new commits> pushed to <https://github.com/cofacts/rumors-api/tree/master|`master`>* <https://github.com/cofacts/rumors-api/commit/c1c04a53b12b36fc14f87414cb102adde152588c|`c1c04a53`> - [graphql] fix GT: 0 bug <https://github.com/cofacts/rumors-api/commit/62195028e5921484b82a0b0e9a8edc318a7636ee|`62195028`> - Merge pull request #163 from cofacts/bugfix-gt-0
*<https://github.com/cofacts/rumors-api/compare/62195028e592...4e8354b1aed3|3 new commits> pushed to <https://github.com/cofacts/rumors-api/tree/master|`master`>* <https://github.com/cofacts/rumors-api/commit/31feb7297ef3a6ba7682d41c748bf927108f92d2|`31feb729`> - [ListArticles] implements hasArticleReplyWithMorePositiveFeedback and organizes ListArticles fixtures <https://github.com/cofacts/rumors-api/commit/6326dd2483427f6e9cc8723322b78a94f81cfd14|`6326dd24`> - [package.json] upgrade graphql to fix apollo-engine validation file missing error <https://github.com/cofacts/rumors-api/commit/4e8354b1aed320fc76cdeb09a4c1468822e09956|`4e8354b1`> - Merge pull request #162 from cofacts/filter-article-with-feedback
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=681%3A0
我也更新完囉，有一些細節想明天跟大家討論～
@lucien @mrorz @yanglin5689446
我也更新完囉，有一些細節想明天跟大家討論～
@lucien @mrorz @yanglin5689446
關於 article detail 資料來源的部分，其實有很多不同的樣態：
• 分段、一說明多 URL https://cofacts.g0v.tw/article/2jxmk2uww4sz
• 多則 ＵＲＬ https://cofacts.g0v.tw/article/36p22bx1xoxmg
之前討論的結果是大輸入框 + 輔助工具這樣，就不會限制一定要一筆一筆的
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg#%E8%A8%AD%E8%A8%88
• 分段、一說明多 URL https://cofacts.g0v.tw/article/2jxmk2uww4sz
• 多則 ＵＲＬ https://cofacts.g0v.tw/article/36p22bx1xoxmg
之前討論的結果是大輸入框 + 輔助工具這樣，就不會限制一定要一筆一筆的
https://g0v.hackmd.io/fRDzVwdqSduSlI-BBBK3Jg#%E8%A8%AD%E8%A8%88
好唷，不過這樣的操作邏輯比較像工程師，對一般使用者負擔會不會有點大呢？
其實更簡單的做法是
沒有字的時候顯示淡淡的 placeholder 說可以這樣做
一但打字就消失這樣 XD
沒有字的時候顯示淡淡的 placeholder 說可以這樣做
一但打字就消失這樣 XD
可以看我的新設計
都已經考慮了
有快速輸入也有place holder
有我有看到哈哈，只是當時覺得放在同一個大框框裡視覺上不是很直覺
就先做成我做的那樣
但我的作法的確要放上多個url會比較多點擊，不過我想知道現在平均每篇回應放的url數量跟最多放的url數量是多少？
我原本設計比較像你做的
但後來討論後改掉了
但你這種設計還少了刪除跟新增的互動
我怎麼判斷要多加一欄跟刪除呢
新增就點上面加號囉
我原本是另外有新增跟刪除按鈕
刪除的話留空就是沒有
再來是因為line只能純文字顯示
這樣排版使用者無法預覽他的東西在line是怎麼排的
如果系統有統一整齊的排法，使用者不用去擔心在line是怎麼排的吧
而且即便是讓使用者去排版，網站上的輸入框也不會模擬出line上面呈現的樣子XD
但基本上是的哈哈
因為line就是純文字訊息
不過更重要是power user的編輯像是orz他們就不能用自由的方式編輯了
他們撐起很多的查核，不能限制他們的輸出
哈哈對啊這是需要衡量的地方，我其實覺得都可以。如果重心要在普羅大眾的話我會偏好我的版本，但我想你們上禮拜討論的應該是基於power user居多XD
如果大家都討論出來是自由度高的方式的話我覺得就以那個為主～
然後其實有一個想法是做兩個模式
但變成是原本的文字框版本還是要
已開發來說成本變高了
嗯嗯，我覺得順序而言還是先以power user優先好了
兩個選項的差異大概就像
wix 跟純原始碼開發網頁的差異XD
wix 跟純原始碼開發網頁的差異XD
我覺得先看看六月過後，有沒有時間再加
ok ok
Try node 12?
https://github.com/fsevents/fsevents/issues/291
https://github.com/fsevents/fsevents/issues/291
fsevent 的版本好像很老了
不知道是誰的 dependency QQ
不知道是誰的 dependency QQ
2020-04-22
Try node 12?
https://github.com/fsevents/fsevents/issues/291
https://github.com/fsevents/fsevents/issues/291
There are currently no pre-compiled binaries for node v13, so installation fails: ``` node-pre-gyp info it worked if it ends with ok node-pre-gyp info using node-pre-gyp@0.12.0 node-pre-gyp info using node@13.0.1 | darwin | x64 node-pre-gyp WARN Using request for node-pre-gyp https download node-pre-gyp info check checked for \"/blabla/node_modules/fsevents/lib/binding/Release/node-v79-darwin-x64/fse.node\" (not found) node-pre-gyp http GET <https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.9/fse-v1.2.9-node-v79-darwin-x64.tar.gz> node-pre-gyp http 404 <https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.9/fse-v1.2.9-node-v79-darwin-x64.tar.gz> node-pre-gyp WARN Tried to download(404): <https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.9/fse-v1.2.9-node-v79-darwin-x64.tar.gz> node-pre-gyp WARN Pre-built binaries not found for fsevents@1.2.9 and node@13.0.1 (node-v79 ABI, unknown) (falling back to source compile with node-gyp) node-pre-gyp http 404 status code downloading tarball <https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.9/fse-v1.2.9-node-v79-darwin-x64.tar.gz> gyp info it worked if it ends with ok gyp info using node-gyp@5.0.5 gyp info using node@13.0.1 | darwin | x64 gyp info ok gyp info it worked if it ends with ok gyp info using node-gyp@5.0.5 gyp info using node@13.0.1 | darwin | x64 gyp info find Python using Python version 3.6.7 found at \"/bla/.pyenv/versions/3.6.7/bin/python\" gyp info spawn /bla/.pyenv/versions/3.6.7/bin/python gyp info spawn args [ gyp info spawn args '/blabla/node_modules/node-gyp/gyp/gyp_main.py', gyp info spawn args 'binding.gyp', gyp info spawn args '-f', gyp info spawn args 'make', gyp info spawn args '-I', gyp info spawn args '/blabla/node_modules/fsevents/build/config.gypi', gyp info spawn args '-I', gyp info spawn args '/blabla/node_modules/node-gyp/addon.gypi', gyp info spawn args '-I', gyp info spawn args '/bla/Library/Caches/node-gyp/13.0.1/include/node/common.gypi', gyp info spawn args '-Dlibrary=shared_library', gyp info spawn args '-Dvisibility=default', gyp info spawn args '-Dnode_root_dir=/bla/Library/Caches/node-gyp/13.0.1', gyp info spawn args '-Dnode_gyp_dir=/blabla/node_modules/node-gyp', gyp info spawn args '-Dnode_lib_file=/bla/Library/Caches/node-gyp/13.0.1/<(target_arch)/node.lib', gyp info spawn args '-Dmodule_root_dir=/blabla/node_modules/fsevents', gyp info spawn args '-Dnode_engine=v8', gyp info spawn args '--depth=.', gyp info spawn args '--no-parallel', gyp info spawn args '--generator-output', gyp info spawn args 'build', gyp info spawn args '-Goutput_dir=.' gyp info spawn args ] Traceback (most recent call last): File \"/blabla/node_modules/node-gyp/gyp/gyp_main.py\", line 50, in <module> sys.exit(gyp.script_main()) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/__init__.py\", line 554, in script_main return main(sys.argv[1:]) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/__init__.py\", line 547, in main return gyp_main(args) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/__init__.py\", line 532, in gyp_main generator.GenerateOutput(flat_list, targets, data, params) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py\", line 2215, in GenerateOutput part_of_all=qualified_target in needed_targets) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py\", line 802, in Write self.WriteCopies(spec['copies'], extra_outputs, part_of_all) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py\", line 1145, in WriteCopies env = self.GetSortedXcodeEnv() File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py\", line 1885, in GetSortedXcodeEnv additional_settings) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py\", line 1616, in GetSortedXcodeEnv additional_settings) File \"/blabla/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py\", line 1527, in _GetXcodeEnv if XcodeVersion() >= '0500' and not env.get('SDKROOT'): TypeError: '>=' not supported between instances of 'tuple' and 'str' gyp ERR! configure error gyp ERR! stack Error: `gyp` failed with exit code: 1 gyp ERR! stack at ChildProcess.onCpExit (/blabla/node_modules/node-gyp/lib/configure.js:351:16) gyp ERR! stack at ChildProcess.emit (events.js:210:5) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12) gyp ERR! System Darwin 18.7.0 gyp ERR! command \"/bla/.nvm/versions/node/v13.0.1/bin/node\" \"/blabla/node_modules/node-gyp/bin/node-gyp.js\" \"configure\" \"--fallback-to-build\" \"--module=/blabla/node_modules/fsevents/lib/binding/Release/node-v79-darwin-x64/fse.node\" \"--module_name=fse\" \"--module_path=/blabla/node_modules/fsevents/lib/binding/Release/node-v79-darwin-x64\" \"--napi_version=5\" \"--node_abi_napi=napi\" \"--napi_build_version=0\" \"--node_napi_label=node-v79\" gyp ERR! cwd /blabla/node_modules/fsevents gyp ERR! node -v v13.0.1 gyp ERR! node-gyp -v v5.0.5 gyp ERR! not ok node-pre-gyp ERR! build error node-pre-gyp ERR! stack Error: Failed to execute '/bla/.nvm/versions/node/v13.0.1/bin/node /blabla/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/blabla/node_modules/fsevents/lib/binding/Release/node-v79-darwin-x64/fse.node --module_name=fse --module_path=/blabla/node_modules/fsevents/lib/binding/Release/node-v79-darwin-x64 --napi_version=5 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v79' (1) node-pre-gyp ERR! stack at ChildProcess.<anonymous> (/blabla/node_modules/fsevents/node_modules/node-pre-gyp/lib/util/compile.js:83:29) node-pre-gyp ERR! stack at ChildProcess.emit (events.js:210:5) node-pre-gyp ERR! stack at maybeClose (internal/child_process.js:1028:16) node-pre-gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5) node-pre-gyp ERR! System Darwin 18.7.0 node-pre-gyp ERR! command \"/bla/.nvm/versions/node/v13.0.1/bin/node\" \"/blabla/node_modules/fsevents/node_modules/node-pre-gyp/bin/node-pre-gyp\" \"install\" \"--fallback-to-build\" node-pre-gyp ERR! cwd /blabla/node_modules/fsevents node-pre-gyp ERR! node -v v13.0.1 node-pre-gyp ERR! node-pre-gyp -v v0.12.0 node-pre-gyp ERR! not ok ```
- 👍1
fsevent 的版本好像很老了
不知道是誰的 dependency QQ
不知道是誰的 dependency QQ
今天線上開會ㄛ
雖然我今天
已經線上面試了兩個人
中午跟兩個面試中間各自都有視訊會議
都坐在同一張椅子上，真方便 (?
雖然我今天
已經線上面試了兩個人
中午跟兩個面試中間各自都有視訊會議
都坐在同一張椅子上，真方便 (?
- 😆1
會變胖。（我的慘痛經驗）
會變胖。（我的慘痛經驗）
- 😱1
！會議結束了嗎
meet.jit.si
Powercall 今天會隨機 mute 人，完全不知道為啥
" 🤔 有 2 人想知道以下訊息的真實性 ”
@stbb1025 staging site 現在有 @yanglin5689446 做的 navbar UI 囉
http://cofacts.hacktabl.org/articles
article list 的還在 review~ ( https://github.com/cofacts/rumors-site/pull/247 )
http://cofacts.hacktabl.org/articles
article list 的還在 review~ ( https://github.com/cofacts/rumors-site/pull/247 )
☑︎ new article list UI ☑︎ new replies page UI ☑︎ search bar ☑︎ hoax for you page ☑︎ search result page(wip) ☐ paginator
@stbb1025 導航列跟文字沒有垂直剛剛好對齊是因為 logo svg viewport 位置問題，可以重出一版上
然後你會覺得導航文字要跟 logo 文字 大家的關係要調整嗎？比如說導航文字現在看起來是比較大，要調成一樣或是比較小嗎？
對我覺得要調小一點 XD
導航列跟文字沒有垂直剛剛好對齊是因為 logo svg viewport 位置問題，可以重出一版上
這段不是很懂><
這段不是很懂><
@lucien
垂直置中
但那應該是因為有 user 的 app id 是 `DEVELOPMENT_BACKEND` 的關係。因此，其實 reply 或任何東西的 user 都有可能是 null，程式邏輯上不能有任何地方沒有先檢查 user 不是 null 就直接存取 user 唷。
cc/ @yanglin5689446
cc/ @yanglin5689446
Staging 上某 reply 的 user 是 null
localhost 上則不是 null
這其實是當時為了讓 localhost 開發方便，
訂有讓 localhost 可以看到 app_id = `DEVEOPMENT_BACKEND` 的使用者的緣故
https://github.com/cofacts/rumors-api/blob/master/src/graphql/models/User.js#L113-L115
其實只要是 localhost:3000 接上 API server 之後，就能打 mutation，這其實不太安全，所以才做了這種 `DEVELOPMENT_BACKEND` 機制，特別允許這種 localhost:3000 的 request，只是安上不同 appId https://github.com/cofacts/rumors-api/blob/master/src/checkHeaders.js#L37-L42
訂有讓 localhost 可以看到 app_id = `DEVEOPMENT_BACKEND` 的使用者的緣故
https://github.com/cofacts/rumors-api/blob/master/src/graphql/models/User.js#L113-L115
其實只要是 localhost:3000 接上 API server 之後，就能打 mutation，這其實不太安全，所以才做了這種 `DEVELOPMENT_BACKEND` 機制，特別允許這種 localhost:3000 的 request，只是安上不同 appId https://github.com/cofacts/rumors-api/blob/master/src/checkHeaders.js#L37-L42
而 staging 上那個造成 exception 的 reply，app_id 確實是 `DEVELOPMENT_BACKEND` @@
```{
"_index" : "replies_v1_0_2",
"_type" : "doc",
"_id" : "jD2sy3EBrIRcahlYXQri",
"_version" : 2,
"found" : true,
"_source" : {
"userId" : "hD1qunEBrIRcahlYYQoi",
"appId" : "DEVELOPMENT_FRONTEND",
"type" : "NOT_ARTICLE",
"text" : "fasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdffasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdffasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdf",
"reference" : "fasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdf",
"createdAt" : "2020-04-30T15:20:03.289Z",
"hyperlinks" : [ ]
}
}```
```{
"_index" : "replies_v1_0_2",
"_type" : "doc",
"_id" : "jD2sy3EBrIRcahlYXQri",
"_version" : 2,
"found" : true,
"_source" : {
"userId" : "hD1qunEBrIRcahlYYQoi",
"appId" : "DEVELOPMENT_FRONTEND",
"type" : "NOT_ARTICLE",
"text" : "fasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdffasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdffasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdf",
"reference" : "fasdfasdfadsfasdfadsfasdfadsfadsfadsfadsfadsfadsfadsfasdf",
"createdAt" : "2020-04-30T15:20:03.289Z",
"hyperlinks" : [ ]
}
}```
還是其實我應該做的是在 staging 開放 localhost 但 production 不開放
把 `DEVELOPMENT_BACKEND` 機制整個淘汰掉
以及把資料庫內所有 appId = `DEVELOPMENT_BACKEND` 的東西都砍掉？
把 `DEVELOPMENT_BACKEND` 機制整個淘汰掉
以及把資料庫內所有 appId = `DEVELOPMENT_BACKEND` 的東西都砍掉？
但這樣就無法模擬有不同 appId 的狀況就是了 QQ
翻譯還沒有好
哪個翻譯
喔對耶
哪個翻譯
2020-04-23
喔對耶
In <https://cofacts.g0v.tw/article/i0yh2jv8zn5c|https://cofacts.g0v.tw/article/i0yh2jv8zn5c> there are more than 10 replyRequests; however, only the first 10 is returned in the API. This causes that newly submitted replyRequests disappear: <https://user-images.githubusercontent.com/108608/80057284-bea01580-8558-11ea-87bb-7bc436fb80a3.gif|missing-rq>
*CUP
傳統上，國家、政府和某些國際組織把持著調查案件的權力和資源，面對涉及政權的衝突、懸疑未解的國際爭議，升斗市民是否就無計可施，只能被動地等結論？在網絡發達、資訊唾手可得的今天，Bellingcat 告訴世人：只要適當運用科技、智慧、觀察力和耐性，人人都可以為捍衛真相出一分力。
bellingcat
Reverse image search is one of the most well-known and easiest digital investigative techniques, with two-click functionality of choosing “Search Google for image” in many web browsers. This method has also seen widespread use in popular culture, perhaps most notably in the MTV show Catfish, which exposes people in online relationships who use stolen photographs...
- 1
- 👍1
@stbb1025 導航列跟文字沒有垂直剛剛好對齊是因為 logo svg viewport 位置問題，可以重出一版上
然後你會覺得導航文字要跟 logo 文字 大家的關係要調整嗎？比如說導航文字現在看起來是比較大，要調成一樣或是比較小嗎？
https://github.com/cofacts/rumors-line-bot/pulls PR 們有一陣子了 QQ
對我覺得要調小一點 XD
導航列跟文字沒有垂直剛剛好對齊是因為 logo svg viewport 位置問題，可以重出一版上
這段不是很懂><
這段不是很懂><
@stbb1025 @lucien 這個問題再麻煩你們看一下囉
簡單來說現在的 filter 主要是針對 article
在 reply 的搜尋結果頁可能要用針對 reply 的 filter 或是移除
簡單來說現在的 filter 主要是針對 article
在 reply 的搜尋結果頁可能要用針對 reply 的 filter 或是移除
Hmm...
search reply 是照用 Latest reply filter
@lucien
垂直置中
- 👍1
我對一下跟各位說
看起來就只能 「自己回應的」、被認為「含有…」以及時間做 filter 了
- 1
已更新 hackmd
2020-04-24
關於目前這個看起來越來越像生命之樹的 state diagram，目前正在做左邊的互動分支
左下角 `ASKING_REPLY_FEEDBACK` 的行為有點微妙
如果真的照圖上畫的做，會變成 `ASKING_REPLY_FEEDBACK` 與 `__INIT__` 這兩個 state 的 handler 都要處理相同的 LIFF handling 邏輯。
但一件事情不應該要讓兩個 state 都能 handle，這代表 state 劃分有問題
如果真的照圖上畫的做，會變成 `ASKING_REPLY_FEEDBACK` 與 `__INIT__` 這兩個 state 的 handler 都要處理相同的 LIFF handling 邏輯。
但一件事情不應該要讓兩個 state 都能 handle，這代表 state 劃分有問題
我思考了一下有兩個方向：
1. 拿掉 `ASKING_REPLY_FEEDBACK` state，`CHOOSING_REPLY` 顯示 reply 之後就直接回 `__INIT__`，在 `__INIT__` 裡面處理 feedback LIFF 回傳的東西
2. `ASKING_REPLY_FEEDBACK` 處理完 feedback LIFF 的事情之後不要推進到 `__INIT__` ，繼續留在 `ASKING_REPLY_FEEDBACK`，使用者重新選擇 yes/no 之後還可以重複同樣的處理邏輯。
我覺得 2 比較有道理，因為 1 等於是讓 `__INIT__` 越來越肥大，一個 state machine 裡面的 state handler 內部居然還用其他東西去下判斷，就代表那個 “state” 很可能其實是很多 state 組合起來的。
1. 拿掉 `ASKING_REPLY_FEEDBACK` state，`CHOOSING_REPLY` 顯示 reply 之後就直接回 `__INIT__`，在 `__INIT__` 裡面處理 feedback LIFF 回傳的東西
2. `ASKING_REPLY_FEEDBACK` 處理完 feedback LIFF 的事情之後不要推進到 `__INIT__` ，繼續留在 `ASKING_REPLY_FEEDBACK`，使用者重新選擇 yes/no 之後還可以重複同樣的處理邏輯。
我覺得 2 比較有道理，因為 1 等於是讓 `__INIT__` 越來越肥大，一個 state machine 裡面的 state handler 內部居然還用其他東西去下判斷，就代表那個 “state” 很可能其實是很多 state 組合起來的。
不過如果這樣的話，那我覺得其實中路跟右路 (?) 其實也應該做一樣的處理。
例如 `ASKING_REPLY_REQUEST_REASON` state 在接到 source LIFF 的資料之後不要前進到 `__INIT__` ，在自己這個 state 一次處理 source LIFF 與 reason LIFF 的東西
右路 `ASKING_ARTICLE_SUBMISSION_CONSENT` 也應該把 reason LIFF 收回來自己處理
這樣 `__INIT__` 就能回到最單純的，處理新 session （使用者傳新訊息進來）的處理，不需要管 LIFF
例如 `ASKING_REPLY_REQUEST_REASON` state 在接到 source LIFF 的資料之後不要前進到 `__INIT__` ，在自己這個 state 一次處理 source LIFF 與 reason LIFF 的東西
右路 `ASKING_ARTICLE_SUBMISSION_CONSENT` 也應該把 reason LIFF 收回來自己處理
這樣 `__INIT__` 就能回到最單純的，處理新 session （使用者傳新訊息進來）的處理，不需要管 LIFF
而 `ASKING_REPLY_REQUEST_REASON` 與 `ASKING_ARTICLE_SUBMISSION_CONSENT` 的 LIFF 處理回話內容，也可以依照「新送訊息」與「reply request 附議」有所客製化（現在因為都在 `__INIT__` 處理，分不出他是首位回報人，還是送 reply request 的附議者，所以只能回說「Thanks for your info」)
左下角 `ASKING_REPLY_FEEDBACK` 的行為有點微妙
如果真的照圖上畫的做，會變成 `ASKING_REPLY_FEEDBACK` 與 `__INIT__` 這兩個 state 的 handler 都要處理相同的 LIFF handling 邏輯。
但一件事情不應該要讓兩個 state 都能 handle，這代表 state 劃分有問題
如果真的照圖上畫的做，會變成 `ASKING_REPLY_FEEDBACK` 與 `__INIT__` 這兩個 state 的 handler 都要處理相同的 LIFF handling 邏輯。
但一件事情不應該要讓兩個 state 都能 handle，這代表 state 劃分有問題
我思考了一下有兩個方向：
1. 拿掉 `ASKING_REPLY_FEEDBACK` state，`CHOOSING_REPLY` 顯示 reply 之後就直接回 `__INIT__`，在 `__INIT__` 裡面處理 feedback LIFF 回傳的東西
2. `ASKING_REPLY_FEEDBACK` 處理完 feedback LIFF 的事情之後不要推進到 `__INIT__` ，繼續留在 `ASKING_REPLY_FEEDBACK`，使用者重新選擇 yes/no 之後還可以重複同樣的處理邏輯。
我覺得 2 比較有道理，因為 1 等於是讓 `__INIT__` 越來越肥大，一個 state machine 裡面的 state handler 內部居然還用其他東西去下判斷，就代表那個 “state” 很可能其實是很多 state 組合起來的。
1. 拿掉 `ASKING_REPLY_FEEDBACK` state，`CHOOSING_REPLY` 顯示 reply 之後就直接回 `__INIT__`，在 `__INIT__` 裡面處理 feedback LIFF 回傳的東西
2. `ASKING_REPLY_FEEDBACK` 處理完 feedback LIFF 的事情之後不要推進到 `__INIT__` ，繼續留在 `ASKING_REPLY_FEEDBACK`，使用者重新選擇 yes/no 之後還可以重複同樣的處理邏輯。
我覺得 2 比較有道理，因為 1 等於是讓 `__INIT__` 越來越肥大，一個 state machine 裡面的 state handler 內部居然還用其他東西去下判斷，就代表那個 “state” 很可能其實是很多 state 組合起來的。
不過如果這樣的話，那我覺得其實中路跟右路 (?) 其實也應該做一樣的處理。
例如 `ASKING_REPLY_REQUEST_REASON` state 在接到 source LIFF 的資料之後不要前進到 `__INIT__` ，在自己這個 state 一次處理 source LIFF 與 reason LIFF 的東西
右路 `ASKING_ARTICLE_SUBMISSION_CONSENT` 也應該把 reason LIFF 收回來自己處理
這樣 `__INIT__` 就能回到最單純的，處理新 session （使用者傳新訊息進來）的處理，不需要管 LIFF
例如 `ASKING_REPLY_REQUEST_REASON` state 在接到 source LIFF 的資料之後不要前進到 `__INIT__` ，在自己這個 state 一次處理 source LIFF 與 reason LIFF 的東西
右路 `ASKING_ARTICLE_SUBMISSION_CONSENT` 也應該把 reason LIFF 收回來自己處理
這樣 `__INIT__` 就能回到最單純的，處理新 session （使用者傳新訊息進來）的處理，不需要管 LIFF
而 `ASKING_REPLY_REQUEST_REASON` 與 `ASKING_ARTICLE_SUBMISSION_CONSENT` 的 LIFF 處理回話內容，也可以依照「新送訊息」與「reply request 附議」有所客製化（現在因為都在 `__INIT__` 處理，分不出他是首位回報人，還是送 reply request 的附議者，所以只能回說「Thanks for your info」)
When reporting a message with the LINE bot the first time, there will be a pop-up window asking the user to grant permission to "send messages for you". This might confuse users as if the LINE bot is going to send messages to their friends or other chatrooms on their behalf, while it may be just for the LIFF page to send a message back to the very chatroom between the bot and the user. It would be better if something like an explanation about the use of this permission is available to users before they press the "confirm" button. After all, we do want them to think twice before confirming a request as well as sharing a message. <https://user-images.githubusercontent.com/44064051/80186988-790b4780-8641-11ea-8aa5-721316638211.jpg|obscura1587713314272_1>
- 🤖1
*What's covered* <https://user-images.githubusercontent.com/108608/80211453-5cced100-8668-11ea-9ccf-7543ab62bfe2.png|skAdT290hqMGZQAHIK3QRvQ> *What's not covered* LIFF implementation. The flow is tested by manually inputting `prefix` + `option` on LINE, mimicking user interaction in LIFF. *Screenshot*
至此，所有 chatbot state handler 都已經 revamp 成新的版本。在同一個 search session 下，可以支援「改選另一個 article」、「改選另一個 reply」這樣的操作。
再麻煩大家 review PR 了 m(_ _)m
再麻煩大家 review PR 了 m(_ _)m
LINE bot 新流程已經完全實作完畢，也已經上到 staging 了，請大家測測看：
https://lin.ee/1QUzEX4nI
也請賞光一下這些 PR：
https://github.com/cofacts/rumors-line-bot/pulls ，PR 裡面都有使用的錄影或截圖⋯⋯
https://lin.ee/1QUzEX4nI
也請賞光一下這些 PR：
https://github.com/cofacts/rumors-line-bot/pulls ，PR 裡面都有使用的錄影或截圖⋯⋯
你超級棒~~~很厲害=D
1. 可以是空的沒錯
2. 重複一次 share 這件事情可以討論～
2. 重複一次 share 這件事情可以討論～
Replied to a thread: 2020-04-24 20:30:13
至此，所有 chatbot state handler 都已經 revamp 成新的版本。在同一個 search session 下，可以支援「改選另一個 article」、「改選另一個 reply」這樣的操作。
再麻煩大家 review PR 了 m(_ _)m
再麻煩大家 review PR 了 m(_ _)m
- ❤️1
https://www.facebook.com/coscup/photos/a.10150204129832249/10158429767227249
有 Open source chatbot 耶
但我沒啥新梗
有 Open source chatbot 耶
但我沒啥新梗
:woman-bowing:COSCUP 議程徵稿其實 4/20 就開始了:man-bowing: 對不起！Sorry！ごめんなさい！tsin phái-sè！ 給你公開說明書:point_right:<https://bit.ly/2Y0FEwb> 請ㄅ要再敲打我窗QQ － 截止時間：2020/05/11 徵稿題目： ．QMK Keyboarde 鍵人谷 ．Open Source Chatbot ．Let's Read the Source...
2020-04-25
Under some scenario, user's manipulation will have unexpected results. For instance, when the user is asked feedback from 2 replies in one search session, the user may want to give feedback to the former reply, but currently the chatbot always targets the last reply being displayed. The root cause is the context (`selectedArticleId`, `selectedReplyId`) is not preserved when the postback or LIFF is invoked. If we preserve all context in JWT (for LIFF) or postback payload, we will be able to recover the context whenever the LIFF or postback is invoked. To achieve this, the context should store as few data as possible. We should get rid of `data.selectedArticleText` and always read from DB (using `selectedArticleId`) instead. As for `data.searchedText`, the data is required to preserve in context, but we don't need to put it in JWT nor postback payload, since `data.searchedText` never change within one search session. This picks up what is left behind after implementation of <https://github.com/cofacts/rumors-line-bot/issues/49|#49> .
As discussed in slack: > `__INIT__` 越來越肥大，一個 state machine 裡面的 state handler 內部居然還用其他東西去下判斷，就代表那個 “state” 很可能其實是很多 state 組合起來的。 > 例如 `ASKING_REPLY_REQUEST_REASON` state 在接到 source LIFF 的資料之後不要前進到 `__INIT__` ，在自己這個 state 一次處理 source LIFF 與 reason LIFF 的東西 > 右路 `ASKING_ARTICLE_SUBMISSION_CONSENT` 也應該把 reason LIFF 收回來自己處理 > 這樣 `__INIT__` 就能回到最單純的，處理新 session （使用者傳新訊息進來）的處理，不需要管 LIFF > 而 `ASKING_REPLY_REQUEST_REASON` 與 `ASKING_ARTICLE_SUBMISSION_CONSENT` 的 LIFF 處理回話內容，也可以依照「新送訊息」與「reply request 附議」有所客製化（現在因為都在 `__INIT__` 處理，分不出他是首位回報人，還是送 reply request 的附議者，所以只能回說「Thanks for your info」) We should not return user to `__INIT__` state after `ASKING_ARTICLE_SUBMISSION_CONSENT` state and `ASKING_REPLY_REQUEST_REASON` state. By leaving the users there, the LIFF response handling can be off-loaded from `initState` handler (simplifies `initState`), and this allows further customization of LIFF handling in `ASKING_ARTICLE_SUBMISSION_CONSENT` and `ASKING_REPLY_REQUEST_REASON`.
2020-04-26
今年的人機互動研討會 CHI 有 misinfo & fake news 軌
https://programs.sigchi.org/chi/2020/program/session/36353
有一篇訪談微博使用者是否能分辨五毛
有一篇在探討人類在 FB / Twitter 看到訊息後判斷真假的機轉
有一篇在講外行人會不會利用 crowd-source 系統達成自己的政治目的
https://programs.sigchi.org/chi/2020/program/session/36353
有一篇訪談微博使用者是否能分辨五毛
有一篇在探討人類在 FB / Twitter 看到訊息後判斷真假的機轉
有一篇在講外行人會不會利用 crowd-source 系統達成自己的政治目的
與時俱進
這邊有篇好像是博論長度的論文
在講如何用社群網路資料自動偵測五毛
2016 年寫的，2020 釋出
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2738325
在講如何用社群網路資料自動偵測五毛
2016 年寫的，2020 釋出
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2738325
papers.ssrn.com
Astroturfing is the practice of an organization communicating a message using fake “grass-roots” sources. Because these messages attempt to mimic ordinary indiv
This PR: • Adds `src/liff/pages/{Source|Reason|PositiveFeedback|NegativeFeedback}.svelte` page stubs • Implements loading state in `src/liff/index.html` and `src/liff/App.svelte` • Implements `gql` in LIFF that sends authorization header, and `graphql` server that verifies the authorization header • Initializes LIFF and handle the <https://www.facebook.com/groups/linebot/permalink/2380490388948200/?comment_id=2380868955577010|weird redirection mechanism of LIFF v2> • Add LINE user id in LIFF JWT tokens • Removes old context JSON API; replace `issuedAt` with `data.sessionId` in GraphQL context API. *Screenshot* *LIFF button opened previously* If LIFF button is pressed before, pressing it again could be pretty fast: <https://drive.google.com/file/d/1hpv2Z1vjWItUBSmUmV2SXryjbKj5-MVQ/view?usp=sharing|https://drive.google.com/file/d/1hpv2Z1vjWItUBSmUmV2SXryjbKj5-MVQ/view?usp=sharing> The screencast shows: • `App.svelte` routing mechanism works • `gql` in LIFF works with GraphQL context & `@auth` mechanism • Production `Cache-control: max-age` works *Fresh LIFF button* For a new LIFF button, LIFF HTML is fetched from server, which makes the LIFF redirection obvious <https://drive.google.com/file/d/1i0pl1iqHaMVNTJR6cm8_mpf6SHK5A7qw/view?usp=sharing|https://drive.google.com/file/d/1i0pl1iqHaMVNTJR6cm8_mpf6SHK5A7qw/view?usp=sharing> The screencast shows: • 'loading' state works • LIFF redirection handling works (Green loading bar appears twice)
2020-04-27
Implements the LIFF asking user about message source. *Screenshots* <https://user-images.githubusercontent.com/108608/80314605-1377b080-8825-11ea-8eb6-8611170e4f64.png|image> *Pressing invalid sources* <https://drive.google.com/open?id=1i3gOOxN6bAfl0AeOsEAI2zvIO0-az55t|https://drive.google.com/open?id=1i3gOOxN6bAfl0AeOsEAI2zvIO0-az55t> • Closes LIFF • Sends message to chatbot *Pressing valid sources* <https://drive.google.com/open?id=1i5TJXLMRYInPHxePP18aE2-vZFmUADOZ|https://drive.google.com/open?id=1i5TJXLMRYInPHxePP18aE2-vZFmUADOZ> • Page switch to reason LIFF • Sends message to chatbot; article submitted to database, and source recorded under the hood
Implements <https://github.com/cofacts/rumors-line-bot/blob/dev/liff/index.html#L82-L151|previous LIFF reason logic> using svelte. *Screenshots* *confirms when length is not sufficient* *blocks reasons that is totally identical to searched text* *confirm button changes color once length reached threshold*
今天又是了一下發現 `CreateOrUpdateArticleReplyFeedback` 應該確實是沒有更新 user name
後端那邊我看是用 upsert userId 的方式產生一個 articleReplyFeedback
不太確定 elasticsearch 的 upsert 是怎麼實作的 @@
後端那邊我看是用 upsert userId 的方式產生一個 articleReplyFeedback
不太確定 elasticsearch 的 upsert 是怎麼實作的 @@
看起來那一個 `articleReplyFeedback` 的作者，app ID 不是 `website` 而是 localhost 開發專用的 `DEVELOPMENT_FRONTEND`
我記得我哪裏好像有寫，要 match 人的時候一定要 user id 與 app id 都 match @@
我記得我哪裏好像有寫，要 match 人的時候一定要 user id 與 app id 都 match @@
所以這是只有 develop 才會發生的問題囉？
似乎是登入 localhost rumors-api 後做 insert 操作，才會有的問題
- 👌1
合理
因為那是我自己登入新增的 feedback
以前的 feedback 都沒 comment
因為那是我自己登入新增的 feedback
以前的 feedback 都沒 comment
de 這 bug de 好久 _(┐「ε:)_
但 localhost 的 rumors-api 接的好像是 localhost 的 DB，不是 staging?
不太確定你的意思
我是在 local 自己申請 fb develop app 登入然後新增 feedback 的
我是在 local 自己申請 fb develop app 登入然後新增 feedback 的
i see 所以是 localhost 的 rumors-api 與 elasticsearch DB
如果 staging API 有你要的東西
那看要不要把 localhost rumors-site 的 .env 裡的 API URL 指向到 staging ( https://cofacts-api.hacktabl.org/graphql )
理論上這樣 appId 就會跟其他 staging 上的資料一致，比較拉得到 user
機器上也可以不用開 elasticsearch DB 與 rumors-api，比較省資源
那看要不要把 localhost rumors-site 的 .env 裡的 API URL 指向到 staging ( https://cofacts-api.hacktabl.org/graphql )
理論上這樣 appId 就會跟其他 staging 上的資料一致，比較拉得到 user
機器上也可以不用開 elasticsearch DB 與 rumors-api，比較省資源
- 👍1
合理
我開著一堆 container 筆電一直在哀嚎 XD
我開著一堆 container 筆電一直在哀嚎 XD
openpeeps.com
Open Peeps is a hand-drawn illustration library to create scenes of people. You can use them in product illustration, marketing, comics, product states, user flows, personas, storyboarding, quinceañera invitations, or whatever you want! ⠀
- 1
HackMD
Cofacts Next Spec ===== 全站導航 --- - [列表](/iJm9_nZaTA2GyInn7ycxoA) 各頁細節 --- - [可疑訊息](/ahtI6xsFR
@fysidm has joined the channel
2020-04-28
LIFF implementation for positive (new) and negative (<https://github.com/cofacts/rumors-line-bot/blob/dev/liff/index.html#L93-L96|existing>) feedback for a reply. It is now testable on staging - <https://lin.ee/1QUzEX4nI|https://lin.ee/1QUzEX4nI> *Screenshot* *Add positive feedback and then add negative feedback* <https://drive.google.com/open?id=1jAikpF8K1AgTK9INy3J9HhmJmUL1rHR|https://drive.google.com/open?id=1jAikpF8K1AgTK9INy3J9HhmJmUL1rHR>_ *Not providing feedback still counts*
Replied to a thread: 2020-04-24 20:30:13
LINE bot 新流程已經完全實作完畢，也已經上到 staging 了，請大家測測看：
https://lin.ee/1QUzEX4nI
也請賞光一下這些 PR：
https://github.com/cofacts/rumors-line-bot/pulls ，PR 裡面都有使用的錄影或截圖⋯⋯
https://lin.ee/1QUzEX4nI
也請賞光一下這些 PR：
https://github.com/cofacts/rumors-line-bot/pulls ，PR 裡面都有使用的錄影或截圖⋯⋯
密碼露出啦
請換一下 orz
請換一下 orz
```const FIXED_DATE = 612921600000;```
懂測
懂測
@ggm 我想問一下列出某使用者所有 `userArticleLink` ，以及找出某使用者的 `userSettings` 這兩個 read query 會要收進 model 裡，還是非 mutation 操作就直接呼叫 `client.findAll` ？
haha 眼尖耶！那個是 test 的沒事沒事，我來拿掉
有 `UserSettings.findByUserId` 呀
看起來單一個 find （其實是 `findOrInsert`）沒問題惹
不過關於 `userArticleLink` 確實是要做個列表的，這部分要收進 model，還是要呼叫的人自己呼叫 `await (await UserArticleLink.client).findAll({userId: xxx})` ?
不過關於 `userArticleLink` 確實是要做個列表的，這部分要收進 model，還是要呼叫的人自己呼叫 `await (await UserArticleLink.client).findAll({userId: xxx})` ?
列出某使用者所有 `userArticleLink` 這個是漏了
travis-ci.org
Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.
這個 test 看起來都過呀 為什麼是 `#707 errored` 呀？
有東西開著沒有 close，所以 process 沒有結束，然後 10 分鐘沒輸出被 CI 砍了
1- 👍1
噢看到了最下面有寫 眼殘
密碼露出啦
請換一下 orz
請換一下 orz
```const FIXED_DATE = 612921600000;```
懂測
懂測
@ggm 我想問一下列出某使用者所有 `userArticleLink` ，以及找出某使用者的 `userSettings` 這兩個 read query 會要收進 model 裡，還是非 mutation 操作就直接呼叫 `client.findAll` ？
haha 眼尖耶！那個是 test 的沒事沒事，我來拿掉
有 `UserSettings.findByUserId` 呀
看起來單一個 find （其實是 `findOrInsert`）沒問題惹
不過關於 `userArticleLink` 確實是要做個列表的，這部分要收進 model，還是要呼叫的人自己呼叫 `await (await UserArticleLink.client).findAll({userId: xxx})` ?
不過關於 `userArticleLink` 確實是要做個列表的，這部分要收進 model，還是要呼叫的人自己呼叫 `await (await UserArticleLink.client).findAll({userId: xxx})` ?
列出某使用者所有 `userArticleLink` 這個是漏了
- 1
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=889%3A306
想問一下 `相似可疑訊息` 的邏輯
是套用 moreLikeThis filter 還是用 category 之類的？
想問一下 `相似可疑訊息` 的邏輯
是套用 moreLikeThis filter 還是用 category 之類的？
Article type 底下有個 relatedArticles 可以用
staging 上有"有相似訊息"的訊息可以測嗎？
https://cofacts.hacktabl.org/article/1fi7dla9wtwjn
```{
GetArticle(id: "1fi7dla9wtwjn") {
relatedArticles {
edges {
node {
id
text
}
}
}
}
}```
```{
GetArticle(id: "1fi7dla9wtwjn") {
relatedArticles {
edges {
node {
id
text
}
}
}
}
}```
Article type 底下有個 relatedArticles 可以用
- 👍1
@lucien @mrorz @yanglin5689446
Also @bil
Landing page 的初版文字架構，圖像跟編排還沒出來～會等文字架構大概定案再著手
我是先用比較輕鬆的口吻來介紹，希望能更吸引閱讀，大家看有什麼想法都歡迎提出唷 @bil @lucien @mrorz @yanglin5689446
覺得很勵志ＸＤ
「要怎麼判斷真假」會有 call to action 嗎？還是要擺個網路文章如 https://m.facebook.com/taiwantfc/photos/a.234834500505015/550796898908772/?type=3
我可能會在“人人都是判斷者“這裡明示：
我們不相信權威，也沒有資格告訴你「只有______說的才是對的。」Who would check fact-checkers?Everybody would check fact-checkers.
我們不相信權威，也沒有資格告訴你「只有______說的才是對的。」Who would check fact-checkers?Everybody would check fact-checkers.
Call to action 或外部連結我覺得要看必要性～最好的情況是用最精簡的方式讓使用者在同一頁就吸收完畢
盡量不要讓使用者還沒看完就中途跳出去😂
「質疑，才是自由的開始」這是我昨天在思考的slogan
我之前去演講時常被觀眾問「有多個回應的話，所以我要相信誰」
我都回答「相信自己」XD
判斷依據是，他選用的出處、他寫的文字有沒有「說服你」。這其實也呼應 Lucien 說的，是帶著質疑去看每一個回應，才會有後續「說服」的過程。
我都回答「相信自己」XD
判斷依據是，他選用的出處、他寫的文字有沒有「說服你」。這其實也呼應 Lucien 說的，是帶著質疑去看每一個回應，才會有後續「說服」的過程。
我覺得這段文字很美XD
但感覺你們說的東西有點偏精神層次
對於第一次造訪的使用者我覺得會有點深耶
但感覺你們說的東西有點偏精神層次
對於第一次造訪的使用者我覺得會有點深耶
蠻適合當平台的slogan哈哈
品牌slogan
Also @bil
Landing page 的初版文字架構，圖像跟編排還沒出來～會等文字架構大概定案再著手
我是先用比較輕鬆的口吻來介紹，希望能更吸引閱讀，大家看有什麼想法都歡迎提出唷 @bil @lucien @mrorz @yanglin5689446
staging 上有"有相似訊息"的訊息可以測嗎？
覺得很勵志ＸＤ
- ❤️3
「要怎麼判斷真假」會有 call to action 嗎？還是要擺個網路文章如 https://m.facebook.com/taiwantfc/photos/a.234834500505015/550796898908772/?type=3
【防疫特別企劃:bookmark_tabs:】告訴你所有親朋好友，看到可疑訊息「不分享，以防萬一」！ COVID-19全球疫情大流行的同時，「#假訊息大流行」也正在發生！該如何判斷您所接受到的訊息可能不是正確的呢？ :white_check_mark:查核中心替大家整理疑似不實訊息的特徵： :round_pushpin:一、吃某種特定食物或用某種方式可以治療某種疾病 :round_pushpin:二、突然要你趕快去囤貨、領錢、加油...
我可能會在“人人都是判斷者“這裡明示：
我們不相信權威，也沒有資格告訴你「只有______說的才是對的。」Who would check fact-checkers?Everybody would check fact-checkers.
我們不相信權威，也沒有資格告訴你「只有______說的才是對的。」Who would check fact-checkers?Everybody would check fact-checkers.
- 2
- 👍1
https://cofacts.hacktabl.org/article/1fi7dla9wtwjn
```{
GetArticle(id: "1fi7dla9wtwjn") {
relatedArticles {
edges {
node {
id
text
}
}
}
}
}```
```{
GetArticle(id: "1fi7dla9wtwjn") {
relatedArticles {
edges {
node {
id
text
}
}
}
}
}```
- 👌1
Call to action 或外部連結我覺得要看必要性～最好的情況是用最精簡的方式讓使用者在同一頁就吸收完畢
- 👍1
盡量不要讓使用者還沒看完就中途跳出去😂
「質疑，才是自由的開始」這是我昨天在思考的slogan
- 😲1
我之前去演講時常被觀眾問「有多個回應的話，所以我要相信誰」
我都回答「相信自己」XD
判斷依據是，他選用的出處、他寫的文字有沒有「說服你」。這其實也呼應 Lucien 說的，是帶著質疑去看每一個回應，才會有後續「說服」的過程。
我都回答「相信自己」XD
判斷依據是，他選用的出處、他寫的文字有沒有「說服你」。這其實也呼應 Lucien 說的，是帶著質疑去看每一個回應，才會有後續「說服」的過程。
你超級棒~~~很厲害=D
我覺得這段文字很美XD
但感覺你們說的東西有點偏精神層次
對於第一次造訪的使用者我覺得會有點深耶
但感覺你們說的東西有點偏精神層次
對於第一次造訪的使用者我覺得會有點深耶
蠻適合當平台的slogan哈哈
品牌slogan
2020-04-29
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=889%3A306
目前的 article details 設計中
replyRequest 是會顯示 user 的名字的
但現在的後端設計中 replyRequest 似乎只有 userId ?
目前的 article details 設計中
replyRequest 是會顯示 user 的名字的
但現在的後端設計中 replyRequest 似乎只有 userId ?
LINE 使用者的部分不會有 user 名字，而是會用 userId 生成的假名與頭像替代
https://g0v.hackmd.io/@NFi0czulSemxCM8RNSlz8Q/HJ8xT3QVU/%2F7ERem43XREWJPOjjdE28SQ
https://g0v.hackmd.io/@NFi0czulSemxCM8RNSlz8Q/HJ8xT3QVU/%2F7ERem43XREWJPOjjdE28SQ
cc/ @lucien
Detail spec有寫這一段的討論，需要實作一個我們的假名產生器
雖然假名目前還沒有定論到底要用啥生成
1. 可以是空的沒錯
2. 重複一次 share 這件事情可以討論～
2. 重複一次 share 這件事情可以討論～
LINE 使用者的部分不會有 user 名字，而是會用 userId 生成的假名與頭像替代
https://g0v.hackmd.io/@NFi0czulSemxCM8RNSlz8Q/HJ8xT3QVU/%2F7ERem43XREWJPOjjdE28SQ
https://g0v.hackmd.io/@NFi0czulSemxCM8RNSlz8Q/HJ8xT3QVU/%2F7ERem43XREWJPOjjdE28SQ
Cofacts Next Spec ===== 全站導航 --- - [列表](/iJm9_nZaTA2GyInn7ycxoA) 各頁細節 --- - [可疑訊息](/ahtI6xsFR
Johnson Liang
LINE user 呈現在網站上的頭像與假名生成
https://g0v.hackmd.io/7ERem43XREWJPOjjdE28SQ
cc/ @lucien
Detail spec有寫這一段的討論，需要實作一個我們的假名產生器
- 👌1
雖然假名目前還沒有定論到底要用啥生成
問個
新增回應的部分要用套件的編輯器嗎？
還是簡單用就好?
因為我之前用 draft 之類套件編輯器的經驗是有很多小 bug 需要處理
而且不確定這個編輯器功能要多複雜
新增回應的部分要用套件的編輯器嗎？
還是簡單用就好?
因為我之前用 draft 之類套件編輯器的經驗是有很多小 bug 需要處理
而且不確定這個編輯器功能要多複雜
我們這裡是純文字編輯唷，沒有所見即所得
畢竟 LINE 也只吃純文字
不過我覺得「ordered list」、「unordered list」按鈕的互動行為需要討論 @lucien
1. 如果編輯沒有框文字，按下ordered list / unordered list 按鈕，要幫他斷行然後加 `-` 在前面嗎
2. 如果使用者在 `1. XXXXXX` 後面斷行，要幫他加 `2.` 嗎？
3. 如果編輯框起數個段落後按下 ordered list / unordered list 按鈕，是要幫每個段落前面加 1, 2, 3 嗎？
畢竟 LINE 也只吃純文字
不過我覺得「ordered list」、「unordered list」按鈕的互動行為需要討論 @lucien
1. 如果編輯沒有框文字，按下ordered list / unordered list 按鈕，要幫他斷行然後加 `-` 在前面嗎
2. 如果使用者在 `1. XXXXXX` 後面斷行，要幫他加 `2.` 嗎？
3. 如果編輯框起數個段落後按下 ordered list / unordered list 按鈕，是要幫每個段落前面加 1, 2, 3 嗎？
就是這些微互動會需要定義
好
然後上述這些互動好像也有這個可以用
https://github.com/sparksuite/simplemde-markdown-editor
但正如 @yanglin5689446 說的，可能會有 bug 要處理，另外裡頭的粗體斜體標題等東西還要拔掉。
https://github.com/sparksuite/simplemde-markdown-editor
但正如 @yanglin5689446 說的，可能會有 bug 要處理，另外裡頭的粗體斜體標題等東西還要拔掉。
關於 emoji picker 我們之前是不是有找一發呀
有一個 slack like
unorder list 是想加 •
我一直很好奇
是不是有些手機沒辦法看到某些 emoji
我們是不是要引導編輯只能用某些 emoji subset
是不是有些手機沒辦法看到某些 emoji
我們是不是要引導編輯只能用某些 emoji subset
我們應該可以只選用特定 emoji subset picker
但要不要在輸入匡跳警告要想想
有些真的不支援呢
skin tone 的部分應該可以藏起來
因為舊手機應該是確定會壞掉
因為舊手機應該是確定會壞掉
可以先從選 set 開始
set 我覺得都可以用耶
是每個 set 都有一部分太新不能用
是每個 set 都有一部分太新不能用
因為不透過我們 picker 大概會有兩種情境而已
1. 電腦的 power user 會使用 os /輸入法 picker
2. 手機編輯
1. 電腦的 power user 會使用 os /輸入法 picker
2. 手機編輯
更正是指 emoji version
喔喔那就對
可以用 browserstack 測
下面這是 iPhone 7 / iOS 10
下面這是 iPhone 7 / iOS 10
我們不是真的編輯器
也不是真markdown
Editor上面都是快速輸入功能
我們這裡是純文字編輯唷，沒有所見即所得
畢竟 LINE 也只吃純文字
不過我覺得「ordered list」、「unordered list」按鈕的互動行為需要討論 @lucien
1. 如果編輯沒有框文字，按下ordered list / unordered list 按鈕，要幫他斷行然後加 `-` 在前面嗎
2. 如果使用者在 `1. XXXXXX` 後面斷行，要幫他加 `2.` 嗎？
3. 如果編輯框起數個段落後按下 ordered list / unordered list 按鈕，是要幫每個段落前面加 1, 2, 3 嗎？
畢竟 LINE 也只吃純文字
不過我覺得「ordered list」、「unordered list」按鈕的互動行為需要討論 @lucien
1. 如果編輯沒有框文字，按下ordered list / unordered list 按鈕，要幫他斷行然後加 `-` 在前面嗎
2. 如果使用者在 `1. XXXXXX` 後面斷行，要幫他加 `2.` 嗎？
3. 如果編輯框起數個段落後按下 ordered list / unordered list 按鈕，是要幫每個段落前面加 1, 2, 3 嗎？
所以理想上應該是自己重刻
就是這些微互動會需要定義
好
然後上述這些互動好像也有這個可以用
https://github.com/sparksuite/simplemde-markdown-editor
但正如 @yanglin5689446 說的，可能會有 bug 要處理，另外裡頭的粗體斜體標題等東西還要拔掉。
https://github.com/sparksuite/simplemde-markdown-editor
但正如 @yanglin5689446 說的，可能會有 bug 要處理，另外裡頭的粗體斜體標題等東西還要拔掉。
A simple, beautiful, and embeddable JavaScript Markdown editor. Delightful editing for beginners and experts alike. Features built-in autosaving and spell checking.
關於 emoji picker 我們之前是不是有找一發呀
有一個 slack like
1
unorder list 是想加 •
我一直很好奇
是不是有些手機沒辦法看到某些 emoji
我們是不是要引導編輯只能用某些 emoji subset
是不是有些手機沒辦法看到某些 emoji
我們是不是要引導編輯只能用某些 emoji subset
我們應該可以只選用特定 emoji subset picker
但要不要在輸入匡跳警告要想想
有些真的不支援呢
skin tone 的部分應該可以藏起來
因為舊手機應該是確定會壞掉
因為舊手機應該是確定會壞掉
可以先從選 set 開始
set 我覺得都可以用耶
是每個 set 都有一部分太新不能用
是每個 set 都有一部分太新不能用
因為不透過我們 picker 大概會有兩種情境而已
1. 電腦的 power user 會使用 os /輸入法 picker
2. 手機編輯
1. 電腦的 power user 會使用 os /輸入法 picker
2. 手機編輯
更正是指 emoji version
喔喔那就對
可以用 browserstack 測
下面這是 iPhone 7 / iOS 10
下面這是 iPhone 7 / iOS 10
2020-04-30
我想問一下
`ListReplyRequests` 的目的是為了列出熱門求回應的訊息嗎？
如果是的話 `ReplyRequest` model 是不是需要關聯到 `Article`
`ListReplyRequests` 的目的是為了列出熱門求回應的訊息嗎？
如果是的話 `ReplyRequest` model 是不是需要關聯到 `Article`
是的
啊不過那個 `ListReplyRequests` 背後要做的 「我的關注」好像被 defer 了，似乎是變成 profile page 的一部份的樣子 ._.
https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg 這裏空空如也
啊不過那個 `ListReplyRequests` 背後要做的 「我的關注」好像被 defer 了，似乎是變成 profile page 的一部份的樣子 ._.
https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg 這裏空空如也
現在是沒有
如果要從 article 關聯的話
其實可以從 ListArticles 關聯然後列出來
但是這樣就沒辦法拿到最新的 ReplyRequest 了
如果要從 article 關聯的話
其實可以從 ListArticles 關聯然後列出來
但是這樣就沒辦法拿到最新的 ReplyRequest 了
`ListArticles` 沒辦法列出「我關注的 article」，因為 elasticsearch 沒有 join，而個別 reply request 與 article 是存放在不同 index，而非 article 下的 nested object
這也是為何當時規劃需要 `ListReplyRequest` 然後再在 application side (GraphQL API resolver) 去 associate article，因為那是唯一可以列出「我有關注的訊息」的方式
（「我有關注」作為 `ListReplyRequest` 的一種 filter ）
（「我有關注」作為 `ListReplyRequest` 的一種 filter ）
嗯嗯
不過現在沒 spec 的話，好像確實只能暫緩 @@
可能請 @lucien 講一下規劃
印象中是搬去 profile page
印象中是搬去 profile page
你們現在是講哪一個需求呀
「我的關注」https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg
要列出該使用者的所有 replyrequest
要列出該使用者的所有 replyrequest
是的
啊不過那個 `ListReplyRequests` 背後要做的 「我的關注」好像被 defer 了，似乎是變成 profile page 的一部份的樣子 ._.
https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg 這裏空空如也
啊不過那個 `ListReplyRequests` 背後要做的 「我的關注」好像被 defer 了，似乎是變成 profile page 的一部份的樣子 ._.
https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg 這裏空空如也
- 😮1
`ListArticles` 沒辦法列出「我關注的 article」，因為 elasticsearch 沒有 join，而個別 reply request 與 article 是存放在不同 index，而非 article 下的 nested object
這也是為何當時規劃需要 `ListReplyRequest` 然後再在 application side (GraphQL API resolver) 去 associate article，因為那是唯一可以列出「我有關注的訊息」的方式
（「我有關注」作為 `ListReplyRequest` 的一種 filter ）
（「我有關注」作為 `ListReplyRequest` 的一種 filter ）
嗯嗯
不過現在沒 spec 的話，好像確實只能暫緩 @@
可能請 @lucien 講一下規劃
印象中是搬去 profile page
印象中是搬去 profile page
你們現在是講哪一個需求呀
「我的關注」https://g0v.hackmd.io/bDabiOi3SyCKyRZ2g0eILg
要列出該使用者的所有 replyrequest
要列出該使用者的所有 replyrequest
merge TextExpansion & old ExpandableText components should merge <https://github.com/cofacts/rumors-site/pull/247|247> first
@stbb1025 @lucien @mrorz 之前本來有做兩行斷行的可收合文字介面 `TextExpansion`
不過發現原本的 `ExpandableText` 實作比較簡單而且泛用性更高
所以把它改回來了
不過就變成原本用字數來算的方式而不是用行數
因為中文字的寬度跟英文不一樣
用算行數的方式滿麻煩的(要先計算 container 的寬度、算有幾個中文字做調整才有辦法精準)
https://github.com/cofacts/rumors-site/pull/248
不過發現原本的 `ExpandableText` 實作比較簡單而且泛用性更高
所以把它改回來了
不過就變成原本用字數來算的方式而不是用行數
因為中文字的寬度跟英文不一樣
用算行數的方式滿麻煩的(要先計算 container 的寬度、算有幾個中文字做調整才有辦法精準)
https://github.com/cofacts/rumors-site/pull/248
merge TextExpansion & old ExpandableText components should merge <https://github.com/cofacts/rumors-site/pull/247|247> first
TextExpansion 有什麼效能上或是 bug 的考量嗎？
功能上比較不泛用(不容易 reuse)
瀏覽器支援比較差
而且之前實驗看起來算行數也不準(因為中文字的寬度...)
瀏覽器支援比較差
而且之前實驗看起來算行數也不準(因為中文字的寬度...)
如果是把內容複製一份到一樣寬的、藏起來的 div
然後計算高度不設限的 div，與高度有上限的 div 的高度
如果不設限的 div 較高，就代表有 truncation 發生，應該顯示 Show / hide button
這樣呢？
Ex: https://jsbin.com/cadalezobi/4/edit?html,css,js,console,output
然後計算高度不設限的 div，與高度有上限的 div 的高度
如果不設限的 div 較高，就代表有 truncation 發生，應該顯示 Show / hide button
這樣呢？
Ex: https://jsbin.com/cadalezobi/4/edit?html,css,js,console,output
其中的 max-height 可以用 `-webkit-line-clamp` 取代。
注意：即使是 firefox，也要用 `-webkit-line-clamp`
https://caniuse.com/#feat=css-line-clamp
注意：即使是 firefox，也要用 `-webkit-line-clamp`
https://caniuse.com/#feat=css-line-clamp
原本實作是用 line-clamp 沒錯
嗯嗯
不過癥結點不在 ellipsis
而是在「到底該不該顯示『show more』按鈕」的判斷～
不過癥結點不在 ellipsis
而是在「到底該不該顯示『show more』按鈕」的判斷～
這方法好像不錯
不過如果多一個 compare 會不會有 fouc 問題啊
還有 SSR 的時候應該會變兩倍流量之類的？
不過如果多一個 compare 會不會有 fouc 問題啊
還有 SSR 的時候應該會變兩倍流量之類的？
我是可以試試看
你說的沒錯，他會讓 HTML 變大，「JS 取高度」的時機也是問題
不過因為有 max-height 或 line-clamp，他的高度最多就是 N 行，會 FOUC 的只有「顯示更多」按鈕本人而已
不過因為有 max-height 或 line-clamp，他的高度最多就是 N 行，會 FOUC 的只有「顯示更多」按鈕本人而已
HTML bloat 的部分，可以做成說這個 component 要在瀏覽器上 / componentDidMount 之後才去 populate 用於計算的 div 的內容
這樣就是在瀏覽器上 js 跑起來時才會計算，而 SSR 吐出來的時候 component 會一直以為「高度沒超過 N 行」（計算用 div 高度 = 0，或根本沒觸發計算）所以不會顯示「顯示更多」按鈕
這樣就是在瀏覽器上 js 跑起來時才會計算，而 SSR 吐出來的時候 component 會一直以為「高度沒超過 N 行」（計算用 div 高度 = 0，或根本沒觸發計算）所以不會顯示「顯示更多」按鈕
FOUC 的部分就是，會在瀏覽器上才會跑出「顯示更多」
如果沒有推移到什麼其他東西、或者是推移到文字的話，我覺得應該還好～
如果沒有推移到什麼其他東西、或者是推移到文字的話，我覺得應該還好～
https://github.com/cofacts/rumors-site/pull/248/files
@yanglin5689446 是說這個是不是還沒 ready 呀
我看用到 `ExpandableText` 的地方傳了 `lineClamp` 進去，但 `ExpandableText` 內部並沒有處理它
@yanglin5689446 是說這個是不是還沒 ready 呀
我看用到 `ExpandableText` 的地方傳了 `lineClamp` 進去，但 `ExpandableText` 內部並沒有處理它
@mrorz 我昨天又重新用上面討論的方式實作了
之前那個算是丟上來討論而已
之前那個算是丟上來討論而已
再麻煩你幫我 review 了🙏
功能上比較不泛用(不容易 reuse)
瀏覽器支援比較差
而且之前實驗看起來算行數也不準(因為中文字的寬度...)
瀏覽器支援比較差
而且之前實驗看起來算行數也不準(因為中文字的寬度...)
如果是把內容複製一份到一樣寬的、藏起來的 div
然後計算高度不設限的 div，與高度有上限的 div 的高度
如果不設限的 div 較高，就代表有 truncation 發生，應該顯示 Show / hide button
這樣呢？
Ex: https://jsbin.com/cadalezobi/4/edit?html,css,js,console,output
然後計算高度不設限的 div，與高度有上限的 div 的高度
如果不設限的 div 較高，就代表有 truncation 發生，應該顯示 Show / hide button
這樣呢？
Ex: https://jsbin.com/cadalezobi/4/edit?html,css,js,console,output
jsbin.com
A live pastebin for HTML, CSS & JavaScript and a range of processors, including SCSS, CoffeeScript, Jade and more...
- 👍1
其中的 max-height 可以用 `-webkit-line-clamp` 取代。
注意：即使是 firefox，也要用 `-webkit-line-clamp`
https://caniuse.com/#feat=css-line-clamp
注意：即使是 firefox，也要用 `-webkit-line-clamp`
https://caniuse.com/#feat=css-line-clamp
原本實作是用 line-clamp 沒錯
嗯嗯
不過癥結點不在 ellipsis
而是在「到底該不該顯示『show more』按鈕」的判斷～
不過癥結點不在 ellipsis
而是在「到底該不該顯示『show more』按鈕」的判斷～
這方法好像不錯
不過如果多一個 compare 會不會有 fouc 問題啊
還有 SSR 的時候應該會變兩倍流量之類的？
不過如果多一個 compare 會不會有 fouc 問題啊
還有 SSR 的時候應該會變兩倍流量之類的？
我是可以試試看
你說的沒錯，他會讓 HTML 變大，「JS 取高度」的時機也是問題
不過因為有 max-height 或 line-clamp，他的高度最多就是 N 行，會 FOUC 的只有「顯示更多」按鈕本人而已
不過因為有 max-height 或 line-clamp，他的高度最多就是 N 行，會 FOUC 的只有「顯示更多」按鈕本人而已
- 👍1
HTML bloat 的部分，可以做成說這個 component 要在瀏覽器上 / componentDidMount 之後才去 populate 用於計算的 div 的內容
這樣就是在瀏覽器上 js 跑起來時才會計算，而 SSR 吐出來的時候 component 會一直以為「高度沒超過 N 行」（計算用 div 高度 = 0，或根本沒觸發計算）所以不會顯示「顯示更多」按鈕
這樣就是在瀏覽器上 js 跑起來時才會計算，而 SSR 吐出來的時候 component 會一直以為「高度沒超過 N 行」（計算用 div 高度 = 0，或根本沒觸發計算）所以不會顯示「顯示更多」按鈕
FOUC 的部分就是，會在瀏覽器上才會跑出「顯示更多」
如果沒有推移到什麼其他東西、或者是推移到文字的話，我覺得應該還好～
如果沒有推移到什麼其他東西、或者是推移到文字的話，我覺得應該還好～
- 👍2
是說禮拜三提到的那個 LIFF bubble 有兩個、以及兩次有點重複這件事情
我看了一下泰國開發者的各種花式 LIFF http://www.evanlin.com/th-lae-flextemplate
給了我靈感：連續兩個 bubble 好像用 carousel 會不會比較好？也就是 share to FB / LINE 的那個 bubble 收到右邊去？
我看了一下泰國開發者的各種花式 LIFF http://www.evanlin.com/th-lae-flextemplate
給了我靈感：連續兩個 bubble 好像用 carousel 會不會比較好？也就是 share to FB / LINE 的那個 bubble 收到右邊去？
- 1
好猛
或是提供理由 / 看文章的那個 bubble 收到右邊去之類