Some background:
I am new to Ruby and Rails and I've been assigned to get an already completed Ruby on Rails project to compile from source.
The project has, as far as I've been able to discover, little to no documentation on how to set it up. The developers are unavailable for me to contact.
After doing some tutorials and learning the basics I have been trying to get the code to compile and run. My platform/setup is currently:
Windows 7
Ruby 1.9.3
Rails 3.2.13
Although I am attempting to develop with a VirtualBox Ubuntu setup alongside of this because I suspect it will be easier in the long run.
Despite there being no Gemfile for this project I have managed to (I believe) pin down and install all of the necessary gem packages (hopefully compatible versions). I am now running into this issue:
in alias_method': undefined methodpath' for class `ActionController::UploadedStringIO' (NameError)
As far as my searches have led me to believe this is a bug that can occur when the versions of Ruby and Rails are not correct/incompatible?
Is there a way to "reverse engineer" what version of Ruby and Rails was used to develop this project in the first place from the code alone? Could this bug be caused by me using 3.2.13 Rails if the original developers were using 1.8.7 Ruby? It seems to me that if I can emulate their setup closely enough then the source should compile and I can get down to business.
Additionally I am using the default WEBrick server. Is there a way to determine what the original team used for the web service? Does it even matter if they used a Apache setup or are these server implementations mostly interchangeable aside from efficiency?
Thank you for your time. If you have any further advice on how to handle this sort of project I'd love to hear that too.
If there is no Gemfile, it points to the Rails app being 2.3 or earlier. As for the Web server, they are interchangeable, but there is really very little chance that they were using Webrick, due to its ability (or lack thereof) to handle many concurrent requests. Chances are, they were using mongrel, or passenger via Apache or Nginx.
I am trying to find a tutorial or a document or what ever which will show all the real steps with details how to setup my win 7 pc in order to debug - deploy a rails app through rubymine. I have found only spare pieces of the puzzle which i don't know how to connect.
I am newbie to ruby stuff, that's why i need details steps.
I will appreciate any help.
Download the rails installer.
http://railsinstaller.org
And then rubymine, and you should be good to.
That said, windows is less than ideal to do ruby develoment on. I did it for a while, and I spent to much time fighting the fact that ruby is best on a Unix based system. You can install ubuntu on a virtual machine and used than for your rails needs.
I think the best day to do this is to use vagrant. Check this http://www.confreaks.com/videos/2368-rmw2013-ready-to-code-automate-your-development-environment
I was dismayed to find that rake takes 20+ seconds to load before running my Rails tests. I searched and it seems that everything in Rails is just much slower on Windows. I tried to use spork but it doesn't work on Windows.
So how do you test Rails on Windows? How do you setup your environment?
How about continuous testing?
After a TON of searches the takeaways are:
1) Ruby (and therefore Rails) on Windows is painfully slow.
2) There's an attempt to make Ruby faster on windows (https://github.com/thecodeshop/ruby/wiki/Downloads). Although it's not as fast as in *nix, it's fast enough to work with.
So the answer is: Avoid developing Rails on Windows if you can. If you still want/have to develop on Windows then replace your Ruby files with The Code Shop's Ruby build, it will give you a workable speed.
As a side note, for all the talk about being open, embracing diversity, etc. the Ruby and Rails community is very antagonistic to people asking how to do X or Y on Windows. On my searches most of the posts I saw were to the tone of "Winblows sux00rz! get a Mac or Linux".
Update:
I got spork + autotest + growl working on Windows so testing is much faster and automated. I put the instructions in this blog post.
I was following the solution on this answer for distributing rails apps but it seems like it's not up to date for everything with slingshot.
I just can't get it working. Is there a new or another way to get a rails application distributed into offline exe file and .app for Mac OS X ?
I went down this path a year or two ago and didn't find any success. I couldn't ever get Slingshot to work with 2.3.x Rails apps, I even thought about deploying the application on an entire OS system wrapped up into a virtual .exe using Xenocode (which is now Spoon Studio). Ultimately, I rebuilt the back-end Ruby stuff in javascript and deployed it as an AIR app, not something I'd recommend or even do again myself.
There's another thread on this topic with some other options listed in the answers and comments:
Distributing Rails Applications as Native Applications
Good luck.
I'm developing an application with Ruby on Rails that I want to maintain for at least a few years, so I'm concerned about the next version coming up soon.
Going from Rails 1 to Rails 2 was such a big pain that I didn't bother and froze my gems and let the application die, alone, in the dark.
On this project I don't want to do that. First because this new version looks awesome, but also because this application may turn into a real product.
How can I prepare my application so that it will be upgradable with as little changes as possible.
How time consuming do you think switching version will be?
And what about my server? Deployment?
I'm already looking at deprecation notices... what else can I do?
The best thing you could do would be to follow development of Rails 3 via blogs and the Github repository and keep up a copy of your app along with it.
The official Ruby on Rails blog is updated with "What's new in Edge" posts every once in awhile. There are other blogs that often write about new things in edge as well. Larger features are often highlighted in these blogs, so you know about all the cool new features you can play with.
I'm not sure how close Rails 3 is to release (last I heard the core team was talking about a release at RailsConf 2009 in May), but you can always freeze the edge version of Rails into your application and just see what breaks. If you are using git, or another DVCS, you might make a branch specifically for Rails 3 and periodically update Rails to the latest edge code. Just be aware that edge Rails is a moving target so things in your app may break or fix themselves as you are pulling in newer Rails code.
Update:
Jeremy McAnally has a ton of info on upgrading from Rails 2 to Rails 3 on his blog.
http://omgbloglol.com/
I don't think there is going to be a major problem. Going off what was said in that initial report the Rails team realized that they can't do a major rewrite like they did from 1 to 2.
They even say:
I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3.
I would be more concerned going from Merb to Rails 3.
The single most important thing you can do to make it easy to migrate to a new version of rails is to have a comprehensive test suite. Without a good test suite, I would never have the confidence that the new version of rails hasn't broken something in my app. On the current Rails app I'm working on, we started on Rails 2.1.1 back in October of 2008. Since then, we've migrated to Rails 2.1.2, 2.2.2, 2.3.2, 2.3.3 and now 2.3.4. I did the migrations to 2.3.2, 2.3.3 and 2.3.4...and for the 2.3.2 and 2.3.3 upgrades, we had some failing tests that alerted us to problems we would not have discovered without having such a good test suite. The failing tests actually alerted us to a regressive bug in rails that there was a patch for on the Rails lighthouse but that was not included in the release (since it was discovered, right after the release).
Once you've got that test suite in place, just stay current with each rails release (waiting a couple weeks to upgrade is fine, just don't skip any of the releases).
Yehuda Katz (a member of the Rails core team) has stated that there will most likely be a transitional release, containing deprecation warnings and such.
So as long as you have a good test suite to expose the inevitable upgrade problems, and stay current with the Rails release, the migration to Rails 3 should not be too difficult.
As simple as:
One
Two
Three
Great screencasts from Ryan Bates.
For preparing your application, the best way it what Jared said. Follow the Rails3 development.
For the time consuming, I think it depends of how you've followed the rails3 development before it's release.
And for the deployment, it shouldn't take too much problems. Rails 3 will be using Rack. So you can start it with mongrel, passenger or any server/gateway it shouldn't give you any problem.
There are some major changes in Rails 3, I posted about my experience upgrading my app to Rails 3 here: http://rails3.community-tracker.com/permalinks/5/notes-from-the-field-upgrading-to-rails-3
A good start in preparing would be to migrate over to using bundler. And doing a very deep review of strings that will go through the new XSS protection scheme.
There are going to be some automated compatibility checkers. Also, keep an eye on http://www.railsplugins.org/ so that you know if the libraries you depend on are going to be upgraded. The Rails Core team seems to be giving a lot of advance notice to the community this time around, so any lib that is actively maintained should be good to go.
Just do one thing
take a backup of your old version project first and then
on terminal(command prompt) write
rails new path/of/the/project
for example if my 2.3.* project is at home/rails_projects/myproject then
rails new home/rails_projects/myproject
or
cd home/rails_projects
rails new myproject
It will ask if there is any modifications done in any /config or other files. Do appropriate.