This might be an incredibly simple question, but I'm writing my first Rails engine (Rails 3.2) and this is all pretty new.
My engine is meant to Email Delivery (do the sending and the logging of messages) for a few of my older Rails apps (3.0.11, 2.3.15, 2.3.14). I thought I would be able to just create this application and mount it to the older apps.
Simply put, must I upgrade the older apps before being able to use an engine written in a new version?
I went on #rubyonrails on irc and got a bit more information.
"You should be able to use new engines in older apps as long as you don't use any APIs not in the new version you'll be fine."
and
If the engine requires a different gem version than your application does: "You'll have to resolve those issues manually"
That should get me started....
Related
can anyone help me how to create a web service API in rails 4. I know how create web service API in ruby 1.8.7 and rails 2.3.5 with action web service gem. When I am trying to use https://github.com/datanoise/actionwebservice gem in rails 4, I am getting deprecated errors.I want to upgrade my web service app. Please help me.
Rails-API looks promising, because it will be part of Rails core in Rails 5.
Rails-API
Rails-API is a subset of a normal Rails application, because API only applications don't require all functionality that a complete Rails application provides. so, it compatible well with old Rails versions. I don't know compatibility exactly, but I'm using it with Rails 3.2.x
There are another proper framework for this purpose, for example, Sinatra, Grape, but If you familiar with Rails, Rails-API will be the best choice.
Actionwebservice is long deprecated, in favour of REST API's. At my previous job we used a fork of actionwebservice in a rails 3 project.
Since there is no maintainer anymore for the actionwebservice gem, that fork never got merged back. If you check the fork history, a lot of people are fixing and partially updating it, but it is scattered all over the place.
Afaik none of the forks were updated to use rails 4. But using a rails 3 fork might just work.
If you really need to build a SOAP API server with Rails, imho your best option is to take a look at Wash-out, but you will have to re-write your API code.
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.
In order to migrate smoothly a Rails 3.0.10 application which need to grow up with many new models and controllers over rails 3.1.1, I wonder if we could just mount the old app under the new 3.1.1 leaving one team implementing the new features, while the other carefully migrate the old 3.0.10 components.
Is that possible ? Is it desirable ? If yes how can we do it ?
Any idea or experiences is welcome.
UPDATE
... we also are in a phase which every programmer is starting a new feature, with no resources for porting currently. So I said, way don't start with many brand new self contained/tested apps (rack + sinara + old rails 3.0) driven by (mounted on) rails 3.1.1 working as a router/container ?
I've in mind something like Paul Dix describe in his "Service-Oriented Design with Ruby and Rails" book.
New features, can also be started over Rails 3.1.1, on top of that old 3.0 app, until the first programmer will be ready to start migration ... what do you say ?
Luca
I'd recommend not doing it this way. What you end up doing is doubling your work - you now have to test every feature in multiple codebases, for little benefit.
Just upgrade the app from 3 -> 3.1 and move on with your day. It shouldn't be hard, 3.1 is a point release and should be mostly backwards compatible.
Historically the main issue with upgrading has been 3rd party library dependencies besides Rails - they often break when rails is updated, and then you have to either fix them, rewrite them yourself, switch to another one that works on the new rails version, or just wait to upgrade until they are compatible, all which may be undesirable.
Fortunately, I don't think a lot of gems broke in between rails 3 and 3.1 so you shouldn't have that issue.
Edit: if you're concerned about the changes to css/javascript/html in 3.1, I can only imagine you're assuming the asset pipeline changes things. in my experience, it doesn't. The asset pipeline, to my knowledge, is mostly optional. I think you can still reference css/javascript in the same manner as rails 3.0 if you want
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 have a old app made on rails 1.2.5, this application have alot of access per day.
I intend to upgrade my server (a joyent accelerator) to run ruby 1.9.x and work with rails 3 but I can't stop or move this app to another server.
Have any way to run this application on ruby 1.9?
or run two ruby versions (1.8.7 and 1.9) at the same time?
or on the last case upgrade my app to work with rails 3?
Thanks.
There was quite a few patches to Rails to make it run under Ruby 1.9. I think you are up for a challenge if you try to do that. With Ruby Version Manager you can work with multiple ruby environments from interpreters to sets of gems.
Does it have to be switched over to Rails3 and Ruby 1.9?
Can you just throw you old app on a virtualized server and keep the app running as is?
The reason for my suggestion is that we just went through a similar case. A local business (a construction association) had a pair of apps developed for them 2-3 years ago (works with Rails 1.2.6). Nothing overly major (a billing app, and a bid/contractor/customer management system). Everything works, so no need to update anything.
Their hosting provider was not willing to keep an old outdated rails available in shared hosting environment. Hosting shop cited maintenance can't be streamlined, security concerns, etc. Sure enough, the same host offers to rewrite the apps for current technologies (for a price, of course).
Client wasn't happy with them. The shop that developed the apps since closed and the developers left for greener pastures. But everything works, so why reinvent the wheel, right? Client went looking for alternatives. Came to us. We sat down with the client, did some cost/benefit analysis and decided to just host in a virtualized environment (at another provider). Did that in a week (with some hick-ups): back-up, move, restore, test, everything works. And it's been working now for 3 months without any issues.
This might not work for you, but unless you need to add to the app why fix what ain't broken?
Rails 3 works with Ruby 1.8.7
Another option (apart from obvious RVM) is to leave your Ruby 1.8.7 and Rails 1.x as is and install latest JRuby and Rails 3.0 and dependent gems with jruby -S gem install rails. Ruby and JRuby gems perfectly coexist without any interference. OpenSolaris in Joyent's Accelerator is good at running Java, so you won't have much problems with it.
P.S. Btw, I won't recommend updating your Rails 1.x app to 3.x, unless you're planning to add lots of new features to it. It can be very painful, especially if you used lots of old-school gems and plugins.