Now, when you build a Rails starter application with Rails Composer, you get the option of page-view tracking without any effort. Run Rails Composer and you’ll see:
recipe Running analytics recipe... option Install page-view analytics? 1) None 2) Google Analytics 3) Segment.io choose Enter your selection: 2 option Google Analytics ID?
I like Segment.io because it gives me Google Analytics plus any of 107 other services. With Segment.io, you can instantly switch on tracking for services such as Mixpanel, KISSmetrics, and many others. It’s a commercial service but it’s free for low-traffic sites (less than 100K pageviews or events per month). Rails Composer installs the Segment.io tracking script in the Rails asset pipeline, and adds code to accommodate Rails TurboLinks.
Rails and Analytics
I wrote an article on Analytics for Rails last year. You can see the article for more about the code you need for analytics. My goal for Rails Composer is “no mystery code.” That’s why I write tutorials and articles to explain the code generated by Rails Composer. Thanks to support from RailsApps subscribers, I was able to update the article this week. Please join me in giving a shout-out of thanks to the subscribers who pay $19/month to make this possible. And if you haven’t joined, please consider getting a subscription to support the project.
There’s also a new mailing list for news about Rails Composer. Join the mailing list if you want announcements of new features for Rails Composer.
You can now join a mailing list for news about Rails Composer. Sign up here:
Expect to receive two or three emails a month with announcements about features and changes.
The next time you run Rails Composer to build a starter application, you’ll see an option to join the mailing list. I’ve built an application for mailinglist.railscomposer.com (which you can find on GitHub) with a simple API that responds to a curl request generated by Rails Composer. It’s fun to see it in action. From the Rails Composer command line you can enter your email address, and the mailinglist.railscomposer.com application updates a MailChimp mailing list. Rest assured, there’s no funny business going on with the email addresses (it’s open source so anyone can examine the code); email addresses are not stored in the application database; they are simply passed to MailChimp.
I’m eager to see how many developers are using Rails Composer. In just a weekend, 20 developers have signed up for the mailing list. The Rails Composer repo on GitHub has over 2000 stars but we don’t really know how many developers are actively using Rails Composer. In any case, the mailing list will be a better channel than blog posts or tweets to announce Rails Composer features and changes.
If you’ve got ideas for Rails Composer, let me know. You can reach me at (firstname.lastname@example.org). Thanks to support from subscribers, I’m now working full-time on the RailsApps project, splitting my time between developing Rails Composer and writing tutorials.
Thanks to a code contribution by a developer in Russia, Rails Composer now has an option to set a default locale for a starter application. Anton writes, “I know it isn’t a significant new feature, but maybe the ability to set a default locale would be handy for developers from non-English-speaking countries.”
Rails Composer saves one step for a developer by setting the default locale in the config/application.rb file and creating an empty file in the config/locale/ folder. As a bonus, if the application uses Devise for authentication, Rails Composer will add the devise-i18n localization gem. That means your Devise messages are automatically translated for 40 different languages. Cool!
It would be nice if we could automatically translate the English words on the default Rails Composer home, user, and about pages. To do that, we’d have to add translations to the rails_apps_pages gem. That’s not in my plans, but if anyone wants to do it, I’ll add the contributed code.
Right now, the “set a default locale” option is available when you select “Custom application” in Rails Composer.
In April I wrote of my plans to drop MongoDB (and the Mongoid gem) from Rails Composer (see MongoDB Dropped From Rails Composer). Today I received a note from a developer who makes a case for keeping MongoDB. Steven Kolstad writes:
I believe that MongoDB has earned its place in our development community, even if the honeymoon period of early adopters is starting to wane. Despite what public opinion is gossiping about currently, there is a use case for this technology, and I predict that once the marketplace is educated about what that is, the popularity will balance itself out. I sat and watched how long it took for Ruby to prove that it wasn’t some fad. That, even amidst wide speculation to the contrary, Ruby could be an enterprise development tool with real production value. I feel that MongoDB will likewise prove their worth in the arena.
If, like Steven, you’re interested in adding back MongoDB and Mongoid to Rails Composer, let me know (email@example.com) and we’ll put together a team to share the effort.
I just released a 3.0.0 version of the rails_apps_composer gem that cleans up a lot of gnarly code, making it easier to add new recipes. The gem is still challenging to figure out, but I can help you with it. The rails_apps_composer gem contains the recipes that build the Rails Composer tool.
As a first step, someone could modify the rails-omniauth example app for Mongoid. It is the simplest of the example apps that use a database. The job may be as simple as modifying the User model. If someone builds a rails-mongoid-omniauth application, I’ll add it to the RailsApps examples collection.
It is important to have an example app because the only way to test Rails Composer with a regression test after each new release is to build an example app and compare it to the example app, using a file compare tool. Mark Blackwell contributed a regression testing tool named megatest, which someone may be able to adapt as needed.
To add Mongoid to Rails Composer, you can examine the file recipes/rails-omniauth.rb (in the rails_apps_composer gem) and create a new recipe recipes/rails-mongoid-omniauth.rb to build the example app.
That will give you a recipe that builds an example app but it won’t add Mongoid as a “custom build” option. That requires finding ways to create a Mongoid version of each existing RailsApps example app. You will have to find each place that a models/user.rb file is created and add logic to modify for Mongoid.
If you like MongoDB and Mongoid, this is your chance to join an open source team and build something that makes life easier for numerous developers. Don’t hesitate, even if you’ve never contributed to an open source project before.
I’ve completed a new tutorial on Rails authorization with Pundit.
RailsApps subscribers are getting tutorials every month:
- June - Pundit Quickstart Guide
- May - Devise Quickstart Guide
- April - RSpec Quickstart Guide
- April - Learn Ruby on Rails for Rails 4.1
- March - Bootstrap and Foundation Guides
You can join RailsApps to get the tutorials and support the project. Coming next is a tutorial on OmniAuth.
The new tutorial covers role-based authorization, showing how to use the Active Record enum feature in Rails 4.1 to add a role attribute to a User model. You can set up roles for administrators, users with free or premium plans, or any other system of privileges. The tutorial shows how you can set up simple role-based authorization without any extra gems. For more complex applications, the tutorial introduces the Pundit authorization gem.
Pundit or CanCan?
The CanCan authorization gem has been popular since Ryan Bates released it four years ago (it’s been recently replaced by its successor, CanCanCan). CanCan provides a domain-specific language that isolates all authorization logic in a single Ability class. As an application grows in complexity, the CanCan Ability class can grow unwieldy. Every authorization request requires evaluation of the full CanCan Ability class, adding performance overhead. Like CanCan, Pundit offers the advantage of segregating access rules into a central location. In Pundit, it’s a folder named app/policies/ containing plain Ruby objects that implement access rules. Pundit policy objects are lightweight, adding authorization logic without as much overhead as CanCan. Pundit is well-suited to the service-oriented architecture that is growing in popularity among Rails developers, emphasizing object-oriented design with discrete Ruby objects providing specialized services.
In-Depth Pundit Tutorial
For a small gem, Pundit has a surprising number of features. The RailsApps tutorial goes into depth, covering:
- set up with a starter app
- adding roles to the User model
- access rules in a policy object
- authorization in controllers
- authorization in views
- scoped database queries
- strong parameters
- adding RSpec tests for authorization
It’s the only in-depth guide to Pundit. I appreciate the support from RailsApps subscribers that made it possible to release this tutorial.
The Rails and Devise tutorial is now available.
Here are the tutorials I’ve recently released:
- March - Bootstrap and Foundation Guides
- April - Learn Ruby on Rails for Rails 4.1
- April - RSpec Quickstart Guide
- May - Devise Quickstart Guide
Next up, in June, will be a tutorial on Pundit, the authorization gem that is needed for almost every web application.
All the tutorials are available to subscribers to the RailsApps project. It’s my way of thanking subscribers for their support of the project.
Rails and Devise
Almost every web application uses Devise for sign in and user management. If you’re new to Rails, you need to know it. If you’re an experienced developer, you might find that your knowledge needs a refresh (do you know the Devise team recommends a new “lazy way” to handle strong parameters?). For such a popular gem, I found it surprising that there are no up-to-date, in-depth tutorials. So of course I had to write it :-)
The tutorial accompanies the rails-devise example application which is available on GitHub. It is a complete application which you can use as a starter app, complete with a suite of RSpec feature tests.
I’m working to build out a complete series of tutorials and example applications that allow a beginner to progress from no knowledge of Rails (starting with the book Learn Ruby on Rails), to learn how to use a front-end framework (Bootstrap or Foundation), develop testing skills (with the RSpec Quickstart Guide), and build real-world applications with authentication (the Devise Quickstart Guide).
All the example applications can be built with the Rails Composer tool so they can be used as starter apps. My goal is to offer a complete suite of starter apps with every line of code explained in a tutorial.
I’m grateful to the subscribers who support the RailsApps project so I can continue to build out these resources.
This week I released the RailsApps Testing gem. It sets up a testing framework for Rails by setting up configuration files for:
- Database Cleaner
- Selenium Webdriver
For more about this testing framework, I wrote a tutorial on testing with RSpec (subscriptions support the RailsApps project):
This is a popular collection of gems for testing Rails applications. Typically, a developer makes several small configuration changes when setting up a test framework with these gems. The configuration changes are easy to make manually, but this gem provides a generator to make the changes, for ease of use with an automated process such as an application template.
That’s why I built it. The code for the Rails Composer tool is getting increasingly complex (some would say “gnarly”). I’m slowly moving code from the rails_apps_composer gem (which builds the Rails Composer application template) to separate gems. The first step in that direction was the RailsLayout gem, which generates Rails application layout files for various front-end frameworks such as Bootstrap and Foundation.
I primarily use RSpec and Capybara for testing, but in principle, the gem could also set up Test::Unit or Cucumber frameworks. If someone submits a pull request, it could give users of Rails Composer the option of alternatives to RSpec.
I’m interested in learning more about the configurations people like for their testing frameworks. There are other interesting gems that assist in testing. Some, like Guard, don’t need any special configuration. Others can’t be used without some integration with RSpec. The RailsApps Testing gem sets up one of the common configurations of a test framework. If there are other possibilities, let me know and we can expand the RailsApps Testing gem.
As always, a big thank you to the RailsApps subscribers who support this work.
I’ve dropped MongoDB as an option from Rails Composer. I’m not sure if this will be temporary, or if it will become permanent. That’s up to you.
MongoDB and the Mongoid ORM were offered in Michael Bleigh’s rails_wizard which I forked in 2011 to develop the rails_apps_composer gem (I use rails_apps_composer to build the Rails Composer application template). Three years ago, MongoDB was popular, especially for quick-and-dirty prototypes or project spikes. Mongoid eliminates the need for migrations because the database automatically adds tables or columns that match models or attributes in a Rails application. That’s convenient, but in the last three years MongoDB lost its halo among developers. Articles such as Sarah Mei’s Why You Should Never Use MongoDB summarize its disadvantages. There are some valid use cases for MongoDB, but most Rails developers now use SQLite for quick-and-dirty prototypes and PostgreSQL for production.
I’ve relied on the community to provide patches to support Mongoid in the rails_apps_composer gem. As MongoDB’s popularity has waned, there have been fewer offers to help. Other databases use ActiveRecord as an ORM and it’s relatively easy to offer support for SQLite, MySQL, and PostgreSQL. MongoDB, not so much, since every model generated by Rails Composer has to be hacked to support Mongoid. That means every release of Rails Composer that makes changes to models requires customization for Mongoid. No one has stepped forward to make the fixes needed for Mongoid support, so GitHub issues are open and not getting resolved.
Rails Composer is primarily a tool to build the RailsApps example applications. I actively contribute code and resolve issues to support that mission. Rails Composer has a “build your own option” and a large community of developers contributes code that supports popular gems and favorite configurations. I merge pull requests that support options I don’t actively use. When I accept a pull request, I trust and hope that the community of developers will actively maintain any options that I don’t use, but sometimes a gem will lose popularity and end up as a neglected and little-used option in Rails Composer. If no one notices, that’s fine, it is just cruft in the code.
The Mongoid option creates more of a problem, though. A few people still choose the Mongoid option in Rails Composer, and people have opened GitHub issues to report problems with Mongoid. That’s fine, but the issues are languishing and no one has submitted patches for a fix. Consequently, I’ve decided to drop the Mongoid option from the Rails Composer menu.
If you want the Mongoid option in Rails Composer, let me know and I will work with you to prepare the code that’s needed to support Mongoid. If no one steps forward, I’ll assume Mongoid is really no longer wanted.
Today I’ve released version 2.0.1 of the book Learn Ruby on Rails. Last week I released version 2.0.0 with major updates.
You can get the updated book when you join the RailsApps project:
This is the only Rails book that covers Rails 4.1. Does that matter? I think so. If you’re a beginner, and you install the newest version of Rails, and your book doesn’t match what you see when you open Rails, you’re going to feel lost from step zero.
Plus, Rails changes every six months in significant ways. Rails 4.1 introduces the config/secrets.yml file which offers a new, recommended way of setting configuration variables, a facility at the core of any Rails application. Rails 4.0 introduced strong parameters, a new way to handle forms submissions that affects almost every Rails application.
It is challenging to always update books, videos, or online courses for the newest version of Rails. It seems most authors and publishers don’t bother, or wait months to release a new edition. I’m trying to change that, by publishing Learn Ruby on Rails as part of the RailsApps project, with a subscription-based business model.
How am I doing? Rails 4.1.0 final was released April 8th. I released an updated version of Learn Ruby on Rails the same day.
Here are details about what’s new in each version. The book has a “Version Notes” chapter with more details.
- Added resources to the “Get Help When You Need It” chapter
- Added a section explaining the config.assets.precompile configuration setting
- Added a hint about passwords that use punctuation marks (contributed by a reader)
- Updated references to Ruby from version 2.1.0 to 2.1.1
- Updated the tutorial application from Rails 4.0 to Rails 4.1
- Dropped the Figaro gem and showed how to use config/secrets.yml
- Updated the “Front-End Framework” chapter
- Updated “The Parking Structure” chapter about the Rails directory structure
- Introduced the concept of service-oriented architecture (SOA)
You can read the book online or download it in three ebook formats: PDF, Mobi (Kindle), ePUB (iBooks). A subscription is $19/month, which means updates, plus additional books and tutorials. Right now, when you purchase a subscription, you get:
You can sign up for a subscription on the RailsApps site. In addition to getting books and tutorials, you’ll be supporting development of the RailsApps example applications and tools for starter apps.
I’m fascinated with Nitrous.IO. If you don’t know it, it’s a service that gives you a computer inside your web browser. It’s free for small projects and you get a powerful Linux-based development environment that’s hosted “in the cloud” and available instantly in any web browser. It’s no big deal if you’ve already got a full-blown Rails development environment installed on your local machine. But for thousands of newcomers who are daunted by the obstacles of installing Rails, Nitrous.IO delivers a development environment without hassle. In my Learn Ruby on Rails book, I recommend it to anyone who encounters difficulty setting up a development environment for Rails (and that means almost everyone on Windows).
Now there’s the Nitrous.IO Hack Button. Here’s what it looks like:
Click on the button and you can log in to Nitrous.IO with a RailsApps example application fully installed and ready to run. No need to install Ruby or clone the repo from GitHub. The Nitrous.IO Hack Button does that for you.
I’ve added the Nitrous.IO Hack Button to six of the RailsApps example applications:
So anyone can try the example applications without installing a development environment locally or cloning the Github repo.
For most RailsApps users, who are experienced Rails developers with their own local development environments, or for students who need to set up a development environment so they can begin to master Rails, the Nitrous.IO Hack Button won’t be useful. Nonetheless I’m fascinated by the idea that one click can create an entire Rails development environment with a ready-to-launch Rails starter app.