Sporting coding note

    標題不知道要怎麼下，意思是說除了下指令給 bot，bot 會回覆相關資訊之外，還可以主動發訊息給指定的 Line 用戶 (當然，前提是這個 Line 用戶需要加入 bot 為好友）。 Line Messenger API 除了提供 reply_message 的方法之外，還有提供 push_message 的方法。     reply_message 顧名思義是當用戶發出訊息給 bot，bot 針對這一個訊息所作的回覆，經測試發現一個 reply token 只能回覆一次，無法針對同樣一個 reply token 一直傳訊息，意思是一個 reply token，只能用一次 reply_message，不過一次 reply_message 可以傳入多個訊息就是了。     另外一個測試發現 reply token 有它的生命週期，bot 在處理用戶訊息如果過久未回覆，reply token 也會失效；那如果真的需要長時間處理的動作該怎麼辦呢？這邊建議可以使用 push_message 的方式，在用戶發出訊息時，可以取得用戶 ID，在處理完畢後，針對這個用戶 ID 傳送訊息，就會很像 bot 針對訊息回覆的情境。     離題了，這次主動通知系統用了 push_message 做了什麼呢？     其實就是 server 排程作業結果回報通知，排程作業各位可以想看看能做什麼，我是用來做小米商店商品開賣通知，因為小米商店常常缺貨，但是又很想要這商品，又不想從大陸買進來（擔心保固、電壓、插座、運送等問題）。在 web server 上實做了傳訊息給 Line 用戶的 push line api，排程作業透過 curl 呼叫 push line api。 示意圖如下

    來到了2016年的年底，想年終盤點一下自己的技能樹狀態，自從換了工作這兩年自己碰了些什麼？     習慣騎車上班的路上替自己設定今日工作目標，說是工作目標，廣義上不如說是今日目標，除了工作任務外，另外加上想了解的軟體發展、最近熱門的軟體架構、時下最夯的程式語言、github 大神們分享的專案、軟體佈署的議題，甚至寫些能方便自己生活的程式。     有些人會認為這樣的作息對得起公司嗎？對我來說，上班除了工作任務之外，其他的時間用來自我學習成長，對於公司跟個人都是雙贏的作法；在不耽誤工作的情形下，其餘時間用來加強自己的本職學能，不是很正常的嗎？難道大家一整天都會全力在工作上嗎？至少我選擇了對公司跟個人都好的"休閒"，無愧於心。     兩年前換了新工作後，一開始也是躍躍欲試，一頭栽進現有系統的架構了解、這邊的程式撰寫模式，不過總是事與願違呀，企業文化、部門文化不是一個小螺絲釘可以輕易改變的，更何況身處傳統產業，思維跟企業軟體發展完全無法因應時代的變化，今年是2016但是開發環境還在 vs2008 vb.net，連 nuget 套件管理工具都還沒有起步的IDE，不過就算有也沒用，因為畢竟是自己企業內部的系統，系統的穩定更勝於一切，只能用MS自己出的元件，做出最陽春的功能，軟體開發人員在這能學到多少，會有這種期待的我，我想我也是醉了。與其坐以待斃，不如利用時間加強自己的能力，也許哪天會用的上呢！      回到正題，列表（工程師風格） Softward develop 1. Android app develop      1.1 三維測量儀 ( blog | google play store )     1.2 台北市安心地圖 ( blog | google play store | youtube )      1.3 協尋毛小孩 ( blog | google play store | youtube )     1.4 陽光空氣水 ( blog | google play store | youtube )     1.5 譯圖文 ( blog | google play store | youtube )      1.6 吹哨找手機 ( blog | google play store | yout

好吧！最近又在整理照片，一直在想要怎麼整理一堆照片，光是分類就花費不少時間。 上次的 ezOrganizePic 是用 jhead 取得 EXIF 資訊，依拍照日期將照片歸到各自的資料夾。 參考以往的分類習慣，除了日期就是景點分類，格式像是 "20161111_華山1914文化創意產業園區"，可是沒看照片怎麼知道在哪裡拍的？就算看了照片也不見得有拍到景點（因為是拍人像），沒看到景點還是想不起來。 看一下 EXIF 提供的資料，現在都用手機拍照，而且都會放入 gps 位址資訊，其實是知道在哪裡拍的，只是 gps 代表的位址在哪裡呢？ 這時只能對 google 大神拜拜了，google 提供了 place api，在大家標注景點的時候，是可以透過這個 api 取得的。 好！這個 shell 的目標主要是 1. 掃圖檔 2. 取得 EXIF gps 資訊 3. 轉換 gps 時分秒成 google 要求的 gps 格式 4. 透過 google place api 取得指定 gps 最近的景點 5. 將照片的檔名重新以景點命名 6. 看檔名就知道在哪裡 敗筆是一堆亂七八糟的景點怎麼過濾呢！跑出一堆公司行號的景點或是私人景點（家）無法被正確標記。 如果這可以處理，相信會有些市場的，加油加油。 github: autoSceneName2Pics

如題，有興趣試用的可加入或加入再封鎖。 ps. 個人電腦充當Server，效能不彰、隨時無回應，如果能接受就加吧！

繼上上次 FB Messagenger bot   及上次的 Line bot 學習製作的過程， 對於聊天機器人"聊天"這檔事有了一些體悟，所以寫下來供作參考。 先回顧一下 FB Messenger bot 開發經過，首先 FB 在今年年初推出了 Message Platform，自己興致勃勃的找了些教程，用 node.js 開發並佈署在 heroku.com。 FB 提供了一個大～平～台（王大陸～原諒我很想寫這個爛梗)，讓大家可以透過 Messenger，從後台接收訊息及發送訊息到客戶端。 說穿了，這些聊天平台將自己的服務跟各個企業的商業服務做個管道出來，對於聊天平台跟其他運用這服務的企業算是雙贏的局面，一方面替自己衝使用量，佔據社群軟體的榜首，一方面替企業精簡人力、擴大銷售。 聊天平台原本的社群服務加上企業原有服務，透過 "聊天機器人" 這個溝通管道，更加強了雙方的連結。 軟體架構其實是相對的單純，撇除聊天平台原本的溝通界面服務、、各大企業原本也有相應的網路服務，透過 sdk 交換雙方的訊息也不難。 終端消費者在聊天平台提供的界面上打打字，透過 sdk 交換訊息到企業網路服務，企業網路服務接收訊息後回應終端使用者，最終達成終端使用者的目的。 目前看似一切都在既有的服務上作業，sdk 使用上也簡單，那問題在哪裡？ 問題就在 "聊天" 這檔事，如果消費者打了某段訊息，例如"我要買電視"，企業接收訊息後判斷有"電視"兩個字，就推出自家電視產品廣告；那這跟透過指令界面一個口令一個動作有什麼不同？ 萬一消費者打的訊息內容是 "我要買可以當電視的平板電腦"，結果推薦的是電視，那會有多囧，我要是消費者馬上就跳開這個平台，不好玩又亂推薦。 關於 "聊天" 這檔事，雖然日常生活無時無刻都在聊天，認真分析起來，聊天機器人真是呆板的可以，但是還是要努力不要讓他/她變成"它"，我們還是期待機器人是個人呀！ ok google、siri 這樣聰明的個人管家跟聊天機器人的目的性不同，聊天機器人的聊天支線、主題比較可以聚焦。 關於聊天機器人 "聊天" 這檔事，列下四點： 1. 單一時間點的討論只會圍繞單一個主題，