我通常會關(guān)注各種網(wǎng)站-有關(guān)最新出版物，熱門新優(yōu)惠，限時游戲和競賽等。

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

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

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

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

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

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

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

而且您知道演習。

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

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

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

聊夠了。 讓我們編碼吧！

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

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

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

該應(yīng)用程序運行非?？?#xff0c;當我點擊Create Project時，彈出編輯器：

事不宜遲，我抓住了以前的Apps腳本功能的內(nèi)容，并將其放入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腳本代碼轉(zhuǎn)換為NodeJS。 一旦將request模塊添加到項目中，就不那么困難了（畢竟都是JS！）：

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

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

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

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

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

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

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

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

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

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

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

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

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

這很容易，而且拖放操作也很簡單：在“ 現(xiàn)有表”下選擇先前創(chuàng)建的表，然后選擇domain設(shè)置為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操作并在前面顯示小圖標。 單擊后，將顯示（重新）配置彈出窗口，類似于我第一次將其拖放時得到的彈出窗口。

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

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

現(xiàn)在，我該如何定期運行我的機器人？

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

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

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

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

整個event從紅色變?yōu)榫G色，這可能表明我的觸發(fā)器已成功設(shè)置。

對。 該測試一下了。

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

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

幾秒鐘后，會自動彈出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開發(fā)工具包本身的。

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

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

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

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

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

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

從那時起，一切都變得相當自動化：在“成功完成”通知之后，出現(xiàn)了一個非?？斓摹皹?gòu)建”步驟（伴隨著底部狀態(tài)窗格中的進度條）。

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

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

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

現(xiàn)在，讓我們再次嘗試測試。

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

好極了！

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

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

都好; 沒有重復(fù)！

現(xiàn)在檢查我的收件箱，看看Sigma是否在說真話。

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

希望我的CloudWatch觸發(fā)器明天明天凌晨1點觸發(fā)，如果有的話，給我?guī)砹撕孟?#xff01;

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。