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
218: Building an Admin Panel with ActiveAdmin
Imagine you've just opened a high-end boutique. To your customers, the store looks pristine—curated displays, soft lighting, and a seamless checkout process. That's your public-facing Rails application. But behind the velvet curtain, you have a "back office." The back office isn't pretty; it's where the messy work happens. It's where you track inventory, change prices on the fly, manage supplier contacts, and occasionally delete a glitchy order. You don't want your customers seeing the spreadsheets and shipping labels, but you can't run the business without them.
ActiveAdmin is essentially that back office for your Ruby on Rails app. Instead of you spending three days building custom controllers and views just so your non-technical teammate can edit a product description, ActiveAdmin gives you a fully functional administrative interface almost instantly. It maps your database models directly to a set of CRUD (Create, Read, Update, Delete) pages.
Turning Models into Management Pages
Once you've got the gem installed and the initial setup run, the magic happens in the app/admin directory. If you have a Product model in your e-commerce app, you don't write a ProductsController for the admin side. Instead, you register the model. I've found that the beauty of this approach is that it keeps your "business logic" (the public site) completely separate from your "management logic."
ActiveAdmin.register Product do
permit :name, :price, :description, :stock_quantity
end
With those few lines, you now have a URL (usually /admin/products) that lets you list every product, create new ones, and delete old ones. The permit method is crucial here—it's just Rails' Strong Parameters wrapped in ActiveAdmin's syntax. If you forget to permit a field, you'll be staring at a "failed to save" error and wondering why your database is ignoring you.
Curating the Inventory List
By default, ActiveAdmin shows every single column in your database table on the index page. If your Product model has 20 columns, including created_at and updated_at, the page becomes a cluttered mess. I usually prefer to be intentional about what the admin actually needs to see at a glance.
You can use the index block to define exactly which columns appear and how they are labeled. I'm a big fan of using as: :boolean or as: :currency to make the data readable for humans, not just machines.
ActiveAdmin.register Product do
permit :name, :price, :description, :stock_quantity
index do
selectable_column :id
column :name
column :price, sortable: true
column :stock_quantity
actions
end
end
Notice the selectable_column? That allows the admin to check boxes next to items to perform "batch actions," like marking ten products as "Out of Stock" all at once. It's a huge time-saver for anyone actually managing a real store.
Taming the Input Form
The default form is fine, but it's basic. In a real-world app, you often want a better user experience. For example, if your product description is a long-form text field, a tiny one-line input box is frustrating. You can override the form block to use different input types or group related fields together.
I often use div wrappers or div.grid-column` to organize the layout so the admin isn't scrolling forever on a massive monitor.
ActiveAdmin.register Product do
permit :name, :price, :description, :stock_quantity
form do |f|
f.inputs "Basic Information" do
f.input :name
f.input :price
end
f.inputs "Inventory Details" do
f.input :stock_quantity
f.input :description, as: :text, input_html: { rows: 5 }
end
f.actions
end
end
By grouping the fields, you're creating a cognitive map for the person using the tool. They know exactly where the "money" stuff is and where the "marketing" stuff is. It seems like a small detail, but when you're the one staring at this screen for four hours a day, it's the difference between a tool you love and one you hate.
📋 Practical Task
Building the "Vintage Camera Shop" Admin Panel
You are building a management system for a vintage camera store. You have a Camera model with the following attributes: brand (string), model (string), year (integer), price (decimal), condition (string), and notes (text).
Your task is to create an ActiveAdmin registration for the Camera model that meets these specific requirements:
- Permit all the attributes listed above.
- Customize the index view to only show the
brand,model, andprice. Make sure thepricecolumn is sortable. - Customize the form view to group the fields into two sections:
- "Camera Specs" (containing
brand,model, andyear) - "Sales Info" (containing
price,condition, andnotes)
- "Camera Specs" (containing
- Ensure the
notesfield is rendered as a text area with 10 rows.
Write the complete code for app/admin/cameras.rb.
There are no comments for now.