Added scripts for starting up app and server; updated migrations; added instructions for Docker

[jhsu802701]

• I updated the migration scripts, because I was getting the following error message:

  StandardError: Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for

• I made no other changes in how the app runs.
• The only other change I made to a pre-existing file in this app was updating the README.md file to direct the reader to the README-ruby_on_racetracks.md file for a faster way to get started.
• Running build_fast.sh script automatically sets up this app in only one step. (It includes the process of configuring PostgreSQL.) Those who prefer the old way are free to ignore it.
• The server.sh script automatically sets up this app for the Ruby on Racetracks way.
• The test_app.sh script is called by the build_fast.sh script. It runs "bundle install", the database migration scripts, and the tests.

[coveralls]

Coverage remained the same at 52.482% when pulling 4ae84f08327ed9f1e863fea35ab09f82ffc34392 on jhsu802701:build_fast.sh into d9c77c1dacc200b01cd040530b7293a869cf7d85 on minnestar:master.

[jcoyne]

I feel like this makes it more difficult to set up because it adds a dependency on Docker as well as tmux. Besides the migration issue I'm not exactly sure what problem this is solving. It would be helpful if you created a separate PR that just has the migrations fixed.

[jhsu802701]

You can still use the Vagrant way. This Docker OPTION is a faster alternative and is not required. The Docker images I've provided come with tmux already pre-installed. rbenv, NVM, Node.js, Phantom.js, etc. are pre-installed. Also pre-installed are the correct versions of Ruby, the rails gem, the pg gem, the nokogiri gem, and the ffi gem. Under my Docker OPTION, you never have to wait for all these things to be pre-installed, and the "bundle install" step is much shorter with the correct versions of rails, pg, nokogiri, and ffi pre-installed.

[jhsu802701]

The Bash scripts I added streamline routine tasks. After you "log into" a new Docker container, you just git clone this app's source code and run the build_fast.sh script. It automatically configures PostgreSQL for you and then runs the test_app.sh script, which runs "bundle install", runs the database migrations, and runs the RSpec tests.

[jhsu802701]

The Adopt-A-Tree project at Open Twin Cities (https://github.com/OpenTwinCities/adopt-a-tree/) is an example of a legacy project where I've provided the option of using Docker and automation scripts.

The new Ruby.MN app (https://github.com/jhsu802701/rubymn2) is an example of a clean sheet design that uses my Ruby on Racetracks principles (http://www.rubyonracetracks.com/).

[jhsu802701]

With the aid of my custom Docker image and Bash scripts, I can get my Ruby on Rails apps up and running on any modern laptop/desktop computer in a few minutes. This includes Linux PCs, Macs, and Windows PCs. Transferring a project from one machine to another is trivially easy.

If anything strange happens that gives me even the slightest notion that my development environment is broken, I can reset the development environment to initial conditions in just a few seconds and be back in business in a few minutes.

[jcoyne]

I'm sorry @jhsu802701 I'm still not convinced. I can see that you are very passionate about promoting Ruby on Racetracks and I'm sure it works very well for your workflow. However, I think that learning Ruby on Racetracks is an additional hurdle that we would be putting on developers. I'm not convinced that the problems that Ruby on Racetracks tries to address are real problems for me. Perhaps @pcantrell or @caseyhelbling think differently.

[jhsu802701]

Use of the Ruby on Racetracks way is optional, not mandatory. The only change I made to how the app works is the updated migration scripts, which are necessary for all developers and the production environment. Everyone is free to ignore the src/build_fast.sh, src/server.sh, and src/test_app.sh scripts that I added. Everyone is free to ignore the Docker instructions I added as well.

Similarly, I personally don't agree with the Guard gem (since it requires that the Guardfile be set up properly and maintained), but if someone on a project I'm on wants it, I won't object to having it.

[tonyc]

I'm inclined to say this PR should be declined simply because there are completely unrelated changes all lumped together.

[jhsu802701]

I will submit a new pull request with just the updated migration scripts.

[tonyc]

Thanks, Jason!

For what it's worth, you might want to look into seeing if a rails db:setup properly sets things up first -- it's entirely possible that the migrations don't need to be run on initial setup, since db:setup will run db:schema:load. If that's the case, then perhaps an update to the project's README would be in order.

[pcantrell]

I’ve largely kept out of this discussion since my concern on this project has mostly been the scheduler, and I’ve never had primary responsibility for deployment. However, I will note that newcomers to the project haven’t historically had much trouble getting it up and running locally. Onboarding and deployment seem like nonissues from where I sit.

Getting gems on current patch versions, OTOH, does seem like a worthy goal.

Jason, if you're looking for helpful tasks, there are plenty of issues already logged on the project. The current areas of greatest need mostly have to do with usability, accessibility, and styling. Many issues are quite solvable, but have languished because nobody has time to work on them. Focused fixes that address some of those problems would be welcome.

[jhsu802701]

I submitted a new pull request (https://github.com/minnestar/sessionizer/pull/182) consisting of JUST the migration script updates.