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
63: The Set Class
I see this all the time in code reviews from developers who are new to Ruby: they need a collection of unique items, so they use an Array and simply call .uniq whenever they need to clean it up, or they wrap every single insertion in an unless array.include?(item) block. It feels intuitive because you're already comfortable with Arrays, but it's a performance landmine.
The "Just Use Array#uniq" Trap
Let's look at why that approach fails as your data grows. Imagine you're processing a log file with 100,000 lines to find every unique IP address that visited your site.
# The "Naive" Way
unique_ips = []
log_entries.each do |ip|
unique_ips << ip unless unique_ips.include?(ip)
end
The problem here is that include? is a linear search. For every single IP in your log, Ruby has to scan the unique_ips array from the beginning until it finds a match or hits the end. If you have 100,000 entries, you're potentially doing billions of comparisons. Your program will crawl to a halt, and you'll be wondering why your CPU is screaming.
Leveraging the Hash-backed Speed of Set
This is exactly why the Set class exists. A Set is essentially a wrapper around a Hash where the elements you add become the keys of the hash, and the values are just ignored. Because Hash lookups are (effectively) instant regardless of the size of the collection, checking for existence or adding a new element happens in constant time.
First, a quick heads-up: Set is part of the standard library, but not the core, so you have to explicitly require it.
require 'set'
unique_ips = Set.new
log_entries.each do |ip|
unique_ips.add(ip) # No need to check if it exists first!
end
In this version, adding an IP that's already there does nothing, and adding a new one is incredibly fast. I personally use Sets whenever I'm dealing with "membership" logic—basically any time the question is "Is this thing in the group?" rather than "What is the third item in the list?"
Performing Set Mathematics
Beyond just uniqueness, the Set class gives you powerful tools for comparing collections that would be clunky to write with Arrays. These are based on mathematical set theory, and once they click, they make your code much more expressive.
Consider two sets of user IDs: those who have a "Premium" subscription and those who have "Logged In" today.
premium_users = Set[1, 2, 3, 4, 5]
active_users = Set[4, 5, 6, 7, 8]
# Intersection: Who is both premium AND active?
premium_and_active = premium_users & active_users
# => #<Set: {4, 5}>
# Union: Who is either premium OR active (or both)?
all_relevant_users = premium_users | active_users
# => #<Set: {1, 2, 3, 4, 5, 6, 7, 8}>
# Difference: Who is premium but HASN'T logged in today?
inactive_premium = premium_users - active_users
# => #<Set: {1, 2, 3}>
Using &, |, and - is far more readable than nesting select and reject blocks. Just remember that these operations return a new Set, leaving the originals untouched.
📋 Practical Task
Filtering Banned Users from a Mailing List
You are building a system to send a newsletter. You have a Set of all subscribed email addresses and a Set of emails that have been flagged as "banned" or "spam."
Your task:
- Create a
Setcalledsubscriberscontaining:"alice@example.com","bob@example.com","charlie@example.com", and"dan@example.com". - Create a
Setcalledbanned_emailscontaining:"bob@example.com"and"eve@example.com". - Use a set operation to create a third set,
final_mailing_list, which contains only the subscribers who are NOT banned. - Print the
final_mailing_listto the console.
Hint: Remember to require 'set' at the top of your script!
There are no comments for now.