After all the hussle about Rails 3, can I, after all, painlessly use DataMapper without almost changing my ActiveRecord code so that I could run my Rails at GAE without any bother?
Well, you still have to add the properties for DataMapper, and a bunch of code in the gems you are using might not be ORM-agnostic. And you have to change your queries to the DM syntax (which is IMO more beautiful than the AR one), or you can use some of the old AR ones by using the gem dm-ar-finders. And what's GAE?
Related
In minitest_helper.rb I have seen the minitest class defined as:
MiniTest::Rails::Spec
or
MiniTest::Spec
What is the difference between these definitions? I have also noticed where the basic class is set...such as
MiniTest::Spec::TYPES.last[1] = MiniTest::Rails::Spec
What does this accomplish?
MiniTest::Rails::Spec is for testing rails sites, using the rspec-like dsl in minitest. MiniTest::Spec is just the plain rspec like minitest without the additional rails functionality.
The last line is adding rails matchers to standard MiniTest::Spec. There's a comment in the source explaining it: https://github.com/seattlerb/minitest/blob/master/lib/minitest/spec.rb#L97
I have a gem, that declares the class FulltextRow
I created an initializer called hacks.rb were I open classes from different gems.
I added the following code:
FulltextRow.class_eval do
....
end
However, If I don't require the class I get the exception:
uninitialized constant FulltextRow (NameError)
But it works well If I do:
require 'fulltext_row'
FulltextRow.class_eval do
....
end
My question is:
Why do I need to require a class that is defined in a gem? Aren't they automatically required?
I would love to help you out but it's hard to troubleshoot this with the lack of information given. I do have two suggestions, though.
1) You should verify the gem is loading properly within the gem. What I mean is to have supporting tests that affirm that the gem is working as intended. I've had instances where my gem's classes were not loading because I wasn't setting up the file structure right or had a silly typo somewhere.
2) It is also possible that your gemfile has set to not load the gem automatically.
gem full_text_row, require: false
Good luck!
I have a feeling this is a dumb one, but I've spent some time trying to figure it out and googling it, and to no avail. I'm trying to use a Ruby Gem in a Controller. I have included it in my Gemfile, run bundle install, seen it show up in my gems list, restarted my local server. But somehow whenever I try to call the gem ( rails_rrdtool ) It just tells me
uninitialized constant RrdgraphsController::RRD
app/controllers/rrdgraphs_controller.rb:22:in `show'
The spot in my code where it wigs is when I'm calling
RRD.graph
It's as though it doesn't know where the heck the gem is... However, I can use require to import it successfully into an irb session. So I know that it works, it's just not getting in there some how...
Bundler should be handling the inclusion of the gem I assume. Am I calling it in the wrong place?
This looks like a namespacing issue. Your error says it is looking for the constant inside of the current class: RrdgraphsController::RRD when it should be looking for a class outside of the current context.
Try prefixing the class name with a double colon to fully define the location of the class.
::RRD.graph #rest of your code
There's a good analogy of what this does in this other accepted answer. Basically it creates an absolute path so Ruby doesn't have to guess.
A simple question. Does this version support generators?
I wanted to test out using it and follow along with Ryan Bates screen cast which I uses a different version.
I've been playing with tables today and want to see how this works using the generator with a scaffold generated model and all its components.
Running rails g bootstrap:themed returns
Could not find generator bootstrap:themed
So I tried to reinstall with rails g install:bootstrap
Error similar which lead me to try to find if it supports these commands.
Thanks
It doesn't need generators for asset files, since we hook into the asset pipeline through the use of a Rails Engine - configuration options are available through the use of variables (use this as a reference, Sass variables are actually $x rather than #x and need to be defined before importing bootstrap), Sass' #extend, and Bootstrap's #makeRow and #makeColumn mixins, along with the other Bootstrap mixins.
Themed scaffold would be interesting but generally would be a pain to maintain - view scaffolding tends to get ripped apart pretty quickly anyway. Perhaps a 'sane' application.html.erb layout generator could be useful.
So yeah, we currently have no generators, don't need an asset one, themed scaffold probably not coming soon unless someone is interested enough to do the work on it, potentially a layout generator in the pipeline.
Checkout
https://github.com/decioferreira/bootstrap-generators
Seems to be what you are asking for.
-Rick
My Rails 3.0 app on ruby 1.8.7 contains Haml 3.1.3. Most of the views are haml templates, it takes about 0.5-5ms to render them on my machine in production mode.
Having said that, a few partials take much longer. 300ms to 900ms for 30-60 lines of haml. It must be something in the way how I use it, but how could I debug what's wrong? The benchmarks are consistent and reproducible.
I'm not sure about possible sources of the error:
deep partial nesting? (3-5 levels)
deep haml nesting? (4-8 levels)
use of block helpers?
lots of translations?
using haml with formtastic 2.0?
using form builders for nested forms?
Any help is appreciated.
It turned out to be a number of things inside Formtastic 2.0:
Lots of object lookups, uncached
Lots of translations, uncached
Use of try…rescue blocks which slowed it down tremendously
Fixes have been added to Formtastic 2.1 and up, making it a lot faster. Kudos to Sascha Konietzke for providing patches.
A more recent way to fix this is Hamlit, a high-performance Haml implementation with some limitations by design for performance. It claims 8.24x speedup.
Also, not Haml-specific, but look at multi-fetch gem for lists.
Most likely it's Garbage Collection. See these posts:
http://www.williambharding.com/blog/uncategorized/rails-3-performance-abysmal-to-good-to-great/comment-page-1/
http://bibwild.wordpress.com/2011/06/28/rails3-unbearably-slow-view-rendering-use-ree-with-gc-tuning/
If you're using REE 1.8.7 (which also fixes a memory leak, so you should be) then you can tune your GC settings. I just did this last week and our response time dropped by 50%.
Put in .bashrc:
export RUBY_GC_HEAP_INIT_SLOTS=1000000
export RUBY_HEAP_SLOTS_INCREMENT=500000
export RUBY_HEAP_SLOTS_GROWTH_FACTOR=1
export RUBY_GC_MALLOC_LIMIT=50000000
Source, and restart server
$> source ~/.bashrc
$> rails s
Depending on what is your problem, this might make rendering your partials faster (in my case, average rendering time got x3 faster).