Tag: aws

Posted on

Moving my Twitterbot @kevinhookebot to Mastodon @kevinhookebot@botsin.space

I mentioned a few days back that I’ve started to look at migrating some of my Twitter bot projects over to Mastodon, specifically to the botsin.space Mastondon server. Over the past few years I’ve deployed a number of bots that have been running continually for a number of years now without any updates. My motivation to move away from patronizing Twitter since the buyout is that it’s not a place I want to hang out anymore, but also I have some tech updates I need to take care of for these bots. A few of them I deployed 5 years ago and the AWS Lambda runtimes they were deployed with are now long past their support and have long been deprecated.

The main Lambda for @kevinhookebot was deployed originally in 2017 but updated at some point at least once in 2018:

The Lambda that watches for replies to a Tweet and replies automatically I don’t think has been updated since it was first deployed, and has been running on the Node6 runtime since 2017:

Both of these need to get redeployed with a later/supported runtime and also moved to using the Servlerless framework to help automate the deploys. It’s also odd that given that I share most of my hobby projects on Github, neither of these were committed to a repo anywhere, so first steps were to commit the original source to Github, and then starting making my updates.

First Steps

Before completely retiring the Twitter accounts, I’m going to update most of these to either cross-post to Twitter and Mastodon, or fork a Mastodon version and keep both running for a while, then eventually I’ll close the accounts on Twitter later.

For first steps, updating @kevinhookebot has to add integration with Mastondon’s apis to post a status update. I’ve got some learning to do with the apis and the authentication approach, but so far using the mastondon-api npm module, posting a status update is as simple as:

let Mastodon = require('mastodon-api');
let config = require('./config/config-mastodon.json');

exports.postMastodon = (item) => {

    const M = new Mastodon({
        access_token: config['access-token'],
        api_url: 'https://botsin.space/api/v1/',
    });

    M.post('statuses', {
        "status" : item.tweettext
    })
        .then((resp) => console.log(resp.data));

}

I still have to things to work out, like how to query replies to a Toot that I’ll need to support some of my other interactive bots, but so far so good.

Posted on

AWS DynamoDB error: ValidationException: One or more parameter values were invalid: Condition parameter type does not match schema type

Executing a query against a Global Secondary Index I got this error:

ValidationException: One or more parameter values were invalid: Condition parameter type does not match schema type

Using the NodeJS Document api, my query looked like this:

let params = {
        "TableName": "exampletable",
        "IndexName": "example-createdate-index",
        "KeyConditionExpression": "exampleattr1 = :exampleattr1",
        "ExpressionAttributeValues": {
            ":exampleattr1": { "S": "0" }
        },
        "ProjectionExpression": "createdate, exampletext",
        "ScanIndexForward": false
    }
return docClient.query(params).promise();

The error is saying that one of my query parameter types does not match the values in the schema. I know this value is a String so this looks correct. Following recommendations on this question, it’s suggested to not pass the param type as “S” and let the Document api work out the type itself.Remove the “S” and just passed the value and now it’s working as expected.

Posted on

Planning to migrate my AWS Lambda Twitter bots to Mastodon

Like everyone else right now, I’m mulling options to migrate away from Twitter, likely to Mastodon (follow me at @kevinhooke@mastodon.social !). Moving my personal usage is relatively simple, other than rebuilding a list of people and tags that I like to follow. I also have a number of Twitter bots running on AWS Lambdas that I’ve built over the years that I should move at some point.

The easy part is that the code that’s running as an AWS Lambda doesn’t need to physically move anywhere, that can continue to run where it is. The part that needs to change is the APIs it’s using to integrate with Twitter and update them to use APIs to post to Mastodon instead.

I’m still in early stage of looking at options so far. I’ve discovered there’s a Mastodon instance, BotsInSpace, that’s specifically for running bots, so that addresses that first step, where they need to run against. I’ve also been reading through a few articles on developing bots for Mastodon such as this one. So far looks like it shouldn’t be too much of a big deal to move them across.

Posted on

Restructuring / refactoring my Mastodon ZorkBot

Now my ZorkBot is working over at @zorkbot@botsin.space I’ve restructured the 3 Lambdas so it’s easier to follow what calls what.

In it’s current/initial working state, I built it with 3 AWS Lambdas:

mastodon-zorkbot

This Lambda runs every 5 minutes, checking for players messaging the bot

  • checks for last replied to messages so it only replies to a message once, using a DynamoDB table
  • if a new reply is needed, sends the game move command from the player to the next Lamdba, mastodonbot-aws-sdk2
  • replies to the player using the Mastodon APIs

The Lambda is deployed as: mastodonbot-zorkbot-dev-mastodon-reply

mastodonbot-aws-sdk2

This Lambda is called by mastodon-zorkbot, and provides parsing of the text responses from the frotz Custom Runtime Lambda, which is calls next

custom-lambda-zork

This is a Docker image for a Custom Lambda Runtime that invokes the frotz binary. This is the zmachine game runtime that runs the Zork game. It could be updated to run any game supported by frotz. The Custom Runtime has a shell script that pipes echo commands into frotz, captures the response and retuns to mastodonbot-aws-sdk2

The Refactoring

For first steps I’m just going to rename the folders of each of the Lamdbas and the serverless.yml service names so it’s easier to track what calls what in sequence:

mastodon-zorkbot -> zorkbot-1-mastodonreplies

mastodonbot-aws-sdk2 -> zorkbot-2-responseparser

custom-lambda-zork -> zorkbot-3-frotzcustomruntime

Will update later with progress.

Proudly powered by WordPress