I tested the ruby agent 3.7.1.188 of New Relic but I don't understand the purpose of the ruby-prof gem. When I go to http://localhost:3000/newrelic, on the right side is a message that says that I can use the ruby-prof gem to display profiles. So I installed ruby-prof gem and clicked on "Start profiling" then clicked around my site and finally clicked on "stop profiling". I can now click on the URLs to see how long some action lasts. But I get the same statistics without ruby-prof. So where is the exact purpose of ruby-prof regarding the New Relic agent?
Ruby Version: 2.0.0
Rails version: 4.0.0
The purpose of using the ruby-prof gem from within the Ruby agent's developer mode feature is to be able to capture and display execution profiles that instrument each method call that's made while servicing a request. Unfortunately, integration with ruby-prof is one of the older corners of the newrelic_rpm code base, and as such has fallen into a bit of disrepair. That said, it's useful for solving certain kinds of problems, so we're making an effort to revive it. New Relic has just released version 3.7.2 of the newrelic_rpm gem, which should fix ruby-prof integration for Rails 3 and Sinatra applications, and we're planning to fix it for Rails 4 in an upcoming release. If you're interested, you can watch for the next beta release of the newrelic_rpm gem, which should include a fix for ruby-prof usage in Rails 4.
Related
In my Gemfile, I'm including a gem that has a .gemspec that uses the pessimistic operator ~> to specify a version of the gem. However, I need to use a newer version of the gem. In my case I'm using spree 3-0-stable that has activemerchant set to '~> 1.47.0' https://github.com/spree/spree/blob/3-0-stable/core/spree_core.gemspec#L22 but I need use active merchant '~> 1.59.0'
I tried to specify version 1.59.0 in my Gemfile but bundle complains with:
You have requested:
activemerchant ~> 1.59.0
The bundle currently has activemerchant locked at 1.47.0. Try running
bundle update activemerchant
If you are updating multiple gems in your Gemfile at once, try passing
them all to bundle update
But the command bundle update activemerchant will only update to 1.47.x.
What's the rails-y way of accomplishing this? Aside from forking spree myself and updating the .gemspec? Obviously updates to the activemerchant gem might break the spree gem. But I can test with my app.
The maintainers of Bundler have recommended forking the relevant gem, then making a PR back onto the gem. Then link directly to the branch in that PR in your Gemfile. This encourages the community to rally around a solution.
I've documented the process in detail here: https://github.com/rubygems/rfcs/pull/13#issuecomment-770416467
You can't do it, the rubygems system doesn't allow that. You have to file an issue for the upstream gem dependency, and ask them to loosen their requirements.
It may be that the version of activemerchant you want actually won't work with the version of spree you want, it will break it. If so, spree code would have to be fixed to work with the new version of activemerchant. Or, it could work fine with the version you want, the restriction in spree is accidentally unneccesarily strict, in which case the spree gemspec would just have to be changed to allow it.
But there's no way for you to override it without changing the spree gemspec.
You could make your own fork of spree in which you change the gemspec -- but without knowing whether or not spree will really work with the version of activemerchant you want, that could be dangerous. And now you're on your own fork, so you won't be able to upgrade to new versions of spree without merging in their changes to your fork, etc.
Another thing is, it's a bit odd to be running off a spree 3-0-stable branch, instead of an actual released version of the gem. But I'm not familiar with spree's release management practices, perhaps this is what they encourage? At any rate, changing this probably won't fix your problem.
If your app is relatively new or simple, you could consider switching from spree to solidus, a fork of spree. Solidus forked off at spree 2.x though, so migration from spree 3.x might not be straightforward, especially if your app is established and somewhat complex. Although the solidus_core gem is also locked to activemerchant ~> 1.48.0, so it also won't allow anything but activemerchant 1.48.x. The solidus team is pretty responsive on their Slack channel, if you wanted to ask them what's up with that, if they know if later versions of activemerchant will work, if the dependency can be loosened. I have found the solidus maintainers to be very responsive, and likely to be interested in allowing later versions of activemerchant if it's feasible to do. I'm not familiar with the current Spree team and how they communicate with users (if they have a slack, or listserv, or are responsive on github issues, or what), but you could of course have the same conversation with them.
I've recently upgraded to Rails 4.2.0 and MiniTest ~> 5, and that broke the Turn gem. I noticed that it is no longer being maintained due to the developers getting fed up with API changes https://github.com/turn-project/turn , so I pulled it out of my project.
I'm really missing the better test output that Turn provided. What are some great alternatives to get customizable, colorized, well-structured MiniTest output?
Take a look at minitap and tapout - it's not a simple plug-and-play gem like turn was, but you can get it very nice with a bit of trial and error.
I have been searching for a simple answer to this for a few days and can't seem to find an one, on either stackoverflow.com or google. So, firstly, if this is answered elsewhere please point me in the correct direction.
So, I have a relatively new Rails 3 project using the cucumber-rails gem. I am relatively new to Rails but have experience in Ruby and other web frameworks such as Sinatra and Ramaze. My understanding is that out of the box, cucumber-rails uses Capybara for interacting with the web application and somehow does this without starting the rails server. It somehow interacts with rack to simulate the requests. Not sure if I have that entirely correct but I'm pretty sure it does not need a running rails server.
I am not a great fan of the Capybara DSL and I much prefer watir-webdriver which I have used in a few non rails projects (and non Ruby projects even). However, I have not been able to find anywhere to show me how to swap out Capybara for watir-webdriver.
So my questions are these:
Does the cucumber-rails gem have the ability to swap Capybara out for watir-webdriver?
If so, what is the best way to do this?
If not, does that mean I need to ditch cucumber-rails and just set cucumber with watir-webdriver up in my project manually?
Well, it doesn't look hopeful from the project description:
Rails Generators for Cucumber with special support for Capybara and DatabaseCleaner
And sure enough, it explicitly, unconditionally, loads Capybara here
I think that means that you're going to need to hook it up yourself.
Having said that, I don't think there's anything stopping you from installing the gem, running rails g cucumber:install, and then replacing the Capybara-specific bits in the files it produces.
Am migrating rails application from 1.2.3 to 2.0.2. Can anyone tell me if there is any plugin available for this?
Thanks in advance!!
I recently took a 1.0 app all the way to 3.0 by going through 1.2, 2.0, 2.3, then 3. There are no plugins that I know of, but there are certainly plenty of guides.
From the release announcement:
If you want to move your application to Rails 2.0, you should first move it to Rails 1.2.6. That’ll include deprecation warnings for most everything we yanked out in 2.0. So if your application runs fine on 1.2.6 with no deprecation warnings, there’s a good chance that it’ll run straight up on 2.0. Of course, if you’re using, say, pagination, you’ll need to install the classic_pagination plugin. If you’re using Oracle, you’ll need to install the activerecord-oracle-adapter gem. And so on and so forth for all the extractions.
There are plenty of blog posts around, Peter Marklunds is particularily good.
One thing I did before anything else was to start managing the dependencies with Bundler. I blogged about this at the time, was definitely useful.
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.