Replies inline.
On 29 May 2014 14:35, Michael Kaiser-Nyman <[email protected]> wrote: > Hello! I teach quite a few people Rails through my class, Epicodus. One > thing I've noticed is that the sheer number of files and folders `rails > new` generates is pretty intimidating for newcomers to Rails. I'd like to > make a few suggestions to how to reduce that intimidation. > > 1. Don't create the `tmp` and `log` folders. These are automatically > created when `rails server` runs for the first time, so there's no reason > `rails new` needs to generate them. > A quick explanation here that explains these folders is all that is required. The newbies can learn more about these as they come up. Tell them that it's safe to ignore these files for now. > > > 2. Combine `boot.rb` and `environment.rb`. I'll be the first to admit I > don't understand the Rails boot process as well as I wish, and there may be > implications to this I don't understand. But in my informal testing, moving > the contents of one file to another works just fine, and I personally > having trouble seeing the distinction between the two. > Quick summary: bin/rails loads boot.rb, which tells Bundler to setup the load paths for the gems in the Gemfile (including Rails itself). The main purpose of this file is to set up the load paths for bin/rails, and allows Rails to use something other than Bundler if people are crazy enough. That file then loads rails/command which processes the args passed to "rails", which *can* lead it to loading config/environment.rb. Here's the stack trace: https://gist.github.com/anonymous/67ec70f672e6e9fba187. Combining boot.rb and environment.rb is not a good idea imo, because these two files serve their purposes well: one sets up the load paths, the other sets up the Rails application's environment. Slightly different, but important distinctions to make. > > 3. Remove internationalization by default. I could be totally off-base, > but this feels like a feature that probably isn't used by a majority of > apps, and could easily be added by more experienced developers who need it > (and a Rails generator could be built to easily re-install it). > I18n is an important feature to have and if you don't want to use it then you just don't. It's opt-in and newbies can get away without even referring to it during their first apps; just like what happens during the entire ~600 pages of Rails 4 in Action. > > > 4. Move binstubs logic into the Rails gem executables. I haven't played > around with this yet and could be wrong, but I don't see why these files > need to be added to every app, when their logic could simply be included in > the rails/rake/bundle/spring gem executables. > I am not sure what you're suggesting here. Could you elaborate? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
