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.

Jest error parsing React jsx files “Support for the experimental syntax ‘jsx’ isn’t currently enabled”

I ran into this error adding new Jest tests to my React project:

SyntaxError: CellComponent.test.js: Support for the experimental syntax 'jsx' isn't currently enabled (7:34):

and then this recommendation at the end:

Add @babel/preset-react (https://git.io/JfeDR) to the 'presets' section of your Babel config to enable transformation.

Doing an ‘npm i @babel/preset-react –save-dev’ gets us almost all the way there. Add a default babel.config.js with this config and you’re ready to go:

module.exports = {
    presets: [
      '@babel/preset-react',
      [ 
        '@babel/preset-env',
        {
          targets: {
            node: 'current',
          },
        },
      ],
    ],
  };

I pieced this together from multiple places, answers on this question got me in the right direction.

Your experience level in Software Development will lead you to wildly different points of view and opinions

How you view the world around you is affected by your own prior experience. In software development, if you are just starting out, suggestions and guidance from more experienced developers can appear stubborn and shortsighted, but they’re offering a point of view based on their own experience too, what they’re seen work and not work.

For example, say you’re just starting out and you come across this new library/framework that has this one function that does exactly what you need, so you propose adding this new framework to the system.

A more experienced developer you are working with rejects your suggestion, saying that it’s not worth adding a new framework just to pick up this one function.

You go away thinking, ‘huh, that’s a shortsighted point of view, they should be more open to new ideas. They’re obviously stuck in their ways and resistant to change’.

Now think about this from the more experienced developer’s point of view:

  • Adding another framework adds complexity to the system. More complexity means more risk, more things to go wrong, more things to maintain
  • Relying on frameworks and modules brings it’s own overhead – you need to track security vulnerabilities and patches, and update your existing code to integrate with new releases if there are breaking changes
  • Adding a new framework for the sake of taking advantage of one function brings additional risks, even in the parts of the framework you don’t intend to use. What if there’s a security vulnerability in the unused parts of the framework that could be exploited by a malicious user? What if something from the unused parts has an impact on your existing code, e.g. by changing module dependencies unexpectedly?
  • What are the costs and risks to the project of adding this one framework? Would it be cheaper to build it yourself? Are the other costs and risks worth adding the new library even if in the short run it would be quicker to add it now?

If you’re just starting out maybe these are things you’ve never thought about before, or never been in a position where you’re responsible for making these decisions. When someone with more experience makes a decision or offers advice that appears unusual to you, ask yourself what factors they may be looking at the resulted in the decision. Ask them why they made the decision and/or what are the factors they were considering that led them to a decision? Often, things that appear to be being resistent to change and being inflexible are the result of considering and weighing many other risks and potential costs that you have not considered yourself.