I agree with Michael with 2 and 4. > > 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. > > Combining boot.rb and environment.rb (and possibly application.rb) would make it easier for people to understand the booting process. boot.rb is actually misleading since rails 4 (and 3?) since this is not booting anything. application.rb could wrap all of this.
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. Yes! The logic could very well live in the gem. I have actually made a github repository last week that highlighted what I had in mind: https://github.com/pothibo/rails-flattened (bin/ folder is still present since that path is hardcoded in rails' gem). I believe that with Rails 5, a new folder structure should be promoted that would be lighter and easier to understand for someone not used to Rails. ........... I guess we could tweak this repo and try to find a right structure, if people are willing? On Monday, June 9, 2014 7:42:50 PM UTC-4, Ryan Bigg wrote: > > Replies inline. > > > On 29 May 2014 14:35, Michael Kaiser-Nyman <micha...@gmail.com > <javascript:>> 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
