Forem: JoaoCardoso193

Making My Own Answering Machine - A Quick Primer on the Inner Workings of Web Applications

JoaoCardoso193 — Fri, 15 Jan 2021 23:29:36 +0000

Intro
Part 1: The Backend and the API
Part 2: The Frontend Webpage
Part 3: The Answering Machine Script
Conclusion

Intro

Having been born near the very end of the '90s, I've always lived in a world of incredibly fast and innovative technological advancements. Within my first two decades of life, I've witnessed the rise of smartphones, the widespread adoption of home internet, the rise of social media, the digitalization of nearly every service, and much more.

While I am grateful for all the convenience and entertainment modern technology is able to provide us with today, I can't help but be fascinated by the machines of yesteryear that I never got to use or experience. One such machine is the famous answering machine, which hit peak popularity in the '80s and '90s. An endearing product of the era, this technology eventually became obsolete and was gradually fazed out of the mainstream when telephone companies started offering voice mail services.

Still, the image of sitting on the couch at home with a glass of wine while listening to messages your friends and acquaintances left you throughout the day has always appealed to me - an idea that, undoubtedly, has been instilled into my brain by countless Hollywood classics.

With the pandemic forcing all my university classes online this semester, I've decided to go back to sunny Portugal to finish my degree from home. While being back here definitely has its fair share of benefits, I'm sure I'll miss all the friends I've made in the U.S. and who I won't be able to see anymore until later this year when I go back to graduate.

So I thought: "what better time to get myself an answering machine than now? Having a novel, yet retro, communication system that my friends can use to leave messages from anywhere in the world seems like the most fun way to keep in touch."

And so that's what I did, I sat down in front of my computer for an afternoon and built a web app that allows my friends to reach me within seconds by sending a message that will be read out loud by my computer. In this blog post, I will share how I built this app to give you some inspiration on how you can build yours too, and as a means of explaining how web applications work in general. I will purposely omit details to avoid having my answering machine hijacked by internet strangers.

Note: throughout this post, code or text encapsulated inside <> symbols is meant to be replaced.

Part 1: The Backend and the API

If a full web application can be thought of as a restaurant, the backend of a web application can be thought of as the restaurant's kitchen. For most customers, a restaurant's kitchen is a black-box where orders come in and food comes out, but for the workers of the restaurant, the kitchen is where all the magic happens. This is the place where food is stored, prepared, and cooked according to the restaurant's recipes.

This is similar to how web applications work: for many interactive websites, there is a backend portion (a kitchen) that stores all of the relevant info (the food) about its users and content and that processes (prepares and cooks) this info as needed following the logic (the recipes) implemented by its developers (the cooks).

Just like you wouldn't shout out your order directly to the kitchen in a restaurant, the backend of an application isn't directly accessed by its users. Instead, there is an intermediary to relay information between the two.

An Application Programming Interface, or API for short, is an interface that allows someone to interact with an application's backend without having direct access to its code. These are accessible through the internet and can be used to get information from or send information to an application.

Following the restaurant analogy, an easy way to think about how an API works is to imagine it as a waiter. In a restaurant, the waiter (the API) comes to you, takes your order (your request), and passes it on to the kitchen (the backend). Upon receiving your order, the kitchen processes it and delivers your meal (a response) to you through the waiter again. This is essentially how an API is used so that anyone can use applications whose backend they don't have direct access to. Here's a good video of this analogy if this seems confusing.

In order to implement my answering machine app, I needed a backend application with a database to store messages. I also needed an API that would communicate with this backend application. The API needed to work two ways: it had to be able to receive messages from anyone anywhere in the world and it had to be able to retrieve those messages to an authorized user (me 🙂).

There are many ways to set up a backend application with an API, and many different frameworks to do so. Due to my previous experience with the Flatiron School, I decided to go with an API-only Ruby on Rails application. You can read more about how to set up one of those here. However, any method that produces a backend application with an API that includes routes to post, get, and delete messages (the last one being optional) will work just fine.

My main backend application is a simple Ruby on Rails application with an SQL database that stores message models with the following info: an author string, and a body text. There was no need to write custom methods for a message class or anything like that as the main logic of the answering machine was handled by the script that I wrote in the end (more on that later in this post).

Truly, the gist of this project's backend and API is just a set of routes and an SQL table with the following schema:

ActiveRecord::Schema.define(version: 2021_01_10_144146) do

  # These are extensions that must be enabled in order to support this database
  enable_extension "plpgsql"

  create_table "messages", force: :cascade do |t|
    t.string "author", limit: 50
    t.text "body", null: false
  end

end

*Note: the limit: 50 and null: false statements simply certify that the author's name is no longer than 50 characters and that a message's body is not empty.

And here's the messages controller with all the relevant RESTful routes:

class MessagesController < ApplicationController
    def index
        render json: Message.all
    end

    def create
        message = Message.new(body: params[:body], author: params[:author])
        if validate(message)
            message.save
            render json: {'status': 'Message sent successfully!'}
        else
            render json: {'status': "Failed to send: message body can't be empty!"}
        end
    end

    def show
        message = Message.find(params[:id])
        render json: message
    end

    def destroy
        #patch request deletes message by default
        message = Message.find(params[:id])
        message.destroy
    end


    def validate(message)
        #validates message by checking that it is not empty
        if message.body != ''
            return true
        else
            return false
        end
    end
end

With the backend and the API working together through a Ruby on Rails application, it was time to host it online. Heroku is a free hosting platform that anyone can use to deploy their applications on the internet, so that's what I used. The process of deploying a Ruby on Rails application with Heroku is detailed here.

Part 2: The Frontend Webpage

Great! With the backend and the API done, it was time to set up a user-friendly access point where friends could send me messages by posting them to the API.

Continuing our previous analogy, think of a frontend of a full application as the dining area in a restaurant. This is where customers (users) sit, send their orders (requests) to the waiter (API), receive their food (responses), and eat (use the application). For most customers, this is the only part of the restaurant they'll ever inhabit, and the same is true for web applications.

In even simpler terms, the frontend of a web application is what you're using right now to read this post - the part that is directly accessible and visible to you without needing to write any code.

If you want to read more on the different parts of a web application, read this article.

To set up the frontend portion of my application, I made a simple HTML webpage that displays a form to visitors as such:

The entire HTML page is just 20 lines of code:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8" />
    <title><App Title></title>
    <script type="text/javascript" src="src/script.js"></script>
    <link rel="stylesheet" href="css/styles.css" />
  </head>
  <body>
    <div class="form-style-6">
      <h1>Welcome, any messages you send here will be read out loud by my computer!</h1>
      <form id='messageForm'>
      <input type="text" name="author" placeholder="Your Name (optional)" maxlength="50" />
      <textarea name="body" placeholder="Type your Message" maxlength = "280" style="resize: none"></textarea>
      <input type="submit" value="Send" />
      <p>Note: If you get a server-side error, please allow some seconds for the API to awaken.</p>
      </form>
    </div>
  </body>
</html>

There is of course some CSS working behind the scenes to make this webpage look a bit fancier than plain HTML - that part is completely optional and how to implement it is up to your imagination and creativity.

The final and most crucial part of the frontend is a javascript file. I wrote a simple JS script that takes the information submitted from the form and sends it to the API. The script then processes the API's response and appends it to the HTML page at the bottom, displaying a "Message sent successfully!" notice or an appropriate error message. The entire script itself is ~30 lines:

document.addEventListener('DOMContentLoaded', () => {

    let messageForm = document.getElementById('messageForm')
    let response = document.createElement('p')
    messageForm.append(response)

    //form submit
    messageForm.addEventListener('submit', () => {
      event.preventDefault()

      configObj = {
          method: "POST",
          headers: {
              "Content-Type": "application/json"
          },
          body: JSON.stringify({
              "body": event.target.author,
              "author": event.target.body
          })
        }
      fetch('<api_post_messages_url>', configObj)
      .then(res => res.json())
      .catch((err) => {
        response.innerText = 'Server-side error: ' + err.message
      })
      .then(json => {
        response.innerText = json['status']
        })
      messageForm.reset()
    })
  }
)

*Note: the entire script is encapsulated inside a 'DOMContentLoaded' event listener. This is because when a webpage is accessed, we need to wait for all the HTML elements to load first before trying to use them or modify them with JavaScript.

Part 3: The Answering Machine Script

With the backend, the API, and the frontend complete, this project was almost finished. Now I just needed to create a simple script that would access the API with all the messages, read them out to me, and then promptly delete them. I wrote this script in Ruby, although it can be coded in pretty much any language with HTTP functionality.

First, I imported the HTTParty gem to make requests to the API and the TTS gem to have easy to use text-to-speech functionality. With the help of these gems, writing the actual script to get the messages and read them out to me was simple.

After the imports, I wrote a function read_messages. This function sends a get request to the API in order to see all the messages that had been sent there. Then, it gets the content of each message and wraps it nicely in a formatted string. Finally, the function uses the TTS gem to read the formatted string and then promptly sends a request to delete the message off of the API, so that it's not read again:

require 'httparty'
require 'tts'

def read_messages
    response = HTTParty.get('<api_get_messages_url>')

    response.each do |message|
        #create message string
        to_read = ''
        if message['author'] == ''
            to_read = "You have a message: " + message['body']
        else
            to_read = "You have a message from #{message['author']}: " + message['body']
        end

        #read message string out loud
        to_read.play('en', 1)

        #delete message that was just read from API
        HTTParty.delete("<api_get_messages_url>#{message['id']}")
    end
end

Finally, I wrapped the function in an infinite while loop so it is always running while the script is executing:

while true do
    read_messages()
end

*Note: in case you don't want to delete the messages, an alternative is to have a read boolean that can be set to false once a message is read out loud by the script, using a patch request rather than a delete request.

And there you go! Now each time the script is running, I am able to instantly hear any messages that have been previously sent to the API or that are being sent in real-time.

The very final thing I did was to make the script an executable file so that I wouldn't have to type ruby <script_name.rb> into the terminal each time I wanted to run my answering machine.

The process to make any code file executable on MacOS by simply clicking on it is the following:

Use the terminal to navigate into the directory where the script is located.
Type chmod a+x <script_name.file_extension> - this gives you permission to execute the file.
Add the line #!/usr/bin/env <programming_language_name> to the top of your script file - this tells your computer what language the script is in.
Create a shell script like so:

#!/bin/sh
cd <script_directory>
echo Running script
./<script_name.file_extension>

Finally, change the shell script's file extension to .command.

I made a shortcut to the .command file on my desktop, and voilà! Now every time I open up my laptop, I can press that shortcut and instantly hear all the random messages my friends sent me since I last checked! Just like the good ol' days of answering machines...

Conclusion

I hope this post has provided you with some insight into how most web applications we use work behind the scenes. Whether it be a simple answering machine or a complex application like Facebook, the core ideas of how these systems work are all the same.

How I Made a Simple Snake Game with Ruby 2D

JoaoCardoso193 — Thu, 16 Jul 2020 16:53:28 +0000

Snake

Everybody loves Snake. Although the original concept of the game dates back to 1976, this classic game won many hearts when it came preloaded on Nokia phones since 1998. I have many fond childhood memories of playing this classic game on my mom's phone, and I'm sure I'm not the only one whose childhood was bettered by this simple yet brilliant piece of entertainment.

Making Snake

When I decided I wanted to make a Snake game in Ruby, I searched the internet for many tutorials to get me started. By far the best tutorial I found was this one by Mario Visic on Youtube. All credit for this blog post goes to him, I simply followed his method and incorporated a few more things.

In order to re-create this classic game in Ruby, we need the help of Ruby 2D, a wonderful gem which allows you to draw visualizations for your Ruby programs with ease. This gem has a lot of functionality to really bring your programs to life, so it's a no-brainer when it comes to making 2D games in Ruby. Additionally, it has a quite comprehensive and very user-friendly documentation. To install this gem, simply run gem install ruby2d, and then add require 'ruby2d' at the top of your Ruby file.

The Initial Set-Up

Once Ruby 2d is installed and required, we have to set a background color, fps_cap (this determines how many frames the game will render per second), and grid size (this determines how many pixels wide each square on the grid will be):

require 'ruby2d'

set background: 'navy'
set fps_cap: 20

GRID_SIZE = 20 #grid size is 20 pixels

#for default window size of 480px * 640px, width is 32 (640/20) and height is 24 (480/20) at grid size = 20 pixels
GRID_WIDTH = Window.width / GRID_SIZE
GRID_HEIGHT = Window.height / GRID_SIZE

These values can be changed if you desire a different grid size, a different background color, or a different game speed.

The Snake Class

All of the logic for the snake itself was encapsulated inside the snake class:

class Snake

    attr_writer :direction
    attr_reader :positions

    def initialize
        @positions = [[2, 0], [2,1], [2,2], [2,3]] #first coordinate is x and the second is y, starting from top left corner
        @direction = 'down'
        @growing = false
    end

    def draw
        @positions.each do |position|
            Square.new(x: position[0] * GRID_SIZE, y: position[1] * GRID_SIZE, size: GRID_SIZE - 1, color: 'olive')
        end
    end

    def move
        if !@growing
            @positions.shift
        end

        case @direction
        when 'down'
            @positions.push(new_coords(head[0], head[1] + 1))
        when 'up'
            @positions.push(new_coords(head[0], head[1] - 1))
        when 'left'
            @positions.push(new_coords(head[0] - 1, head[1]))
        when 'right'
            @positions.push(new_coords(head[0] + 1, head[1]))
        end
        @growing = false
    end

    #Preventing snake from moving backwards into itself
    def can_change_direction_to?(new_direction)
        case @direction
        when 'up' then new_direction != 'down'
        when 'down' then new_direction != 'up'
        when 'left' then new_direction != 'right'
        when 'right' then new_direction != 'left'
        end
    end

    def x
        head[0]
    end

    def y
        head[1]
    end

    def grow
        @growing = true
    end

    def snake_hit_itself?
        @positions.uniq.length != @positions.length #this checks if there are any duplicate positions in the snake (self-collision)
    end

    private

    #This method uses the modulus operator to make the
    #snake appear on the other side of the screen when it goes over the edge
    def new_coords(x,y)
        [x % GRID_WIDTH, y % GRID_HEIGHT]
    end

    def head
        @positions.last
    end

end

Here, the snake is initialized as 4 squares on the top left corner of the window, heading downwards, and not growing. This is how the snake will appear every time the game is started.

The draw method is used to convert the snake's @positions array to actual squares on the grid, using Ruby 2D's Square method.

The move method moves the snake on the screen by using .shift on the array of positions the snake occupies, which removes the first element of the array (which actually corresponds to the snake's tail, or last square). After the snake's tail is removed, .push (which appends to the end of the array, corresponding to the snake's head) is called to redraw the snake's head 1 square away in the direction of movement. The position of the snake's head can be accessed by calling on the head helper method. The redrawing of the snake's head also uses another helper method, .new_coords, which makes the snake reappear on the other side of the screen if it goes over the edge. This encompasses pretty much all of the snake's basic movement.

The way in which the direction of movement is determined will become apparent later on in the code, but for now a can_change_direction_to? method is required to prevent the snake from going backwards into itself.

Then, two simple x and y methods are require to simply return the coordinates of the snake's head (these will be needed later). A simple grow method is also required to set the snake's @growing condition to true. This will be triggered when the snake eats food and then @growing will be set to false again after the snake moves.

Finally, a snake_hit_itself? method is required to check if the snake has crashed into itself, which will finish the game. This is done quite cleverly by just checking if the @positions array has any duplicate coordinates, meaning that the snake has crashed into itself. If this is the case, the length of @positions and @positions.uniq will be different (.uniq removes any duplicates), and the method will return true.

*If you want to test the game so far, skip ahead to the the Game Loop and Key-Mapping sections, so you can run and interact with the game before proceeding to the next section. If you skip ahead, make sure to not include any references to the Game class or game instance anywhere as the Game class hasn't been defined yet.

The Game Class

Now, it's time to make the class that will encompass all of the game's mechanics:

class Game
    def initialize(snake)
        @snake = snake
        @score = 0
        initial_coords = draw_ball
        @ball_x = initial_coords[0]
        @ball_y = initial_coords[1]
        @finished = false
        @paused = false
    end

    def draw_ball

        available_coords = []
        for x in (0..GRID_WIDTH-1)
            for y in (0..GRID_HEIGHT-1)
                available_coords.append([x, y])
            end
        end

        selected = available_coords.select{|coord| @snake.positions.include?(coord) == false}
        selected.sample

    end

    def draw
        unless finished?
            Square.new(x: @ball_x * GRID_SIZE, y: @ball_y * GRID_SIZE, size: GRID_SIZE, color: 'yellow')
        end
        Text.new(text_message, color: 'white', x: 10, y: 10, size: 25)
    end

    def snake_hit_ball?(x, y)
        @ball_x == x && @ball_y == y
    end

    def record_hit
        @score += 1
        ball_coords = draw_ball
        @ball_x = ball_coords[0]
        @ball_y = ball_coords[1]
    end

    def finish
        @finished = true
    end

    def finished?
        @finished
    end

    def pause
        @paused = true
    end

    def unpause
        @paused = false
    end

    def paused?
        @paused
    end



    private

    def text_message
        if finished?
            "Game over, score: #{@score}. Press 'R' to restart, 'Q' to quit."
        elsif paused?
            "Game paused, score: #{@score}. Press 'P' to resume."
        else
            "Score: #{@score}"
        end
    end

end

Here, the game is initialized with a score of 0, and the @finished and @paused conditions set to false. My code differs a bit from the video tutorial I followed in the way in which the ball (food) is drawn, as it calls on a helper method draw_ball.

I wrote this helper method to check that the ball isn't drawn inside the snake. In order to do this, this helper method requires access to the snake's position, so I initialized the Game class with an instance of the Snake class. With access to the snake's position, draw_ball finds the available coordinates to draw the ball in by selecting all the coordinates on the grid which are not currently being occupied by the snake. Then, this method selects a random sample from all those available coordinates and returns it. Props to my instructor Sylwia Vargas for helping me debug my old method which wasn't working!

draw, again, converts the ball's position array to actual squares on the grid and it also draws a text message on the top left to display information, as long as the game isn't finished. This text message itself is delegated to a helper method text_message. This helper method displays the current score and information about the game's state, changing accordingly if the game is paused or finished.

The snake_hit_ball? method just checks if the snake has come into contact with the ball. This will be called in the game loop later.

The record_hit method adds 1 point to the score and redraws the ball every time it's called.

Finally, the finish, finished?, pause, unpase and paused? methods set and return the game's state accordingly.

The Game Loop

Now, with our main classes finished, it's time to put them to use inside our game loop, which will run every new frame:

update do
    clear

    unless game.finished? or game.paused?
        snake.move
    end
    snake.draw
    game.draw

    if game.snake_hit_ball?(snake.x, snake.y)
        game.record_hit
        snake.grow
    end

    if snake.snake_hit_itself?
        game.finish
    end
end

Every frame, this loop starts by clearing the screen, moving the snake (unless the game is paused or finished), redrawing the snake, and redrawing the rest of the game.

Then, the loop checks if the snake has hit the ball, and if so it records a hit and makes the snake grow accordingly.

Finally, the loop checks if the snake has hit itself, in which case it finishes the game.

Key-Mapping

Our game is looking great so far, but it can't really be interacted with without key-mappings, so let's add that. The main key-mappings will allow us to control the snake's direction as well as pause, reset, and quit the game.

on :key_down do |event|
    if ['up', 'down', 'left', 'right'].include?(event.key)
        if snake.can_change_direction_to?(event.key)
            snake.direction = event.key
        end
    elsif event.key == 'r' or event.key == 'R' #resetting game
        snake = Snake.new
        game = Game.new(snake)
    elsif event.key == 'q' or event.key == 'Q' #quitting game
        exit()
    elsif event.key == 'p' or event.key == 'P' #pausing/unpausing game
        if game.paused?
            game.unpause
        else
            game.pause
        end
    end

end

show

We start with an event-listener which will detect whenever a key is pressed. Then, we check the key pressed against multiple conditions.

If the key was 'up', 'down', 'left', or, 'right', change the snake's direction accordingly, as long as that's allowed by snake.can_change_direction_to?.

If the key was 'r', 'q', or 'p', reset, quit, or pause/unpause the game accordingly.

Finally, we call show to actually render the game's window. This is the very last line in our code as everything else about the game must be executed first before displaying.

Exporting the Game

Congrats! If you've made this far your game should be working perfectly whenever it's run in the terminal.

Although the game is looking great, it's a bit of a hassle to have to open up the terminal and run ruby snake.rb every time we want to play it. So let's fix that.

On MacOS:

Run brew install mruby, brew tap simple2d/tap, and brew install simple2d in the terminal.
In the same directory as your Ruby file for the game, run ruby2d build --macos <your_game_file_name.rb>.

On Linux:

Run sudo apt install mruby libmruby-dev in the terminal.
In the same directory as your Ruby file for the game, run ruby2d build --native <your_game_file_name.rb>

These steps will generate a build directory with your game inside.

Congrats! Now you can enjoy this great classic game by simply pressing on the executable file in the new folder.

My First Bot 🤖

JoaoCardoso193 — Thu, 25 Jun 2020 05:07:24 +0000

A Short Intro on Bots

During my time on the internet, I've become increasingly fascinated by so called "bots" on social media. According to Wikipedia, a bot is a software application that runs automated tasks (scripts) over the internet. Together, bots are responsible for more than half of all web traffic today.

There are many types of bots that can perform all sorts of useful tasks, but by far my favorite bots are those which serve a comedic purpose, as they always brighten up my social media feeds. To see what I mean, take this post from Bots of New York, a parody of the famous Humans of New York Facebook page that uses Machine Learning to generate a human face and a caption based off the content of the original page:

The somewhat random nature of the algorithm used to generate these captions often leads to hilarious results, such as a mother being happy that her newborn baby was able to provide for her right at birth. Other bots I follow include Every Spongebob Frame in Order and News Bot.

To me there's something really comical about the endless possibilities of unsupervised AI-generated content, and so I decided that my time had come: it was time to make my first bot.

I found a great tutorial to help me get started and I was ready to start contributing to the world of social media bots.

Part 1: Twitter Set-up

Following the tutorial I found, my bot was going to be hosted on Twitter and would be written in the Ruby programming language.

In order to be able to host a bot on Twitter, I first needed to apply for a Twitter developer account. The process was actually pretty simple, I just had to fill out a simple form and I was set!

After my account was approved, I had to apply for a new Twitter app. All I had to do was make sure my bot wouldn't break any rules and then fill out another simple form.

After my app was approved (pretty much instantly), I could finally get the API keys and access tokens I'd need to connect my bot to Twitter. These can be found on your app's dashboard, under "Keys and Tokens". Make sure to keep these keys private as anyone with them can easily access your bot.

Part 2: Making the Bot

After opening up VSCode, the first step to setting up my bot was to connect it to the twitter client using the API keys and access tokens. After installing and requiring the Twitter gem, the process was pretty simple:

#Connecting to Twitter App
client = Twitter::REST::Client.new do |config|
        config.consumer_key = "API key goes here"
        config.consumer_secret = "API secret key goes here"
        config.access_token = "Access token goes here"
        config.access_token_secret = "Access token secret goes here"
end

Now that this was done, it was time to write the logic for what the bot would do. Inspired by the erratic and often hilarious captions of Bots of New York, I decided that my bot would tweet out random sentences with a random hashtag. Generating random text that is somewhat coherent and grammatically correct is no easy task, but luckily someone had already developed a gem for Ruby to do just that. This gem, called Literate Randomizer takes advantage of Markov chains to generate random text based off of another source text. I decided that for now, I'd leave the source text as the default: Arthur Doyle's 1912 sci-fi novel The Lost World.

Armed with the power of Literate Randomizer, making my bot's tweets was really simple:

#tweets random sentence with random hashtag when app is called
tweet = LiterateRandomizer.sentence + " #" + LiterateRandomizer.word
client.update(tweet)
puts "\nNew tweet at #{Time.now.strftime('%H:%M')}: '#{tweet}'" #print tweet time and content to terminal
end

The client.update(tweet) statement is what actually prompts the bot to post to Twitter, and the following line is for printing the tweet content to the terminal for my own reference.

With only a few lines of code, my bot came to life. Initially, I put the previous code inside an infinite while true block, that would post a tweet every few minutes using a sleep statement:

    while true do
        tweet = LiterateRandomizer.sentence + " #" + LiterateRandomizer.word
        client.update(tweet)
        puts "\nNew tweet at #{Time.now.strftime('%H:%M')}: '#{tweet}'" #print tweet time and content to terminal
        sleep(3600) #sleep for 3600 seconds, or 30 minutes
    end

Immediately, my bot was producing some great content:

RubyBot

@rubybot10

Filthy vermin I don't think. #if

03:35 AM - 24 Jun 2020

0 0

RubyBot

@rubybot10

Quick young fellah I don't mean my adventures. #slaughter

04:00 AM - 24 Jun 2020

0 0

RubyBot

@rubybot10

Mental inertia. #perch

05:03 AM - 24 Jun 2020

1 0

RubyBot

@rubybot10

INDEMNITY You enlarge my business with a fashion and I propose to hand. #butt

18:15 PM - 24 Jun 2020

0 0

Part 3: Making a Script

I was happy with what my bot was producing, but could it really be considered a bot if every time I wanted to run it I'd have to navigate to its folder and call it from the terminal?

In order to make my bot more automated, I decided I'd write a script that would start the bot whenever I logged into my computer. Unexpectedly, due to having no previous experience with scripts, this was actually the part that took me the longest time to figure out.

The first solution I found was to write a simple sh script that would navigate to my bot's directory, and call it:

#!/bin/sh
cd ~/Documents/Flatiron/RubyBot
echo Running RubyBot
./RubyBot.rb

In order to make my bot executable with the ./RubyBot.rb commmand, I first had to make my Ruby file executable using chmod a+x RobyBot.rb in the terminal, and I had to add #!/usr/bin/env ruby to the top of my bot's Ruby file (this lets the terminal know to execute the file with Ruby). Finally, I renamed my sh script to end with the .command file extension, because otherwise my computer would just open up the script itself on execution, rather than run it. Once this was all done, I went into my System Preferences > Users&Groups > Login Items, and added my RubyBot.command file to the list of items that get executed upon log in.

This worked! Every time I restarted my computer and logged in, the script would run and start my bot.

I could have been satisfied with this, however there were some details that were bugging me: my bot was programmed to post a tweet every 30 minutes, but if I logged in to my computer at say, 10:07, this meant that my bot would post at 10:07, 10:37, 11:07, etc. Additionally, if my computer went to sleep or if I accidentally closed the terminal window running the bot, this would stop the bot and mess up the posting times even further upon restarting it.

I wanted to prepare for the future, and in case my bot one day garnered a massive following online, I wanted to know that my fans could expect a post from my bot at exactly the :00 and :30 minute marks every hour. After all, with all the uncertainty in the world right now, it definitely wouldn't hurt if my bot could provide its fans with the reassurance that it would post a tweet at exactly the beginning and middle point of every hour.

In order to do this, I got rid of the infinite while true block in my bot's code, making it so that my bot would only post a tweet when called. Then, I had to think of a way to externally "call" my bot every 30 minutes instead of just always leaving the terminal window running it open. My solution was the following: I would use my computer's Calendar app to set an event every 30 minutes that would trigger a call to my bot.

In order to do so, I decided to write a simple Automator app that would simply call my already-written RubyBot.command script:

This step was perhaps unnecessary, but I figured that if I was going to be using Apple's proprietary calendar to trigger my bot, I should connect it to an Apple proprietary app in order to minimize the risk of any issues.

After saving my custom Automator app, I opened up my computer's Calendar app, and made an event for each 30-minute slot in a day, setting these events to repeat daily. While making these events, I set a custom alert to open up my custom app for every event:

This was a bit of a tedious process, but it worked:

My calendar was filled with daily events every 30 minutes, and sure enough, at exactly the :00 and :30 minute marks of every hour, my calendar would trigger my custom Automation app, that would trigger my shell script, that would trigger my bot to post a random sentence on Twitter. Worth it!

Conclusions

Although my bot itself was definitely quite simplistic, this exercise served as a great experience on how to connect code to an external API, such as Twitter's API, in order to perform an automated task. It also served as a great exercise in shell scripting (which I had never done before).

I thoroughly enjoyed making my first bot, and I'm already brimming with ideas for other more complex bots I could make, now that I already know how to set it all up.

In the meantime, make sure to follow RubyBot on Twitter!

P.S. In retrospect, an easier alternative solution to have my bot post at exactly the :00 and :30 minute marks would be to just add an if Time.now.min == 0 || Time.now.min == 30 statement before posting, like so:

        if Time.now.min == 0 || Time.now.min == 30
            tweet = LiterateRandomizer.sentence + " #" + LiterateRandomizer.word
            client.update(tweet)
            puts "\nNew tweet at #{Time.now.strftime('%H:%M')}: '#{tweet}'" #print tweet time and content to terminal
        end