I have upgraded my app to Rails 3.1.0, and while I have solved many compatibility issues, but I have also noticed that there are many redundant files, junk codes, and some features I have to recode again.
I am just wondering if I should just rewrite my app from fresh in Rails 3.1.0, or continue modifying and fixing after the upgrade? The former one will produce a cleaner app, but more work, and the latter one will be faster, but will also take some time to clean up the mess. What is my best approach?
Thanks.
what I do is create a fresh empty rails 3.1 app. Install my gems with bundler. Then I copy over my migrations, my models and my spec tests. Run my tests. Get tests passing, resolve any incompatibility issues. Repeat with config/routes, controllers, views, etc.
Related
I'm trying to use sidekiq in a project but have run into an unusual problem that makes no sense.
I've got multiple rails applications on my laptop, many of which are using sidekiq, and are running fine without any problems.
This application also uses sidekiq, and used to work however I'm not running into a problem. I've not touched the project for a while, but the only difference between now, and when it used to work is the upgrade from OS X Lion, to Mountain Lion. This however hasn't effected other projects, so I'm not sure what's going on. When I try to launch Sidekiq, I get an alert stating
To open "sidekiq," you need to install X11.
Would you like to install X11 now?
It's the standard Apple alert, however I don't understand why Sidekiq is supposedly trying to use X11, and why it isn't using it on my other projects?
I'm using
Rails 3.2.8
Ruby 1.9.3p125
Sidekiq 2.13.1
Any help would be really appreciated :)
Got it running. Turned out it wasn't an issue with Sidekiq, but rather ruby for some reason. After I updated ruby to 2.0.0 and fixed other gem issues, the app started up again and is now running. No idea what was going on but it's sorted :)
I'm working on a small project that has been allocated a small amount of time to maintain and update features. This project is on Rails 2.3.
I'd like to move it to Rails 3.2 but there is little time allocated to this so I would like to do it over a slow gradual process.
I'm thinking that it might be worth moving over to Rails 3.2 on a section-by-section basis.
This would mean that I would create a second application that looks the same as the first one but is located somewhere different and accessed from a different subdomain.
Is this feasible if I just update the Rails 2.3 routes file for certain routes to go to the new application?
Has anyone done this before?
It depends on many parameters but among these the most relevant are :
Does your Rails 2 project already use Bundler ? If not, migrate to it before the migration.
Do you use gems which are known not to work on Rails 3 ?
Does your project already use Rails XSS plugin (https://github.com/rails/rails_xss) ? If not, migrate to it before the migration.
After that, the migration will be easier.
For the migration, I recommend that you create a brand new Rails application using "rails new" command, so that all the boot files will be good. Then migrate the initializers/config files and "app" folder...
Good luck.
So I finally upgraded (and then downgraded because of Unity) Ubuntu and reinstalled RVM but I'b stuck with rails 3.1 now, which is fine but all my old projects are in rails 3.0 and 3.1 has some incompatibilities. Off the top of my head RAILS_ROOT is now Rails.root (which all my projects use in someway), and I was having some issues with heroku when trying to upload a small rails 3.1 app I made to play around (since the PG gem wasnt in my gemlist I couldnt run migrations, and then installing the pg gem caused more issues).
So how do I install rails 3.0 again? I cant seem to find it in the repositories
And I know with gem sets I can install both right? Well if I do that, how do I create a new rails project? Which version of rails would use rails new new_app?
Ok, I understand what you need to do. I would highly recommend making a new Gemset using RVM, that way you can start from scratch and not worry about those things.
To do that, run this in your command line with RVM installed:
// EDIT THIS LINE TO MATCH WHAT YOU WANT
rvm use 1.9.2-or-which-ever-version-you-are-using#temporary_gemset --create
Once this gemset is created, it will be empty, so you can then proceed to install a younger version of rails, like so:
gem install rails -v 3.0.11 // (MAY NEED TO USE SUDO, DEPENDING ON YOUR SET UP)
This should install the older version of rails and its dependencies so that you can still edit and work with your older rails project. Check more of RVM's site for more help on switching between gemsets and creating them.
https://rvm.io//gemsets/
I would still recommend to figure out the differences eventually and move to the newer version for Rails, currently 3.2.5 because they are awesome. Here is some material to show you the differences and new features for when you do that later:
http://railscasts.com/episodes/265-rails-3-1-overview
http://railscasts.com/episodes/282-upgrading-to-rails-3-1
http://railscasts.com/episodes/318-upgrading-to-rails-3-2
what is the best when it come to choosing what version of rails to use in your development?
I wanted to upgrade to the newest version for the new features, but in many cases chances were high that my existing code would be broken, and a lot of extra time definitely needed to spend fixing it. Should I stick with the current version of rails I'm using? or heading for upgrade?
Any advice or guideline would be really appreciated.
It is useful to always upgrade, because new gems might not support older versions of Rails and you wil get new features from Rails which could reduce code. You can do it step by step, fixing time to time code that will break in newer version of Rails. It more like continuous refactoring.
I think you have to check carefully when and how to upgrade. Here are some hints that may help in the upgrade process:
Patch versions (like upgrade from Rails 3.1.0 to Rails 3.1.1) were normally no problem at all. Upgrade whenever possible, normally you don't have to change anything. Sometimes you have to check if other Gems as well should be upgraded, read the release notes, they give (sometimes) hints about that.
Minor versions (like upgrade from Rails 3.0.9 to Rails 3.1.0) come with new features and non-compatible changes. In the release notes, you will find information what has changed and has to be proven before hand. As an example, look at Ryan Bates railscast "Upgrading to Rails 3.1.0". You normally have to do the following steps:
Upgrade to the last patch version before.
Look at the deprecated log messages. These are the ones that may break after the upgrade.
Tag your current application, or branch to be sure to not destroy anything by the upgrade.
Do the upgrade up to the point you are sure most needed features work again.
Merge back your changes, and continue with the upgrade
(Have done that the last few days for an application I have upgrade from Rails 1.2 to 2.0 up to 2.3.8 to 3.0.0 up to 3.0.9, and now 3.1.1.)
Major version upgrades are even more difficult. You have to ensure that you have enough time and resources to check all the minor glitches you may have. Most of the time, there were resources available by the Rails team that help do the upgrade, like the Rails upgrade helper or the 3 railscast "Upgrading to Rails 3".
In any case, you should at least check if the main Gems you are using (additional to the normal Rails gems) are compatible with the version you want to migrate to. This may be tricky, but sometimes, the information is available.
My experience is, that Major upgrades take time, and if you don't have it, don't do the upgrade. Minor upgrades take some time, and depending on the change (assets in Rails 3.1) come with a price tag, which is sometimes, not all of the times, worth it. Patch upgrades are painless and should be done at will.
Our Rails application pulls feeds from multiple sources. The workers that pull these feeds need gem dependencies for rmagick, oracle databases, and many other gems. In short, they have very different dependency needs than the main web application. Until Rails 3 and Bundler, life was good.
These worker gem dependencies are irrelevant to our actual production website. Under Rails 3, one Gemfile is expected to contain all these dependencies. This has the nasty side effect of requiring all gem dependencies to be loaded within the production app, which would cause pointless bloat, possible security issues, memory leaks, complicate deployment, and other ills. Sadly, Bundler breaks the standard require mechanism, which would have provided a way out of the quagmire by allowing us to simply require the necessary gems only in the worker and have them somewhere on the system, not in the bundle. The workers use our rails models to file their data.
Can anyone suggest solutions to make the system practical in Rails 3? I am tempted to make the Gemfile use conditional environment variables in places to drive the gem commands, however, it seems the Gemfile.lock could make this problematic going from working on one worker script (for the feeds) to the next, which would have different dependencies. Help???
I've been contemplating a similar problem, and although I don't have a solution in use anywhere yet, your question did make me think it out some more. I think you should be able to use a group to accomplish this. You can add something like this to your Gemfile:
group :workers do
gem "extra_gem_1"
gem "extra_gem_2"
end
Then, you can call
Bundler.require(:default, :workers)
and that should load your gems. How this works will depend on your setup, you might be able to add logic to config/application.rb, or you might need to do this elsewhere. This might be hackish, but it works in the console anyway.
When installing your gems, you can call:
bundle install --without workers
to exclude those gems from production.
Alternatively, you can use two Gemfiles, but that seems like a mess as well since presumably there's some crossover.