I'm looking for a way to handle integer ordinalization in Ruby/Rails, ie. "st", "nd", "rd", and "th" suffixes to integers. Ruby on Rails used to extend FixNum with an "ordinalize" method, but that functionality seems to have been deprecated in version 3.
I am currently just using the source for the old Rails method, which is fine... but this seems like functionality that most scripting languages / web frameworks would have built in, and I feel like the folks behind Rails must have had a reason for deprecating the functionality (perhaps it is now available in Ruby proper?).
Please advise!
The method you want is still ordinalize.
Active_Support was refactored a bit to provide better granularity. Instead of loading in everything at once, you can select smaller chunks depending on what you need.
You can either load everything in Active_Support using require 'active_support/all', or break it down using
require 'active_support/core_ext/integer/inflections':
>> require 'active_support/core_ext/integer/inflections' #=> true
>> 1.ordinalize #=> "1st"
Lately (last I knew) there has been a trend to not modify core classes. The Rails-Core mailing list might have a better answer for this one.
It looks like that functionality was moved to Inflector from a Fixnum extension which makes sense. Hopefully someone else can confirm this.
Related
I have run a static code analysis tool (brakeman) on a rails app and it has reported some SQL Injection vulnerabilities which I suspect may be false positives. The offending lines look like this:
#things_controller.rb
def index
Thing.select(params[:columns]).where(params[:conditions])
end
I can't figure a way to exploit this, but it does seem rather open-ended, is this safe enough (this controller requires admin access anyway) or can it be exploited?
Ruby is 2.0.0-p247,
Rails is 4.0.0
While rails has some built-in filters for special characters, this is definitely vulnerable:
http://guides.rubyonrails.org/security.html#sql-injection
If you want to test it yourself, run a full scan with sqlmap using the url of this action with a conditions GET parameter
If you are a new developer to a large (very large!) rails app it can be really difficult to trace through the flow of what is calling what, where a method is defined, and how to 'grok' how the whole thing works.
What are best practices for how to find information like:
I'm in class Foo and it calls a method bar but there is no def bar in the file. It must be mixed in or a concern or monkey patched etc. in somehow. What are steps 1, 2, 3 for where to look? I don't see anything obvious at the top of the file and greping for 'def bar' doesn't return anything.
Metaprogramming! Probably defined the methods on the fly based on the params passed. Ex. define_method
I would go with
grep "def bar" app/* lib/* -irn (optionally -l)
If I'm in the file open, I most likely would use cscope, because I use vim, but if you are using an IDE it might help you somehow to find this method.
Or yet, I could simply use the debugger, where you can inspect your objects in runtime.
Before I ask a question, I like to caution everyone that I am a programming newbie, so please correct me if I ask something ridiculous.
I have been reading about Ruby having open classes, i.e a method can be added. However, I am trying to get a few examples of how Rails might have added to existing Ruby classes.
Rails has so many core extensions they're in a separate gem – ActiveSupport.
No sense trying to explain everything here, I'll just point you to the Rails guides. After you are familiar with them, refer to the documentation when you need to.
I second Matheus. ActiveSupport is a good example. Take a look at some source code files here:
https://github.com/rails/rails/tree/master/activesupport/lib/active_support/core_ext
And, here's a typical and simplistic example which adds useful and somewhat controversial methods on standard Array class in Ruby.
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/array/access.rb
Most Ruby libraries have a directory named 'core_ext', 'ext' or something along this line which includes methods that extend Ruby's core library in a way or another. People always reinvent methods and in a sense, ActiveSupport is the definitive compilation of those.
I have found that a great example is Time
From a rails application
Time.
Loading development environment (Rails 3.2.3)
1.9.3p125 :001 > Time.
Display all 252 possibilities? (y or n)
Time.module_exec
Time.__delay__ Time.mongo_thread_local_accessor
Time.__id__ Time.name
...
Total = 252
From a plain ruby console (IRB)
$ irb
1.9.3p125 :001 > Time.
Time.hash Time.private_method_defined?
Time.__id__ Time.include? Time.private_methods
Time.__send__ Time.included_modules Time.protected_instance_methods
...
Total = 93
Prior to Rails 3, creating a plugin to extend find was relatively easy: basically override the find method itself in ActiveRecord::Base, calling super if needed.
Now that Arel is being used in Rails 3, (specifically I'm using Rails 3.1), how would I go about doing something similar? The problem is that many of the old find methods are deprecated in favor of scopes like where, order, limit, etc. At what point(s) in the Rails source should I try to override the default behavior?
I'm sure it's going to be a bit more convoluted than this, but the closest thing I can find that seems like it might be appropriate is the construct_finder_arel method in ActiveRecord::Base.
After digging through Rails source, regardless of Arel being used, find_by_sql method is called on whatever model is performing the find. This can be extended via alias_method_chain as follows:
find_by_sql_with_customization(*args)
results = find_by_sql_without_customization
# do something with results here
results
end
alias_method_chain :find_by_sql, :customization
I am a beginner in Rails. I use 2.3.X.
I just saw Rails 3 is pre-released [edit: now in release candidate!]. I will most probably eventually switch to it.
What are the common coding habits in 2.3 I should not take, so that the switch is as smooth as possible ?
Edit:
I've done my homework and read the Release notes. But they are far from clear for the most crucial points, for example :
1.5 New APIs
Both the router and query interface have seen significant, breaking changes. There is a backwards compatibility layer that is in place and will be supported until the 3.1 release.
This is not comprehensive enough for a beginner like me. What will break ? What could I do already in 2.3.X to avoid having troubles later ?
Looking at my personal coding habits (I have been using Rails since 1.2.x), here's a list of API changes you can anticipate according to Rails 3 release notes.
find(:all)
Avoid the usage of:
Model.find(:all)
Model.find(:first)
Model.find(:last)
in favour of:
Model.all
Model.first
Model.last
Complex queries
Avoid the composition of complex queries in favor of named scopes.
Anticipate Arel
Rails 3 offers a much cleaner approach for dealing with ActiveRecord conditions and options. You can anticipate it creating custom named scopes.
class Model
named_scope :limit, lambda { |value| { :limit => value }}
end
# old way
records = Model.all(:limit => 3)
# new way
records = Model.limit(3).all
# you can also take advantage of lazy evaluation
records = Model.limit(3)
# then in your view
records.each { ... }
When upgrading to Rails 3, simply drop the named scope definition.
Constants
Avoid the usage of the following constants in favour of the corresponding Rails.x methods, already available in Rails 2.x.
RAILS_ROOT in favour of Rails.root,
RAILS_ENV in favour of Rails.env, and
RAILS_DEFAULT_LOGGER in favour of Rails.logger.
Unobtrusive Javascript
Avoid heavy JavaScript helpers in favour of unobtrusive JavaScript.
Gem dependencies
Keep your environment.rb as clean as possible in order to make easier the migration to Bundler. You can also anticipate the migration using Bundler today without Rails 3.
The release notes are the most important thing to keep an eye on. Other than that Jeremy McAnally has some neat blog posts about the whole Rails 3 thing (and has just released a gem to help you with the migration).
I'd say, read the rails release notes and see for yourself what seems the more surprising to you. A lot of stuff changed so reading this is definitively very important.