Code Behaving Badly

I've been spending a lot of time thinking about what it means to to have infra service approached as products. When I say infra, I'm talking about things like CI/CD, schedulers, validation suites, and monitoring/alerting.

I get that that isn't a new concept, but there's a few things that I've been struggling with. I want to talk about one of them.

The User

When dealing with customers, they are usually low information (as far as your infra goes), and don't have the technical expertise nor background to assist you. They use the thing you give them the best they can. In infra, your customers are engineers too. They not only use the things you give them, they're capable of understanding them to a high level. Even abusing them when there is a lack of proper controls.

This is both a blessing and a curse. Your customers can talk on the same level as you, but they have the same problem you do. They are good at solving things. This don't have the context that you do yet are bringing solutions. The problem being is that they tend to solve their problem in your software, not your problems (which should include theirs).

You want to harness their help, but you don't want to reject them outright either. The best I've found so far is try try and direct that energy into helping them accomplish your broader goal, which if you've planned right, solves their goal as well. The redirection of effort can be useful. However, I want to avoid the discussion in the first place.

Overall, I've not convinced this is the best approach to the matter. I feel like there is something upstream of the discussion that could be done to prevent needing to manage their effort put in by the customer with the problem. I'm still looking for a way to prevent this from happening, outside of having perfect planning.

Heya,

This is just a simple update to let you know that I've moved the blog over to the write.as software. You can subscribe to it in the fediverse via @ryan@codebehavingbadly.com

That is all and I hope you enjoy your stay.

Why

I found myself wanting to create a bot account for my Mastodon installation.

But, I didn’t want to have to set up and configure an email and go through the whole account confirmation email.

These commands did it and let me log in and create an app and start posting.

At the time of writing this applies to at least Mastodon 4.0.6.

How

Enter the Ruby interactive shell as the mastodon user.

~/live$ whoami
mastodon

~/live$ RAILS_ENV=production bundle exec rails c
Loading production environment (Rails 6.1.7.4)
irb(main):001:0>

Create the Account record, followed by the User record.

account = Account.create!(username:'username_of_new_account')
user = User.create!(email: 'username_of_new_account@youmasto.social', password: 'better_change_me', account: account, agreement: true)

Take some actions to confirm the account, without needing to actually have an email and persist the records.

user.confirm
account.save!
user.save!

Go login to the account and do what you need to do.

Why

Here I was trying to be a good Mastodon admin and upgrade the version. I was coming from the 4.0.x branch.

I encountered the following issues and sharing the direct solution as I had to piece together a few different methods from my searches and no one had a direct answer for this.

Issue 1

I was seeing this error while trying to bundle install:

Your bundle is locked to json-canonicalization (0.3.2) from rubygems repository https://rubygems.org/ or installed locally, but that version can no longer be found in that source. That means the author of json-canonicalization (0.3.2) has removed it. You'll need to update your bundle to a version other than json-canonicalization (0.3.2) that hasn't been removed in order to install.

Issue 2

Also, this issue later while pre-compiling the web assets:

mastodon@mastodon:~/live$ RAILS_ENV=production bundle exec rails assets:precompile
Compiling...
Compilation failed:

mastodon@mastodon:~/live$

How

Issue 1 Solution

If you are temporary moving to 4.2.0 instead of a higher version where it is fixed (at least in 4.2.5 it’s at 1.0.0), you can move higher json-canonicalization in your Gemfile.lock.

When I moved it to 0.3.3 I was able to move forward with the upgrade, not sure if 1.0.0 works with < 4.2.5.

[...snip...]
json-canonicalization (0.3.3)
[...snip...]

Issue 2 Solution

Turns out that this command was running out of memory. The base usage of my node is a little over 1G.

So, when webpack was running, it was running out of memory over my 2G limit. Upping my memory to 4G solved the problem.

If you only see this:

Compiling...
Compilation failed:
`isModuleDeclaration` has been deprecated, please migrate to `isImportOrExportDeclaration`
    at isModuleDeclaration (/home/mastodon/live/node_modules/babel-plugin-lodash/node_modules/@babel/types/lib/validators/generated/index.js:2740:35)
    at PluginPass.Program (/home/mastodon/live/node_modules/babel-plugin-lodash/lib/index.js:102:44)

and nothing else, it’s probably a red-herring. This is a deprecation warning… just a shame it’s directly under the heading of Compilation Failed:.