How can I implement write through caching in Rails 3 similar to cache-money? - ruby-on-rails-3

I recently inherited a Rails 2.3 application that I'm now trying to upgrade to Rails 3. Cache-money is an integral part of the application so I want to make sure we have the same functionality in place when we go to Rails 3. However, my research on the subject has shown that cache-money is not compatible with Rails 3 (due to the use of unsupported AR methods :find_every and :find_from_ids).
I've seen a couple of comments and blogs mention that implementing the type of write through caching with Rails 3 that cache-money provided should be a trivial task. Any ideas on how to approach implementing write through caching with Rails 3?

Last week I launched a new write-through-cache gem for Rails 3, see
https://github.com/orslumen/record-cache.
The reason I built it, is because we were using cache money in a Rails 2.3 project and recently migrated to Rails 3. So chances are, it will also serve you well.
Writing your own write-though caching in Rails 3 does not sound like a trivial task to me. If you do find a trivial way, please be sure to copy me in on that.

Related

report builder like salesforce has for ruby on rails?

Salesforce report builder is pretty awesome - see here http://www.salesforce.com/_app/video/chatter/help/report_builder.jsp.
Lots of my customers want similar functionality built into ruby on rails apps. I cant seem to find any good tool, framework or gem out there to do this sort of thing. Before I start building one myself, I wanted to see if anyone knew of something out there that was similar or could be used for the same purpose.

Can Rails's scheme.rb recreate the scaffolds automatically?

Using schema.rb, I think we can actually convert an older Rails 3.0 project to a Rails 3.2.3 project, rebuilding the database using this schema.rb file.
But if I just used scaffolds to create all the RESTful resources before in the 3.0 project, then won't the scaffolds need to be generated once again for this new Rails 3.2.3 project also? If that is the case, won't it be not useful to use scheme.rb? Because we will create all the migration files along the way anyway and do the rake, and we can just generate the extra create index migrations along the way.
Or is there a better way? Such as a way that the old scaffolds and old database tables and indexes can be recreated automatically? The old database can be used or discarded, so it is a cleaner option to start the sqlite database fresh from the start.
Is there a reason you want to scrap the existing project/database to build a new one? It's usually pretty easy to just update the rails version in your Gemfile, run bundle install, and then just fix anything that breaks (which, if you were using the default scaffolding, won't be much). The existing database will work just fine with either 3.0 or 3.2, as well as all of your old scaffolding files.
You should check out this railscast to see how to go from rails 3.0 to 3.1, so you can see the basics of upgrading. Upgrading from 3.1 to 3.2 is even easier.
To answer your original question, there is no straightforward way to regenerate scaffolds using schema.rb. The scaffolds are only a starting point to help you as you start to build a model/controller, there would usually be no point in recreating them since you usually end up modifying them heavily afterwards anyway.
You can use this "reverse scaffold" script:
https://github.com/ahe/reverse_scaffold
It will generate the required html.erbb file right in your app/views folder.
It pretty well explained on the Readme page.
And, it's updated for Rails 3.2

Converting Rails 2 app with ActiveMessaging to Rails 3, have a few questions

I'm currently converting a fairly large Rails 2 app to Rails 3. The app uses activemessaging in its plugin form. It's used with Amazon SQS primarily for file uploads, among a few other things. I have the all the queues I use defined in messaging.rb and there are existing processors to handle messages. In the Rails 3 version I'm switching over to the activemesssaging gem, version 0.9.0. Aside from getting rid of the old plugin version is there much else I need to do to my existing messaging.rb and processors? Also right now I manually start the poller script, is that the same? I can't seem to find much info about Rails 3 and activemessaging so if anyone can give me the basic steps of what I need to do it would be much appreciated. Thanks.
I don't remember there being a big difference with using the gem - I did not change the way messaging.rb or broker.yml are loaded, and you still have to start the poller yourself.
In general there is not a big difference with Rails 3, which is why you aren't seeing much about it.

Rails 3, too many ways to test?

If you were just starting out in rails which path would you encourage new users to go down with regards to Testing.
Anything I read about regarding Rails 3, tells me I should be using Rspec 2. But Rspec comes with a whole whack of other things I need to learn like
gem 'capybara'
gem 'database_cleaner'
gem 'cucumber-rails'
gem 'cucumber'
gem 'spork'
gem 'launchy'
And then one of my friends just told me that I should just stick to the testing framework that comes with rails, and maybe just integrate 'shoulda' into the test process because it has a nice syntax.
When it comes to testing it seems like we have way too many options and too many ways of doing something. Maybe this is a good thing, but I always thought rails was about creating common conventions and avoiding doing the same thing in different ways.
I'm fairly new to rails.
I'm unsure where to start.
I feel overwhelmed.
Is this normal?
Since you're beginning with rails, I'd recommend using something that "just works" to get in the habit of testing your code and understanding how to work with your framework. Don't waste your time comparing solutions, choose one and stick with it for this project.
That being said, I really think it depends on your experience developing software:
if you've never used unit tests for your code, learn Test::Unit and consider adopting TDD. Notice that TDD will need you to dedicate a large amount of time to it at first, but that is paid off when you get used to it.
if you have significant experience with code tests and are just confused on how to start with rails, I recommend following through http://railstutorial.org/book. This is a (free) Ruby on Rails book that uses RSpec, Spork and serves as a great introduction
After developing one project from start to end using the testing platform you choose now, you'll have a much better task of choosing the testing framework you wish to use.
I'd also recommend you learn RSpec well before diving into Cucumber.
Sounds like you have option overload. Which is common to most people in a lot of different situations even outside of programming. The absolute easiest thing for you to do, would be to go with what Rails sets up by default, which is called Test::Unit
Their official guide introduces it here: http://guides.rubyonrails.org/testing.html
Once you are comfortable with testing using plain Test::Unit style then I would suggest you explore some of the addons your friend mentioned such as shoulda (https://github.com/thoughtbot/shoulda), and factory_girl (https://github.com/thoughtbot/factory_girl)
Good luck!
But Rspec comes with a whole whack of
other things I need to learn like ...
Actually, you don't need to learn any of those other gems to get started with RSpec. Just go with gem 'rspec-rails, and run rails generate rspec:install to set up your project.
A good way to learn RSpec is to look at the code generated by rails generate scaffold. This creates spec files for controllers, views and routes that deal with the standard RESTful actions.
While learning RSpec you can add in other gems as you discover the need for them. Autotest is essential IMHO. Webrat adds useful matchers for view specs. Factory_girl adds support for factories.
Spork is great, but not really necessary until you have enough specs that performance is an issue.
I feel overwhelmed. Is this normal?
Less of this, more of this :)

Is there an equivalent to Symfony's Localized Schema in Rails 3

I've been searching for an equivalent to Symfony's built-in Localized Schema which provides a native support for managing internationalized Tables/DB. Here is a link to Symfony's documentation covering their implementation of I18n & L10n, with the relevant part on Localized Schema (appx. a third down the page, such as the paragraph "Text Information in the Database").
I've checked out Globalize2 gem, but not sure as to whether it is fully supported in Rails3.
Also found the gem puret, which seems to have more recent commits/activity.
All in all though, it's very likely I am missing out on other possible options, as still getting my bearings in RoR dev.
Open to any info/suggestions you may have! ;)
Try gem named has_translations. It have been tested in several production sites for a one year already. Supports 1.9 + Rails 3. For any issues fill out form on the github.
https://github.com/dmitry/has_translations
Actually it's more or less the same as puret, but it was built when rails 2.3.5 was a mainstream, so I just supported it for a websites I've did already. I suggest you to choose between puret and has_translations, others is too magic or not maintained anymore. You can find more alternatives in has_translations README file.