网站服务器一年多少钱,wordpress order,仅仅建设银行网站打不开,付费做网站关键词优化是怎么做的呀无处不再的广告我通常会关注各种网站-最新出版物#xff0c;热门新报价#xff0c;限时游戏和竞赛等。 其中大多数不提供“干净”的通知系统#xff0c;例如RSS feed。 因此#xff0c;我经常不得不刮擦他们HTML才能达到我的需求。 这意味着我经常需要运行一些自定义的字… 无处不再的广告 我通常会关注各种网站-最新出版物热门新报价限时游戏和竞赛等。 其中大多数不提供“干净”的通知系统例如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|\?rspecialTopic)\/[^]*/)[0];if (url ! PROPS.getProperty(latest)) {GmailApp.sendEmail(janakaudgmail.com, MyFavSite Update!, url);PROPS.setProperty(latest, url);}// end of Here Goes Nothingcallback(null,Successfully executed);
} 我知道我知道那是行不通的。忍受我:) 接下来的几分钟我花了我的Apps脚本代码转换为NodeJS。 一旦将request模块添加到项目中就不那么困难了毕竟都是JS 但是我必须说我确实错过了UrlFetchApp模块熟悉的同步语法。 在App Engine下我使用了非常简单的PropertiesService作为我的机器人的“内存”。 在SigmaAWS下事情并不是那么简单。 经过一番环顾之后我决定使用DynamoDB 尽管我仍然觉得这太过头了。 从页面中提取URL后我需要检查是否已将其通知给自己。 等同于在我的表以前称为PropertiesService 中查询现有条目。 在DynamoDB-land中这显然是一个Get Document操作因此我尝试将DynamoDB拖入我的代码中 删除后DynamoDB条目将转换为一个弹出窗口我可以在其中定义表并提供代码级参数。 希望Sigma会记住表配置这样我就不必在我的代码中一遍又一遍地输入它。 由于DynamoDB并不是简单的键值对象因此我花了几分钟的时间来研究如何在其中存储“值”。 最终我决定使用表格的“文档”结构 {domain: my-favorite-site.com,url: {the stored URL value}
} 在这里我可以使用每个机器人的特定domain值查询表因此可以将表重用于不同的机器人。 在我的旧代码中我使用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脚本机器人要长得多 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|\?rspecialTopic)\/[^]*/);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: [janakaudgmail.com],CcAddresses: [],BccAddresses: []},Message: {Body: {Text: {Data: url}},Subject: {Data: MyFavSite Update!}},Source: janakaudgmail.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 这次等待了很长的时间伴随着另一个进度条这次是在弹出窗口中。 一旦达到100Sigma表示我的部署以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无处不再的广告
