12 posts tagged with "mobile"

import Mindmap from '@theme/Mindmap'

<Mindmap markdown={`

自動化工具​

手機​

• Google Home

網路服務​

• Dropbox
• IFTTT

自架​

• Github Actions
• NAS `} />

2017 年開始紀錄自己使用的自動化紀錄工具。今年的自動化程度其實退步了不少，主要是一些以前依賴的第三方服務如 Anobii (不維護) 或豆瓣 (要實名認證) 都紛紛出現了問題。用一年下來，Joplin 確實解決了我隨時筆記與累積的問題。

為什麼要做個人自動化紀錄？​

有人會問，Facebook/Twitter 不就可以記錄大小事了嗎？如果會這麼回答，那就實在太天真了😏。FB 上也許包含了自己覺得值得分享的事，但生活中還有諸多事情值得記錄，而不適合與大眾分享。

或是想整理過去公開紀錄，造訪過去使用過的社交平台（Plurk, Google+, Blogger）已非常難以找出過去的隨筆或評論。

擁有自己的一份完整數位化生活記錄，是我持續的個人目標之一。要達成這個目標，需要藉助一些自動化紀錄工具，好讓整個過程變得自然而不困難。

2017 年開始紀錄自己使用的自動化紀錄工具。

為什麼要做個人自動化紀錄？​

有人會問，Facebook/Twitter 不就可以記錄大小事了嗎？如果會這麼回答，那就實在太天真了😏。FB 上也許包含了自己覺得值得分享的事，但生活中還有諸多事情值得記錄，而不適合與大眾分享。

或是想整理過去公開紀錄，造訪過去使用過的社交平台（Plurk, Google+, Blogger）已非常難以找出過去的隨筆或評論。

擁有自己的一份完整數位化生活記錄，是我持續的個人目標之一。要達成這個目標，需要藉助一些自動化紀錄工具，好讓整個過程變得自然而不困難。

2017 年開始紀錄自己使用的自動化紀錄工具，今年更新。

為什麼要做個人自動化紀錄？​

有人會問，Facebook/Twitter 不就可以記錄大小事了嗎？如果會這麼回答，那就實在太天真了😏。FB 上也許包含了自己覺得值得分享的事，但生活中還有諸多事情值得記錄，而不適合與大眾分享。 擁有自己的一份完整數位化生活記錄，是我持續的個人目標之一。要達成這個目標，需要藉助一些自動化紀錄工具，好讓整個過程變得自然而不困難。

照片自動化備份 📷​

• 360CAM 所拍的相片一律備份到手機
• Dropbox, 自動從手機上傳照片
• Google 相簿，充電時自動從手機備份照片到 Google 雲端
• NAS (Synnalogy), 透過Cloud Sync從 Dropbox 同步照片。

運動自動化紀錄 :walking:​

• 記步，睡眠紀錄：小米手環 2
• 體重：小米體重計

現已不再帶小米手環 2，覺得記錄睡眠與步數，並無法改善健康狀況，意義不大。 同時為了降低多走路所需要的意志力，把每日步數改成更容易達成的 300 步，只要開始走，通常都會超過需要的步數。

Update: 四月開始為了減重需要，又再戴起小米手環 2。並將體重計換成體脂計。因應生活型態的改變，行走目標也改為每天 4000 步。

生活事件自動化紀錄​

延續用 IFTTT 做自動生活紀錄這篇的思路，我把看過的書籍、電影，喜歡的 Youtube 影片，貼過的文章，每日完成的事項都記錄到 Google 日曆中，以方便之後回顧。

自動閱讀 / 觀看紀錄 📚​

對於書籍與電影，我使用 RSS + IFTTT + Google Calendar 來自動紀錄。 當我在豆瓣上修改狀態，豆瓣的 RSS 也跟著改變，這時 IFTTT 會將 RSS 中的新事項紀錄到 Google 日曆上。 對於 Youtube 上 like 的影片，Facebook 或 Twitter 上新貼的文章，也會透過 IFTTT 紀錄到 Google 日曆上。

透過 RSS 轉 IFTTT 紀錄

直接透過 IFTTT 紀錄

自動紀錄每日完成的事項 📓​

這部份是自動紀錄的核心。使用 Todoist + IFTTT + Google Calendar 即可達成。 我在 Google Calendar 上使用一個單獨的日曆 (成功日記) 來紀錄每日完成的事項。

If task completed in Todoist, Then log into Google Calendar

從 Email 新增待辦事項 ✉️​

為了更方便地蒐集待辦事項，我參考這份影片 https://youtu.be/V7Dk7pzjJmM?t=11m30s 來將 Todoist#Inbox 設定為 Email 聯絡人，這樣處理 Email 的過程中也能快速地新增待辦事項。

此外也透過 IFTTT，將設為Reference標籤的信件備份到 Evernote 中。

事實上這兩種設定都很少使用。

紀錄看過或待看的網頁 🌐​

我會將待看的文章搜集到 Pocket。

除了瀏覽 Facebook 或 Twitter 上的文章，我也使用 Feedly 訂閱一些自己挑選過的網站。並將 Feedly 設定成當我做標記時，就將本篇文章轉存到 Pocket 稍候閱讀列表，我可以掃過 Feedly 列表，標記感興趣的新聞，稍後再到 Pocket 閱讀。

這樣讓我在看到文章連結當下不需急著看完整篇文章，而是在有空閒的時候才閱讀這些文章。

我唯一的待辦事項收件夾是 Todoist，若看到值得閱讀 (紀錄) 的網頁，桌面上我使用瀏覽器的Pocket外掛插件 (Firefox 瀏覽器內建)，將待看網頁記錄到 Pocket 中。

若這個網頁非看不可，我會在按下插件時填入一個自訂標籤fox，然後透過 IFTTT，若發現 Pocket 中新增了一筆含fox標籤的網頁，就新建一筆 Todoist 代辦事項。

在手機上就直接使用 Todoist 和 Pocket 等 App 達到一樣的效果。

文章更新時自動提醒 ⏰​

有些網站並未提供 RSS 訂閱，手機上我會使用Web Alert來取得網頁更新提醒。

開發工具設定自動備份 ¨​

使用 VS Code Settings Sync ，只需剛開始時設定一次，之後可同步各種 VS Code 中的設定與插件。

自動化網站部署 🌐​

目前已使用 Github 來放我的個人網站與部落格，透過與 Travis CI 整合，我所修改的任何內容，在幾分鐘之內都會自動部署到網站上。

如何做可參考 Hello Hexo (個人網站自動化部署) 和 Automatically deploy new commit to github pages via Travis CI

Auto website deploy flow

一些可以直接運作在瀏覽器的專案 (如 BlocklyDuino 和 Saihubot)，我會直接將 gh-pages 設為預設分支，所有改動直接 push 到這分支中。這樣一有改動即可在網頁上看到更新成果。

半自動紀錄​

半自動工作紀錄 💼​

透過翻看 Todoist 或 Google Calendar，我可以輕易地將過去一週達成的事項整理出來，再送 PR 到 Github 上。 也可以說這塊目前只能算半自動化地列出過去事項列表，可以再繼續改進。

定期回顧與整理​

我在 Todoist 中增加一個Template項目，裡面放了周檢視 / 月檢視 / 季檢視 / 年檢視樣板，透過重複時間設定，每段時間自動提醒該做檢視了。

撰寫本文的目的之一，也是讓我有回顧我的自動化運作的機會。

照片備份規則​

由於 Dropbox 空間有限，會不定期將 Dropbox 上的照片移動到到 NAS 上按年月份分類的photo/資料夾.

我的照片並不算多，但若有出遊的月份通常照片會暴增。所以我的基本備份規則是依年份，並以雙月份命名資料夾，若是當月有重大活動則直接在檔名中標注。 例如 2016 年的照片資料夾裡會有2016_10_11，或是2016_06_london這樣的命名。

在整理照片的時候，每當遇到特別喜歡的，我會另存到 Dropbox 中的一個依年份歸檔的資料夾，例如 2017 年的精彩照片我會另存到 dropbox/spot/2017資料夾中，這樣隨時可以找出來欣賞。

另外每年累積的一些螢幕截圖，也放在當年度的screenshots資料夾裡。

清理 RSS Feed​

透過 Feedly 訂閱 RSS Feed 太容易，但是不小心每天收到的新聞量就遠高於自己能吸收的量，這時可以到 https://feedly.com/i/organize/my 把那些失效的連結清掉，並快速檢視一下現在仍在訂閱的網站，是否還對這些主題感興趣。

手動紀錄​

為了平衡日常太依靠電子產品的趨向，前年開始就嘗試使用實體筆記本作一些紀錄，2018 一月中開始嘗試養成更頻繁地使用實體筆記本的習慣。在幾經調整後，目前我使用 B5 方格筆記本做基礎，搭配不同的魔擦筆來作筆記。實體筆記本的好處是除了一般的紀錄，還可以隨意畫心智圖，黏照片，貼紙，蓋印章等。參考各種筆記術書籍，我在每本筆記本前幾頁會空出索引區，將筆記本內容索引起來，以便之後查找。

暫時還沒想好（也還沒需求）該如何數位化。

參考資料​

2009 年推出的 Node.js [^1] 是讓 Javascript 成為一門廣為通用的程式語言的關鍵。Node.js 將原專為 Chrome [^2] 瀏覽器開發的 V8 引擎抽離出瀏覽器，讓使用者在一般命令行環境中就可以執行 Javascript。

開發者的需求​

要完成一個全功能的現代網站，開發者除了需要至少理解某門語言相關的網站後端技術之外，Javascript 也是身在 Web 開發領域的開發者至少必須 "略懂" 的腳本程式語言 (scripting language)。

既然不管精通哪門程式語言的開發者，想在瀏覽器上發揮，都仍需要某種程度地熟悉 Javascript 程式語言。那麼，如果在瀏覽器之外，也可以拿 Javascript 來做事情不是很好嗎？

Node.js​

Node.js 並不是第一款讓使用者在一般命令行環境中就可以執行 Javascript 的工具 (最早推出的可能是 Mozilla 的 Rhino 或 XULRunner [^3])，但它跟上了潮流。 2008 年推出的 Chrome 瀏覽器，裡面使用了同被 KDE 與 Apple 使用的 Webkit 作為渲染引擎 (Render)，並自行開發了全新的 Javascript 引擎 (V8 引擎)。Chrome 瀏覽器的 V8 引擎率先支援 JIT (Just in Time) 編譯技術，使得當年 Javascript 的執行效率一舉提升了 8 倍以上📈。基於 V8 引擎的 Node.js 也比其他 Javascript 運行環境有更強的競爭力。由於執行速度的改善，Javascript 語言終於有了和其他程式語言在瀏覽器之外的環境同場競技的實力。

Node.js 的好夥伴: NPM​

Node.js 推出當時，除了擁有一個比其他相似競爭者快上幾倍的引擎之外，在隔年整合的 NPM (Node Package Manager)[^4] 套件管理工具，讓 Javascript 開發者擁有了更有效率地分享與重用函式庫的方式。到了今天，下載大多數使用 Javascript 語言撰寫的專案，只要執行npm install(或衍生的yarn install)，NPM 就能自行安裝與解決套件之間的依賴關係。NPM 實是今日 Node.js 之所以能形成圍繞著 Javascript 語言建立起龐大生態系的不可或缺的功臣。

Node.js 衍生發展​

隨著 Node.js 更加成熟，Web 開發者也圍繞著 Node.js 重新發明他們常用的工具。最先是 Web 開發框架（如 Express.js [^5], hapi, koa）與資料庫接口，再來是相關的編譯工具（grunt, gulp, webpack [^6]）。同時，也有人開始嘗試將 Node.js 與原有的瀏覽器環境結合，讓開發者得以使用網頁相關技術打造桌面應用（nw.js, electron [^7])。基於此技術還發展了數個流行的程式編輯器（atom, Visual Studio Code [^8]）。時至今日，也可透過 Node.js 相關編譯工具，使用網頁相關技術來做行動裝置 App 開發（Cordova, React Native [^9]）。圍繞著 Node.js 的種種發明，讓使用網頁技術的開發者，得以從開發到部署，全都在圍繞網頁技術的生態系中完成。並由此誕生了稱之為 "Full Stack" 全端工程師（前端，後端，整合，測試）和大前端工程師的工作。全端工程師除了需處理網頁端（前端）頁面版型與互動效果外，也要兼顧伺服器端（後端）與資料庫處理。大前端工程師則是除了網頁端之外，也須兼顧行動裝置 App 的開發。

參考資料​

• [^1] Node.js
• [^2] Google Chrome
• [^3] XULRunner
• [^4] NPM
• [^5] Express.js
• [^6] webpack
• [^7] Electron
• [^8] Visual Studio Code
• [^9] React Native

聊天機器人（Chat bot）已存在許久，常見於各種即時通訊工具中。一般人最可能接觸到的，還是銀行的語音服務（Voice Response System）。

當我們打電話到銀行免付費專線，會有語音提示我們輸入驗證資料，然後輸入對應的數字來得到銀行服務。 只有在根據一串語音提示，輸入特定數字時才轉接到真人回應的專線。這個過程跟使用聊天機器人基本上是一樣的。

銀行的語音服務流程

行動裝置的完全普及​

近年來聊天機器人能重新進入公眾視線，主因還是行動裝置的完全普及： 幾乎所有的人都擁有一台智慧型手機。而且所有人的手機上都有一至數個聊天 App（LINE, Facebook Messenger, Wechat）。

邏輯思維 2017 年跨年演講 [^1] 裡提到，美國，中國想上網的人基本都已經能上網（上網人口已經接近飽和），人們每周平均花 24 小時上網，而這些數字都已經沒有太大的提升空間。因此所有的網路服務都得從有限的總量中搶占使用者的上網時間與關注。

換句話說，2016 年我們已正式進入行動網路（移動互連網）的下半場，廠商除了需要想方法佔用更多使用者上網時間之外，另一條路或是協助使用者更有效地利用上網的時間。

聊天 App 佔用使用者更多上網時間​

2016 年初的調查顯示，人們每天平均在手機和在電腦上所花的時間差不多。 隨著手機 App 的發展，人們能透過手機完成的事也越來越多。可以預見到的是人們每天花在手機上的時間佔比會再增加。 人們在手機上花費最多時間的是聊天 App 和社交 App。而今天的聊天 / 社交 App 都已內建網頁檢視（webview）功能。 看到「朋友」分享的新聞連結，點選後可以直接瀏覽內容，完全不需要另外再開啟瀏覽器來查看新聞。

由於聊天 App 佔用了使用者多數的時間，依照「使用者在哪，機會就在哪」的原則，聊天機器人，或是對話式界面 (Conversational UI) 成了一個選項。

Siri, 聊天機器人的濫觴​

這波新一代聊天機器人的濫觴，也許可以歸功於 2011 年蘋果推出的 Siri [^2]，雖然 Siri 並不存在於聊天 App 中。 iPhone 的使用者可以透過手機上的 Siri 智能助理應用，做到用口語詢問近期天氣，日程表，查詢地圖，餐廳，設定鬧鐘等行動，從而用更便利的方式取得服務。 雖然今天 Siri 與其他選擇相比，已盡顯不足之處，但當時 Siri 的推出，讓人們感知到與機器直接對話已不再遙不可及，這直接鼓勵了眾家廠商願意加大投入。

近幾年語音辨識，人工智能 AI 的爆發式進展，與此必然有著千絲萬縷的聯繫。

聊天機器人有什麼用？​

Reddit 曾有用戶提問，如果某個 1950 年代的人突然出現，最難向他解釋的現代事物是什麼？
最多人推的回答是： 「我擁有一部機器，就放在我的口袋裡，我可以用它來存取任何人類已知的知識。
我常用這個來看貓咪的圖片，還有跟陌生人筆戰。」
-- @wastemobile

就像现在手机 App 一样，大部分的 App 其实没什么用，用了只是消耗自己的时间。 但是像 Siri 所能做的，使用者透過聊天機器人簡化日常的瑣事，或是快速得到常見問題的答案。 Slack 平台上已有許多機器人，可以同步 Github Bug，同步代辦事項資訊，提醒今日任務等。這些 Bot 能省下使用者寶貴的線上時間。 我們更多需要的是這類型（用更便利的方式取得服務）的聊天機器人。

聊天機器人與使用者的互動方式​

在網際網路上，沒人知道你是一隻狗

聊天軟體原本的功用是讓使用者可以和「另一個使用者」或「一群使用者」交流。聊天機器人則是取代「另一個使用者」的角色 [^3]，讓使用者和「聊天機器人」一對一交流，或是讓聊天機器人加入群組，和「一群使用者」交流。

一對一

群組（多對多）

聊天機器人的應對方式​

除了「一對一」，「群組」（多對多）之外，依據聊天機器人的應對方式，還可以分為通知型（Notify），模式型（Pattern Matching），對話型（Context Aware）等幾種聊天機器人 [^4]。

通知型（Notify）​

通知型機器人會根據使用者「訂閱」的資訊，傳訊息通知使用者。例如明日天氣預報機器人可以定時告訴使用者明天氣象狀況與溫度，出門需不須要帶傘。 使用者一般不需要輸入任何訊息與機器人對話。

模式型（Pattern Matching）​

模式型機器人會比對使用者送出的訊息，如果符合機器人設定好的一些模式，就做出對應的回應。

例如使用者可以透過天氣機器人，輸入 "weather in Taipei" 查詢當前台北的天氣。

基本的模式型機器人沒有對話的概念，並不會根據使用者過去的應對而改變回應的結果。 例如使用天氣機器人時每次都需要指定想查詢的地點，或是透過預先設定地點 / 偏好溫度格式來簡化使用方式。

除了傳統使用正則表達式 (Regex) 來比對模式外，Facebook Messenger bot 則提供更接近口語的自然語言處理（Nature language Processing）模式比對。 多數聊天機器人框架目前都仍偏向模式型。

對話型（Context Aware）​

對話型機器人會從與使用者過去的對話中提取使用者的偏好，並運用到後續的對話中。

例如 Google Assistant 會根據你之前的查詢，去進一步找到你想听的音樂。

能理解與使用者過去的對話，也是對話型人工智能的重要特徵。當使用者在聊天軟體中新加入一個 bot 服務，使用者與這個服務的對話都與和一般服務員的交談無異，那麼服務的後面是不是真人還重要嗎？

參考資料​

• [^1] 羅輯思維 4 小時跨年演講 https://kknews.cc/zh-tw/tech/xz2x4p8.html
• [^2] https://en.wikipedia.org/wiki/Siri
• [^3] 在網際網路上，沒人知道你是一隻狗
• [^4] Bot Design Patterns