Bird
Raised Fist0
Ruby on Railsframework~10 mins

Job creation and queuing in Ruby on Rails - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a basic Active Job class.

Ruby on Rails
class MyJob < ApplicationJob
  queue_as :[1]

  def perform(*args)
    # job code here
  end
end
Drag options to blanks, or click blank then click option'
Aurgent
Bmain
Cbackground
Ddefault
Attempts:
3 left
💡 Hint
Common Mistakes
Using a queue name that is not defined in the system
Forgetting to set a queue name
2fill in blank
medium

Complete the code to enqueue a job to run asynchronously.

Ruby on Rails
MyJob.[1](user_id)
Drag options to blanks, or click blank then click option'
Aperform_later
Bperform_now
Cenqueue
Drun_async
Attempts:
3 left
💡 Hint
Common Mistakes
Using perform_now which runs the job immediately
Using non-existent methods like run_async
3fill in blank
hard

Fix the error in the job class to correctly access the argument.

Ruby on Rails
class NotifyUserJob < ApplicationJob
  def perform([1])
    UserMailer.welcome_email([1]).deliver_now
  end
end
Drag options to blanks, or click blank then click option'
Aparams
Bargs
Cuser_id
Duser
Attempts:
3 left
💡 Hint
Common Mistakes
Using a generic name like args without unpacking
Using user when only the ID is passed
4fill in blank
hard

Fill both blanks to schedule a job to run 5 minutes from now.

Ruby on Rails
MyJob.[1](wait: [2].minutes).perform_later
Drag options to blanks, or click blank then click option'
Aset
Bperform_later
C5
D10
Attempts:
3 left
💡 Hint
Common Mistakes
Using perform_later without set for scheduling
Using wrong wait time values
5fill in blank
hard

Fill all three blanks to create a job that retries 3 times with 10 seconds delay between attempts.

Ruby on Rails
class RetryJob < ApplicationJob
  [1] StandardError, wait: [2], attempts: [3]

  def perform
    # job code
  end
end
Drag options to blanks, or click blank then click option'
Aretry_on
B10.seconds
C3
Drescue_from
Attempts:
3 left
💡 Hint
Common Mistakes
Using rescue_from which handles exceptions differently
Not specifying wait time or attempts correctly

Practice

(1/5)
1. What is the main purpose of creating a job in Rails using ApplicationJob?
easy
A. To run tasks in the background without blocking the main app flow
B. To create database tables automatically
C. To handle user authentication
D. To style the user interface

Solution

  1. Step 1: Understand the role of jobs in Rails

    Jobs are designed to run tasks asynchronously, so they don't slow down the main app.
  2. Step 2: Identify the correct purpose

    Running tasks in the background matches the job's purpose, unlike database creation or UI styling.
  3. Final Answer:

    To run tasks in the background without blocking the main app flow -> Option A
  4. Quick Check:

    Jobs = background tasks [OK]
Hint: Jobs run tasks later to keep app fast [OK]
Common Mistakes:
  • Thinking jobs create database tables
  • Confusing jobs with UI styling
  • Assuming jobs handle user login
2. Which of the following is the correct way to enqueue a job named SendEmailJob to run later?
easy
A. SendEmailJob.perform_later
B. SendEmailJob.run_later
C. SendEmailJob.enqueue
D. SendEmailJob.perform_now

Solution

  1. Step 1: Recall the method to queue jobs in Rails

    The method perform_later adds the job to the queue for later execution.
  2. Step 2: Compare options

    perform_now runs immediately, enqueue and run_later are not valid Rails job methods.
  3. Final Answer:

    SendEmailJob.perform_later -> Option A
  4. Quick Check:

    Use perform_later to queue jobs [OK]
Hint: Use perform_later to queue jobs [OK]
Common Mistakes:
  • Using perform_now instead of perform_later
  • Using non-existent methods like enqueue or run_later
  • Confusing immediate execution with queuing
3. Given this job definition:
class CleanupJob < ApplicationJob
  def perform
    puts 'Cleaning up!'
  end
end

What will happen when you call CleanupJob.perform_later?
medium
A. Prints 'Cleaning up!' immediately
B. Adds the job to the queue and prints 'Cleaning up!' later
C. Raises an error because perform_later is undefined
D. Does nothing because perform is empty

Solution

  1. Step 1: Understand perform_later behavior

    Calling perform_later queues the job to run asynchronously later, not immediately.
  2. Step 2: Check the perform method

    The perform method prints 'Cleaning up!' when the job runs, so this will happen later after queuing.
  3. Final Answer:

    Adds the job to the queue and prints 'Cleaning up!' later -> Option B
  4. Quick Check:

    perform_later queues job, runs perform later [OK]
Hint: perform_later queues job, runs perform method later [OK]
Common Mistakes:
  • Thinking perform_later runs perform immediately
  • Assuming perform_later is undefined
  • Believing perform method is empty and does nothing
4. Identify the error in this job code:
class NotifyUserJob < ApplicationJob
  def perform(user_id)
    User.find(user_id).notify
  end
end

NotifyUserJob.perform_later
medium
A. Cannot inherit from ApplicationJob
B. Wrong method name; should be perform_now
C. User model does not exist
D. Missing argument when calling perform_later

Solution

  1. Step 1: Check perform method parameters

    The perform method requires one argument: user_id.
  2. Step 2: Check perform_later call

    Calling perform_later without arguments causes an error because user_id is missing.
  3. Final Answer:

    Missing argument when calling perform_later -> Option D
  4. Quick Check:

    perform_later needs all perform arguments [OK]
Hint: Always pass perform arguments to perform_later [OK]
Common Mistakes:
  • Calling perform_later without required arguments
  • Confusing perform_later with perform_now
  • Assuming inheritance from ApplicationJob is invalid
5. You want to create a job that sends a welcome email only if the user has verified their email. Which is the best way to implement this in perform?
hard
A. Raise an error if user is not verified inside perform
B. Send email unconditionally in perform and handle verification elsewhere
C. Check user.verified? inside perform and send email only if true
D. Call perform_now instead of perform_later

Solution

  1. Step 1: Understand conditional logic in jobs

    Jobs can include logic to decide whether to perform actions, like checking if user is verified.
  2. Step 2: Evaluate options

    Check user.verified? inside perform and send email only if true correctly checks verification inside perform before sending email, ensuring only verified users get emails.
  3. Final Answer:

    Check user.verified? inside perform and send email only if true -> Option C
  4. Quick Check:

    Use condition inside perform for selective job actions [OK]
Hint: Put conditions inside perform to control job actions [OK]
Common Mistakes:
  • Sending emails without checking verification
  • Raising errors unnecessarily in perform
  • Confusing perform_now with perform_later
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard