scheduling toots on mastodon

Last week, I wrote about my first month of Mastodon. This post is about three options for scheduling a Mastodon toot.

Option 1 – scheduler

The scheduler is easy to find. To use it, you go to your mastodon profile and choose “Development”. This lets you get an API key which you use to login and post. However, it doesn’t support images. (My use case involves an image in each toot.) It also didn’t work in Safari, but did in CHhome for me.

Option 2 – write your own

I started doing this. The REST APIs are well documented. There’s a variety of API wrappers for different languages. The Java one hadn’t been updated in four years and the Python one appears to want your password (not just access key), so I decided to stick with REST APIs. I created a GitHub action. First I used curl to test getting the token from a secret and calling a URL Then I played at the command line on uploading files.

name: JeanneTest

"main" branch
 #  push:
 #   branches: [ "main" ]
 # pull_request:
 #   branches: [ "main" ]
 #  - cron: "0 2 * * 1-5"

  # Allows you to run this workflow manually from the Actions tab


    runs-on: ubuntu-latest

      - name: REST API test
        run: |
          curl --header "Authorization: Bearer $MASTODON_ACCESS_TOKEN" -sS

This all worked. My next step would have been to switch to Python or Perl to call the attachment API, parse it’s JSON and publish the toot. Then add some sort of scheduler logic. I didn’t get that far because I learned about option 3.

Option 3 – Fedilabs

Fedilabs has an app for that. To use it, you login to your instance and get an auth code. (Each time you schedule.) Then you schedule your toots.

The only think I didn’t find intuitive was the alt text. (You have to upload your image and then the option appears.) What’s cool is that nothing is stored. The app uses the Mastodon REST APIs right away. You can even see your scheduled toots on top.

While I could have written my own, this one is better. And it already exists. So I put some money in the tip jar and am happily using.

Bonus – asking OpenGPT for help

I was thinking to have OpenGPT help me write this blog post. I asked “how do i schedule a mastodon post“. Alas:

I’m sorry, but I’m not able to browse the internet, so I’m not able to provide specific instructions on how to schedule a post on Mastodon. However, Mastodon is a social networking service, so you may be able to schedule a post by accessing your account and looking for a scheduling or scheduling option in the settings or composing a new post.

I then clicked “try again” and got the following. That’s probably true on some client. It isn’t the web browser nor the official iOS Mastodon app.

To schedule a post on Mastodon, follow these steps:

  1. Open the Mastodon app on your device and log in to your account.
  2. Click on the “+” button in the bottom right corner to create a new post.
  3. Type your post in the text field and add any photos or videos you want to include.
  4. Click on the “Schedule” button in the bottom left corner of the screen.
  5. A calendar will appear, allowing you to choose the date and time you want your post to be published.
  6. Once you have selected the date and time, click on the “Schedule” button to confirm.
  7. Your post will now be scheduled and will automatically be published at the specified time.

Java + Cron Job = Quartz

Quartz Enterprise Job SchedulerOne of my favorite, often least used, open source tools for Java/J2EE applications is the Cron Job scheduling tool Quartz. Anyone who’s ever administered Linux or a web server is probably familiar with creating and modifying cron jobs to run a process at a specific time of the day/week/month. For example, you may need a nightly clean job for a data directory, or you may need to generate reports automatically at the end of the week. What I like about Quartz is that it’s simple to use, works in both Java and J2EE server-based applications, and is easy to install.

Java with operating-system cron jobs
Despite the availability of Quartz and similar Java-based tools, some developers still choose to use the operating system crontab and set it up to call Java methods directly. Although this can work well in practice, it’s not a very stable solution. For example, if the Java home variable changes, the cron job could break. Also, it’s not portable, since each operating system has a slightly different scheduling tool. Most importantly, though, the application is more vulnerable to attack since it requires input from a process outside the JVM.

What is Quartz?
Quartz is an open source scheduling module written entirely in Java, which lives inside the JVM. It has complete support for creating jobs based on crontab-like syntax, such as using the string “0 4 * * * ?” to run a job every day at 4am. It also supports a more rigorous non-crontab syntax for schedules that can’t be specified in a single string. Anytime a developer needs to write a process that runs in the background, whether its run once a day or every 5 minutes, they should consider Quartz for their scheduling needs.

Creating a Job
Even though you probably only have one job you want to schedule, all Quartz applications start by creating a scheduler that can support any number of jobs using the following code:

SchedulerFactory schedulerFactory = new org.quartz.impl.StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();

From there, we can create our 4am job schedule by defining the job, defining the schedule, and then tying the two together by adding them to our scheduler instance, as below:

JobDetail job = new JobDetail("myJob",MyClass.class);
CronTrigger schedule = new CronTrigger("mySchedule",Scheduler.DEFAULT_GROUP,"0 4 * * * ?");

Finally, you create a job class, in this case MyClass, that implements the Job interface and has a method quite similar to a main method:

public class MyClass implements Job {
   public void execute(JobExecutionContext context) {
    ... // Perform job

Keep in mind that this code to create the scheduler and job can be in any class. The only class-level restriction is that the job itself has to implement the Job interface. How and where the job is created is up to you.

J2EE: How to apply?
J2EE servers often run for long periods of time, therefore they are a natural fit for Quartz scheduling. For example, you can use Quartz to create reports out of large sets of data in the middle of the night when usage is low. There are literally dozens of ways to integrate Quartz with J2EE, but the two main ways I prefer to use are:

  • Job calls a session bean method
  • Job creates a message and sends it to a JMS queue

In both cases, the job itself is *never* more than a page of code. It just picks up what it was called for and executes a J2EE call. In this manner, you might have a bean called ReportBean with a method on the bean call generateNightlyReport(). The Quartz job would be a short segment of code that connects to the bean and executes the session bean command.

My favorite method, though, is to have a job create a message and send it to a JMS queue, since the Quartz process can return without waiting for the actual job to finish. Also, the job does not require a transaction or context since it’s going to a queue instead of executing a bean directly. As long as you have a messaging bean watching the queue, the job will get executed soon after the Quartz scheduler has finished processing the request.

Some tips
Hopefully this article has given you a taste for Quartz as a scheduling tool. While I am aware there are other scheduling tools in Java, Quartz has always worked right out of the box for me with very little effort, so to be honest I’ve never had a reason to try another. Here are some tips I recommend to write good Quartz applications:

  • Keep your job class under a page. If you find yourself writing a very large job class, extract the useful code into a separate class and have the job code call that class. In this manner, there’s very little code actually tied to your scheduler and you can reuse the class outside the context of scheduler.
  • If your schedule executes often or your jobs are quite long, there’s the distinct possibility a job could be started while the last job is running. For example, if a job runs every 2 minutes and the first job is taking 3 minutes, Quartz won’t block the second job from starting so you will have multiple instances of the same job running at once. While there are probably ways to prevent this within Quartz, one sanity check I like to enforce is a semaphore lock that prevents two threads from executing the same code at the same time. In the case a second job is started while the first is running, the second should just exit instead of waiting for the first to finish. In Java, you can do this atomically by setting an int to 0 or 1.
  • Quartz is often included in a number of J2EE server packages, so you may have it without the need to import the libraries. Keep in mind, though, that the existing version installed with the J2EE server may be older than the one you want to use. In that case, you may want to import your own Quartz jar into the application.