Ruby
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Methods and Blocks
-
Section 4: Object-Oriented Ruby
-
Section 5: Metaprogramming
-
Section 6: Working with Data and Files
-
Section 7: Ruby Frameworks Overview
-
Section 8: Ecosystem and Testing
-
Section 9: Practical Projects
-
Section 10: Interview Practice
-
Section 11: Data Structures and Algorithms in Ruby
-
Section 12: More Practice Exercises
-
Section 13: Enumerable and Functional Style
-
Section 14: More OOP Practice
-
Section 15: More Testing
-
Section 16: Enumerable and Comparable Modules In Depth
-
Section 17: Ruby Standard Library: Core Utilities
-
Section 18: Ruby Standard Library: Data and Security
-
Section 19: Ruby Standard Library: CLI and Text
-
Section 20: Ruby Networking
-
Section 21: Ruby on Rails Deep Dive
-
Section 22: Ruby Metaprogramming Deep Dive
-
Section 23: Ruby Design Patterns
-
Section 24: Ruby Concurrency
-
Section 25: Ruby Testing Deep Dive
-
Section 26: Ruby Gems and Packaging
-
Section 27: Ruby Performance
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Rails API Development
-
Section 31: Rails Authentication and Authorization
-
Section 32: Rails Testing Deep Dive
-
Section 33: Rails Performance
-
Section 34: Rails Deployment
-
Section 35: Sinatra and Lightweight Ruby Web Apps
-
Section 36: More Ruby Language Deep Dive
-
Section 37: Ruby 3.x Modern Features
-
Section 38: More Data Structures in Ruby
-
Section 39: More Practical Projects
-
Section 40: Ruby Ecosystem Tools
-
Section 41: More Practice and Review
-
Section 42: Final Practice and Mastery
-
Section 43: Ruby Interview Deep Dive
-
Section 44: Ruby Background Processing Deep Dive
-
Section 45: Ruby GraphQL
-
Section 46: Ruby Object Model Deep Dive
-
Section 47: Ruby Hanami Framework Overview
-
Section 48: Ruby gRPC and Protocol Buffers
-
Section 49: Ruby Data Processing
-
Section 50: Ruby Search Integration
-
Section 51: Ruby File Upload and Media
-
Section 52: Ruby Email and Notifications
-
Section 53: Ruby Admin Panels
-
Section 54: Ruby Feature Flags and Experimentation
-
Section 55: Ruby Monitoring and Observability
-
Section 56: Ruby Docker and Deployment Deep Dive
-
Section 57: Ruby Security Deep Dive
-
Section 58: More Advanced Metaprogramming
-
Section 59: More Final Projects
44: Practice Exercise: Building a Simple Todo List Gem
Where do the files actually go so this works as a gem?
If you've only written scripts so far, the directory structure of a gem can feel like overkill. But there's a reason for it. Ruby expects a specific layout so that when someone runs require 'your_gem_name', it knows exactly where to look. For our todo list, you want a lib/ directory. Inside that, you create a folder named after your gem, and inside that, a file also named after your gem.
It looks like this: lib/todo_manager/todo_manager.rb. I know it feels redundant to name everything the same thing, but trust me, it prevents naming collisions when your gem is installed alongside a hundred others. You'll also need a .gemspec file in the root. That's the "ID card" for your gem—it tells Ruby the version, the author, and which files are included. Don't forget to actually require your logic files inside that main todo_manager.rb entry point, otherwise, the user will load the gem and find... absolutely nothing.
Should I put the CLI logic and the Todo logic in the same class?
Definitely not. This is where a lot of people trip up. If you mix your puts statements and gets.chomp calls inside your core logic, you've just made your gem impossible to use as a library. What if someone wants to use your TodoManager inside a Rails app or a Discord bot later? They can't, because your code will keep trying to ask for terminal input.
Keep a clean split. Create a Task class and a List class for the data, and a separate CLI class for the interface. Here is how I'd sketch that separation:
# lib/todo_manager/list.rb
class TodoManager::List
def initialize
@items = []
end
def add(task_name)
@items << { name: task_name, done: false }
end
end
# lib/todo_manager/cli.rb
class TodoManager::CLI
def run
puts "Welcome to your Todo List!"
# All the puts/gets logic goes here, calling the List class
end
end
How do I make it an actual command I can run from my terminal?
You don't want to type ruby -Ilib bin/todo every time you want to add a task. To make it a real command, you need a bin/ directory. Create a file in there—let's call it todo (no extension)—and start it with a "shebang" line. This tells your shell to use Ruby to execute the file.
Your bin/todo file should look like this:
#!/usr/bin/env ruby
require 'todo_manager'
TodoManager::CLI.new.run
One pro tip: make that file executable by running chmod +x bin/todo in your terminal. Now, as long as you're in the project root, you can just run ./bin/todo and it feels like a real piece of software.
What's the best way to save the list to a file without overcomplicating it?
Since this is a simple gem, don't bother with a database like SQLite. It's too much overhead for a practice exercise. Just use JSON. It's built into Ruby, it's human-readable, and it maps perfectly to the arrays and hashes you're already using for your tasks.
I usually suggest creating a storage.rb module or just adding a save and load method to your List class. Use File.write and JSON.dump to push your data to a hidden file in the user's home directory (like ~/.todo_list.json). This ensures that the list persists even after the program exits, which is the whole point of a todo app, right?
📋 Practical Task
Build the Persistent Todo CLI Gem
Your task is to build a functional Ruby gem called todo_manager. Your gem must meet the following technical requirements:
- Structure: Follow the standard gem layout (
lib/todo_manager/and abin/directory). - Separation of Concerns: Create a
Listclass to handle adding/removing tasks and aCLIclass to handle user input and output. - Persistence: Implement a save/load system using the
jsonstandard library so that tasks are remembered between sessions. - Executable: Create a
bin/todofile with the correct shebang that launches the CLI. - Functionality: The user should be able to:
- Add a new task.
- List all current tasks.
- Mark a task as completed.
- Exit the program.
Test your gem by running it via ./bin/todo and verifying that your tasks are still there after you restart the application.
There are no comments for now.