我通常會關注各種網站-有關最新出版物，熱門新優惠，限時游戲和競賽等。

其中大多數不提供“干凈”的通知系統，例如RSS feed。 因此，我經常不得不刮擦他們HTML才能達到我所需要的。

這意味著我經常需要運行一些自定義的字符串操作魔術來達到所需。

而且我需要它是周期性的（誰知道下一次熱更新何時出現？）。

并且是自動的（我一天中還有很多重要的事情要做）。

并且是遠程托管的（我不想讓我的筆記本電腦不間斷地運行24×7，并且互聯網連接不中斷）。

到目前為止，我一直依靠Google Apps腳本 （最近是Google App Engine ）來驅動這類自制的集成“代碼段”。 但是，隨著整個世界沉浸在無服務器環境中 ，我為什么不這樣做呢？

因此，我開始遷移我的一個腳本，該腳本是為監視中國零售網站而編寫的。 該網站偶爾會發布各種折扣優惠和季節性游戲，在這些游戲中，我可以通過日常游戲獲得不錯的優惠券和積分。 但是由于某種原因，該網站沒有向我的電子郵件地址發送促銷電子郵件，這意味著我必須不時檢查一下該網站，以確保不會錯過任何有趣的內容。

而且您知道演習。

我很容易忘記事情。 有時，當我離開電腦時，也會想起提醒。 有時候，我懶得去找東西，因為我最終沒有新鮮感，占75-80％的時間。 這么多借口...

此外，當您可以設置機器人，坐下來放松一下時，誰會在他們正確的開發人員心中想做那么無聊的事情呢？

我從AWS Lambda開始， AWS Lambda是免費的無服務器計算的明顯選擇。 它的非到期免費層使我每個月的運行時間達到了令人難以置信的320 萬 （是， 百萬 ）秒–實際上，我可以使一個lambda永遠運行，甚至更多！ –調用次數超過1M （又是百萬次！）。 以前，在App Script或App Engine上，我每天只有90分鐘的時間，每月只有16萬秒，這意味著我不得不非常謹慎地使用配額。 但是現在我可以放開恐懼，充分享受我的發展自由。 與Apps Script或App Engine的框架限制相比，更不用說完全成熟的容器環境了。

聊夠了。 讓我們編碼吧！

我沒有采用標準的方法 ，而是從SLAppForge中選擇了Sigma作為開發框架。 主要是因為它在支持外部依賴項方面享有盛譽，并代表我負責打包和部署工作-包括所有外部服務（API，表，cron和諸如此類）。

首先，我必須注冊Sigma 。 盡管我可以繼續使用其演示功能（黃色的大按鈕），但我已經擁有一個AWS賬戶和一個GitHub賬戶（更不用說電子郵件地址了）； 那為什么不試一試呢？

完成注冊并登錄后，我看到了一個項目選擇窗格，在這里我選擇了一個名為site-monitor的新項目：

該應用程序運行非常快，當我點擊Create Project時，彈出編輯器：

事不宜遲，我抓住了以前的Apps腳本功能的內容，并將其放入Sigma！

let AWS = require('aws-sdk');exports.handler = function(event, context, callback) {// Here Goes NothingPROPS = PropertiesService.getScriptProperties();page = UrlFetchApp.fetch("http://www.my-favorite-site.com").getResponseText();url = page.match(/(lp|\?r=specialTopic)\/[^"]*/)[0];if (url != PROPS.getProperty("latest")) {GmailApp.sendEmail("janakaud@gmail.com", "MyFavSite Update!", url);PROPS.setProperty("latest", url);}// end of Here Goes Nothingcallback(null,'Successfully executed'); }

（我知道，我知道那是行不通的。忍受我:)）

接下來的幾分鐘，我花了我的Apps腳本代碼轉換為NodeJS。 一旦將request模塊添加到項目中，就不那么困難了（畢竟都是JS！）：

但是我必須說我確實錯過了UrlFetchApp模塊熟悉的同步語法。

在App Engine下，我擁有非常簡單的PropertiesService來充當我的機器人的“內存”。 在Sigma（AWS）下，事情并不是那么簡單。 經過一番環顧后，我決定使用DynamoDB （盡管我仍然覺得這太過頭了）。

從頁面中提取URL后，我需要檢查是否已將其通知給自己。 等同于在我的表（以前稱為PropertiesService ）中查詢現有條目。 在DynamoDB-land中，這顯然是一個Get Document操作，因此我嘗試將DynamoDB拖入我的代碼中：

刪除后，DynamoDB條目將轉換為一個彈出窗口，我可以在其中定義表并提供代碼級參數。 希望Sigma會記住表配置，這樣我就不必在我的代碼中一次又一次地輸入它。

由于DynamoDB并不是簡單的鍵值對象，因此我花了幾分鐘的時間來研究如何在其中存儲“值”。 最終我決定使用表單的“文檔”結構

{"domain": "my-favorite-site.com","url": "{the stored URL value}" }

在這里我可以使用每個bot的特定domain值查詢表，從而將表重新用于不同的bot。

在我的舊代碼中，我使用GmailApp.sendEmail()調用在收到新內容時向自己發送通知。 在Sigma中，我嘗試通過拖放簡單電子郵件服務（ SES ）條目來做到這一點：

這里似乎有點打small，因為看來我需要先驗證電子郵件地址，然后才能發送一些東西。 我不確定自己的騎行有多坎,，無論如何，我都輸入了電子郵件地址，然后點擊發送驗證電子郵件 。

果然，我通過電子郵件收到了一個驗證鏈接，單擊該鏈接可以將我重定向到“驗證成功”頁面 。

猜猜是什么：當我切換回Sigma時，彈出窗口進行了自我更新，說明該電子郵件已通過驗證，并指導我進行下一步！

我立即填寫了詳細信息（ 對我自己而言，沒有CC或BCC，沒有主題 MyFavSite Update!和Text Body @{url} （它們自己的可變語法；但我希望它是${} ））：

在SES電子郵件發件人的回調中，我必須更新DynamoDB表以反映已通過電子郵件發送的新條目（因此，我不會再通過電子郵件發送它）。 就像我原始漫游器中的PROPS.setProperty("latest", url)調用一樣。

這很容易，而且拖放操作也很簡單：在“ 現有表”下選擇先前創建的表，然后選擇domain設置為my-favorite-site.com （我的“搜索查詢”；等同于"latest" ”）的"latest" 放置文檔”操作 "latest"在舊BOT）和url條目集的電子郵件地址：

最終，我獲得了相當不錯的代碼（盡管比我親愛的舊版Apps Script機器人要長得多）：

let AWS = require('aws-sdk'); const ses = new AWS.SES(); const ddb = new AWS.DynamoDB.DocumentClient(); const request = require("request");exports.handler = function (event, context, callback) {request.get("http://www.my-favorite-site.com",(error, response, body) => {if (!body) {throw new Error("Failed to fetch homepage!");}let urls = page.match(/(lp|\?r=specialTopic)\/[^"]*/);if (!urls) { // nothing found; no point in proceedingreturn;}let url = urls[0];ddb.get({TableName: 'site-data',Key: { 'domain': 'my-favorite-site.com' }}, function (err, data) {if (err) {throw err;} else {if (!data.Item || data.Item.url != url) {ses.sendEmail({Destination: {ToAddresses: ['janakaud@gmail.com'],CcAddresses: [],BccAddresses: []},Message: {Body: {Text: {Data: url}},Subject: {Data: 'MyFavSite Update!'}},Source: 'janakaud@gmail.com',}, function (err, data) {if (err) {throw err;}ddb.put({TableName: 'site-data',Item: { 'domain': 'my-favorite-site.com', 'url': url }}, function (err, data) {if (err) {throw err;} else {console.log("New URL saved successfully!");}});});} else {console.log("URL already sent out; ignoring");}}});});callback(null, 'Successfully executed'); }

Sigma一直試圖通過提供方便的編輯幫助（代碼完成，語法著色，變量建議等）來幫助我，甚至突出顯示DynamoDB和SES操作并在前面顯示小圖標。 單擊后，將顯示（重新）配置彈出窗口，類似于我第一次將其拖放時得到的彈出窗口。

由于異步，基于回調的語法，我不得不在代碼的n位片段中四處移動。 Sigma處理得很好，在我將代碼粘貼到新位置后，再過一兩秒鐘重新進行了突出顯示。

只是為了好玩，我嘗試手動編輯代碼（不使用彈出窗口），很公平的是，彈出窗口理解了更改并在下次檢查時進行了更新。 對于一個新手來說很整潔，他們希望不花太多時間去完成文檔。

現在，我該如何定期運行我的機器人？

Sigma在函數標題附近顯示一個紅色的閃電符號，并突出顯示相同的event參數。 可能表明這是lambda的調用或觸發點。

對。 他們的文檔說的也是一樣。

AWS文檔和Sigma自己的 文檔向我介紹了CloudWatch計劃的事件觸發器 ，該事件觸發器可以按預定義的時間表觸發lambda，例如Apps Script觸發器，但功能強大得多。 更像App Engine cron表達式 。

如他們的文檔所述 ，我將CloudWatch條目拖到了event變量上，并進行了如下配置：

整個event從紅色變為綠色，這可能表明我的觸發器已成功設置。

對。 該測試一下了。

工具欄上有一個“ 測試 （播放）”按鈕，帶有一個下拉菜單以選擇您的測試用例。 與Apps Script一樣 ，但從某種意義上講，它可以定義調用的輸入有效負載（而Apps Script只是運行沒有任何輸入參數的函數）就更好了：

配置好測試用例并單擊運行按鈕后，狀態欄即開始顯示運行進度：

幾秒鐘后，會自動彈出SigmaTrail日志輸出窗口，并開始顯示一些日志：

errorMessage:"RequestId: 87c59aba-8822-11e8-b912-0f46b6510aa8 Process exited before completing request" [7/15/2018][5:00:52 PM] Updating dependencies. This might make runtime longer than usual. [7/15/2018][5:00:55 PM] Dependencies updated. [7/15/2018][5:00:57 PM] ReferenceError: page is not defined at Request.request.get [as _callback] (/tmp/site-monitor/lambda.js:13:24) at Request.self.callback (/tmp/site-monitor/node_modules/request/request.js:185:22)

糟糕，看來我弄錯了變量名。

一個簡單的編輯和另一個測試。

[7/15/2018][5:04:50 PM] ResourceNotFoundException: Requested resource not found at Request.extractError (/tmp/site-monitor/node_modules/aws-sdk/lib/protocol/json.js:48:27) at Request.callListeners (/tmp/site-monitor/node_modules/aws-sdk/lib/sequential_executor.js:105:20)

嗯，那是什么意思？

看起來這是來自AWS開發工具包本身的。

也許我拖放到應用程序中的AWS“資源”在AWS端尚不可用； 此外，許多Sigma教程在進行測試之前都提到了“部署”步驟。

哦，好，讓我們嘗試部署這個東西。

我希望能夠進行無縫的“一鍵式部署”，但是當我單擊“ 部署”按鈕時，出現一個彈出窗口，提示我需要向GitHub進行身份驗證。 Sigma可能會將我的東西保存在GitHub存儲庫中，然后將其用于其余的部署。

看到沒有惡意，我單擊了登錄，并在隨后的彈出窗口中授權了他們的應用程序。 幾秒鐘后，我又彈出一個窗口，要求我選擇一個存儲庫名稱和一個提交消息。

我的帳戶中沒有回購site-monitor ，因此我很想知道Sigma會做什么。 正如我懷疑的那樣，單擊“ 提交”幾秒鐘后，又彈出一個對話框，詢問我是否希望它代表我創建一個新的倉庫。

Sigma非常善良，甚至提供創建私有存儲庫的機會。 但是可惜的是，我沒有那么奢侈，所以我只單擊了Create Repo and Commit 。

從那時起，一切都變得相當自動化：在“成功完成”通知之后，出現了一個非常快的“構建”步驟（伴隨著底部狀態窗格中的進度條）。

接下來，我又彈出另一個窗口，這次是“ 變更摘要” ； 再過幾秒鐘，就會在其中填充“部署摘要”：

我對底層細節不怎么感興趣（盡管我確實將cweOneAM識別為我的cron觸發器，將siteMonitorLambda為我的機器人），所以我只是點擊Execute ； 這次等待了相當長的時間（伴隨著另一個進度條，這次是在彈出窗口中）。

一旦達到100％，Sigma表示我的部署以CREATE_COMPLETE狀態完成（聽起來不錯！）。

現在，讓我們再次嘗試測試。

"Successfully executed" [7/15/2018][5:39:34 PM] New URL saved successfully!

好極了！

等等，如果我再次運行它，它會重新發送嗎？

"Successfully executed" [7/15/2018][5:39:41 PM] URL already sent out; ignoring

都好; 沒有重復！

現在檢查我的收件箱，看看Sigma是否在說真話。

最初，我有點困惑，因為我實際上沒有收到電子郵件。 但最終我發現它位于我的Spam文件夾中（可能是因為它是由第三方（AWS）發送的？），并取消了標記，因為它起到了垃圾郵件的作用。

希望我的CloudWatch觸發器明天明天凌晨1點觸發，如果有的話，給我帶來了好消息！

總而言之，圖形化IDE非常漂亮，值得同事們推薦。 除了部署時間（我認為這是無服務器應用程序，Lambda或也許是AWS的特征）之外，我幾乎感覺到了家–甚至所有這些漂亮的功能-自動完成，拖放，GUI配置，測試，日志等。

是時候喝杯咖啡了，然后開始將我的其他機器人遷移到Sigma…嗯…AWS。

翻譯自: https://www.javacodegeeks.com/2018/07/bots-placeless-homeless-serverless.html

總結

以上是生活随笔為你收集整理的我的机器人现在无处可去。 无家可归。 无服务器。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。