Use the given project generators
Rails
Before I started using Rails I was the guy who would type out web projects by hand… I was accustomed to it. I knew what I was working with all the time simply because I wrote it. When I had started reading the docs on Rails I was trying to learn it in this same manner that I was used to. But there is a fundamental piece missing when approaching Rails in this way. Rails is opinionated code. It’s designed with a predetermined way for things to work. And for that you need to build the empty project template from the standard command rails new my_project_name.
My not typing this simple command left me like being a stick in the mud only grasping at concepts. The truth is once you generate the project, everything becomes much simpler. From there it’s easy enough to poke around and learn how it works.
It turns out that there are many default ways of doing things. Whether it’s Rails, Rails engines, Rails plugins(railties), or gems. These tools in Ruby have generators built for helping you both understand the uniform standard, and to just get you started with something that works.
For Rails you may have already seen the standard rails new command. But did you know you can specify which version of Rails you want to use for the project right in that command?
# rails _version_ new project_name rails _4.2.0_ new my_project
This also is the same for building plugins, railties, and rails engines.
# For plugins/railties you simply put plugin rails _4.2.0_ plugin new my_plugin # For mountable rails engines you add --mountable rails _4.2.0_ plugin new my_plugin --mountable
You can also generate these template project folders without specifying the version. It will use the latest version of Rails you have installed for generating the project. I won’t be going over too much detail on these, you can read the official docs on Plugins and Engines.
One thing that’s nice about these particular plugin/engine generators is that they provide a dummy directory within the test folder to let you test your code against a Rails project. One thing to note (if you want to test against multiple versions of Rails) is that as of Rails version 4.2 the default way Rails is configured and initialized has changed. Pre 4.2 things are defined on Dummy::Application, as of 4.2 it’s now Rails.application. So you’ll need to make a uniform setter method for this to work in testing different Rails versions. Assuming all future versions of Rails stick with the new standard you would put this at the end of your config/application.rb file.
# /test/dummy/config/application.rb
DummyApp = begin
if ::Rails.version.to_s =~ /^(?:(?:4\.[2-9])|[5-9])/
Rails.application
else
Dummy::Application
end
end
This will set Rails.application for all versions of Rails from 4.2 and on. Earlier versions will use Dummy::Application. Now, before you put this in, it would be best to substitute the string through your entire project to the new name of DummyApp. In Linux you can use the following command.
grep -lR "Rails.application" | xargs sed -i 's/Rails.application/DummyApp/g'
This assumes you generated you directory with Rails 4.2. For seeing how to test multiple Rails versions with Travis CI this is a good guide to use: Testing Against Multiple Rails Versions You will need to have loose definitions on your gem version requirements to accommodate the older Rails versions… also dealing with different testing frameworks during different Rails versions may get a little bit hairy. For that it might be worth looking into these two gems: appraisal and wwtd. For getting started with ‘Travis CI’ I have a tutorial here: Free Travis CI for your Open Source project
Regular Gems
With bundler you can generate your own gem project folder.
bundle gem my_gem
The official docs for getting started with your own gem are here with Bundler: Using Bundler with Rubygem gemspecs and here with Rubygems: Make your own gem
Follow by Example
Sometimes you will need to build a project and you’re going to need to do some complicated integrations and the documentation just doesn’t make it clear. When this happens it’s best to find a project in the open source community that has already built something with the same situation as your own. Basically you can clone their project, strip out all of their project code and keep only the hooks for Rails (if that’s your case). I did this when I created my gem Dynaspan. I needed to write a Rails library that was going to hook into the view and use JavaScript; and the docs weren’t too great on this. By using something I knew that was working beforehand, I could narrow down any problems I was having to my own code.
This of course is a pointer to a recommended practice to “read code”. You learn new things when you start going through other peoples code. You grow in understanding and learn new perspectives. Feel free to fork any open source project and tinker with it to see what happens. You may be able to help with an issue that needs to be addressed.
Extras
If you’ve already got a decent understanding for developing Rails projects then it may interest you to have a tool that will do a lot of the work that you repeatedly have to do when you start a new Rails project. There are some tools made that will help with this. The one I’m aware of is called Rails-composer. This tool takes you through a few questions and then builds the Project template as you requested. I’ve heard of some other projects that do similar things, but I haven’t seen them. A quick Google search has revealed one called Raygun (I haven’t tried it).
Summary
When there is a standard way for something to be done, then there is in essence a template that fits those standards. It would be unwise to work against the way something was designed if you don’t know what your doing. And for keeping things working as designed you have generators. At first it may seam like cheating having code generated for you. I know I sure felt that way; and I didn’t like it at first. But it’s not cheating, it’s following the purpose of design in which the projects were chosen to be implemented. Rails is opinionated and that’s a good thing. It allows you to get more done much more quickly.
When getting into Ruby creating a gem is a hallmark moment. It’s something anyone would want to do, and it’s almost like having a badge of accomplishment. And when you’re going to be reusing something in more than one project it is very helpful to have it available as a gem.
There are plenty of howtos on creating your first gem, but I suggest it’s better if you generate the template project than to do it all from scratch. You’re more than welcome to remove things you don’t want after the code has been generated.
May your experience be much better now with the tools that have been given to you. Please feel free to comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!
God Bless!
-Daniel P. Clark
P.S. For anyone who wants to build their Ruby/Rails environment, without the hard work, you have to check out Bitnami’s Ruby Stack. It’s a complete all-in-one environment package suite for your operating system. And they have a virtual machine image you can work in and get the same thing done.
Bitnami Ruby Stack provides a complete, ready-to-run development environment for Ruby on Rails. It includes the latest stable release of Ruby, Rails, RVM, MySQL, SQLite, NGINX, Apache, Memcache and Varnish, Git and Subersion, Sphinx, PHP and phpMyAdmin. It also includes most popular gems for building Rails applications: Thin, RMagick, Rake, Mongrel, Passenger, Nokogiri and more. It also includes libraries such as OpenSSL, openLDAP, CURL, ImageMagick and more.
Enjoy!
Image by Rob Swatski via the Creative Commons Attribution-NonCommercial 2.0 Generic License.