The default repository for downloading gems using RubyGems was originally RubyForge.org. This was likely because the RubyGems project was hosted only from RubyForge. This meant that when you ran ‘gem install rails’, your RubyGems installation was configured to download the gem from ‘gems.rubyforge.org’. In August of 2008 Github started gaining popularity amongst the Ruby community after it started providing it’s own gem server via gems.github.com. This resulted in many Ruby developers configuring RubyGems to use the Github server as a secondary source of gems.
In August of 2009 a new gem hosting repository came onto the scene known as GemCutter, aiming to resolve issues caused by how Github and RubyForge were handling hosting of gems. In September they decided to move the service to RubyGems.org. In October of Github discontinued building and serving gems from gems.github.com, and RubyGems.org became the official default host for Ruby gems.
Documentation seems to be more available on how to build forms with check boxes or a multiple select field for ActiveRecord objects that have a has_many or has_many_and_belongs_to association with other ActiveRecord objects. This article shows you how provide a multiple select form based on a custom defined array, with the selected options stored in a single attribute of your ActiveRecord object.
Lets say you are working on a form for a blog post that needs a multi-select field of statically defined adjectives, with the one or many adjectives saved to one field for the post.
So it’s been several weeks since I started using test driven development. I’m using FactoryGirl instead of fixtures, because I’ve heard that fixtures are limiting. I’d rather just write Factories from the beginning. I’m also using standard Test::Unit based unit and functional tests. Haven’t touched on integration testing yet.
As I’ve gone along and written these tests, I’ve learned how to do things effectively and am carving out my own style.
For instance you could either test for a link with the content ‘Edit’ on the page, or you could add an ID or class to the link and test for the presence of that link with that class. I found that I’d rather do both just to ensure that the button is or is not present in a certain circumstance.
I just recently started to adopt test driven development practices. The project I’m working on needs to get done soon, and I didn’t want to get held up learning Rspec. After much consulting with other developers at the company I work for, I had decided to use basic Test::Unit tests with FactoryGirl factories instead of fixtures, and adopt Shoulda if a scenario arises where the options it provides (contexts) are needed.
So far things have been running well, and I’m starting to understand just how important testing is. You don’t have to write tests for every single thing you do, but if you implement some sort of feature that you seriously don’t want to break at some point in the future, setup a test for it. Once you setup a test for one type of feature, you can re-use the code later for similar testing. So don’t worry about how long it takes the first time around, it will pay off later when that function isn’t broken because you caught it. I didn’t realize it, but errors you didn’t expect it to directly catch, like the dreaded “undefined method ‘foo’ for nil:NilClass” exception, also popup periodically and alert you that you broke something, even though your test wasn’t built to catch those. This is nice because you might change something in a model, and then all of a sudden something in a view is broken.
I’ve noticed that if you install certain testing gems, like Factory Girl, or Rspec, that your Rails application will create test files for these libraries instead of using the defaults. Even further you can configure the generators used by your Rails app in /config/application.rb
# Configure generators values. Many other options are available, # be sure to check the documentation. # http://edgeguides.rubyonrails.org/generators.html#customizing-your-workflow config.generators do |g| g.stylesheets false g.test_framework :rspec g.fallbacks[:rspec] = :test_unit g.fixture_replacement :factory_girl end
I was just trying to create coding that reflectively loads the subclasses of a class I’ve defined. The idea is that as new subclasses are added, the script I’m writing can detect which ones are present and inform a remote API that support for a specific API feature is available.
I had executed the method once on the class, and it did return the name of the subclass that I had defined and checked for the existence of in the Rails console environment. Then I added other subclasses, reloaded (reload!), and ran the method once again. This time I got nothing but an empty array returned. It turns out that Rails 3 uses autoloading for classes…so the subclasses have to be referenced at some point, and thus loaded into memory, before the subclasses method will include them in the list.
UPDATE: I ran into errors and decided to not use the findutils provided by Homebrew. I simply setup the following alias in .bash_profile and this did the trick. This is using the built in locate database provided with Mac OS X Snow Leopard.
alias updatedb='sudo /usr/libexec/locate.updatedb'
I used to use MacPorts to ensure that my command line environment on my Mac was almost exclusively using MacPort provided binaries, not the built in binaries and libraries that are packaged with Mac OS X.
I forget the proper syntax for a model generation command that includes a reference to another models id (foreign key).
Here is an example you can use to remember:
rails g model Post user:references title:string body:text
Since the ‘user’ model already exists, Rails knows that this should be the user_id field that it generates. I guess it’s not a big deal, you could just do ‘user_id:integer’, but what fun is that?
I recently setup a custom controller to edit/update my Admin accounts, which are authenticated using Plataformatec’s Devise gem.
I found an article in the Devise Wiki that mentions using some sort of ‘update_without_password’ method to update the model without requiring the password. In this case I’m not requiring the user to provide their own password to edit their info. I’m allowing them to do it straight out.
The solution that I found was to simply remove the ‘password’ and ‘password_confirmation’ from the parameter set if both are blank.
# remove password parameters if blank if params[:admin]['password'].blank? && params[:admin]['confirmation'].blank? params[:admin].delete('password') params[:admin].delete('password_confirmation') end
I just started a new Rails 3.2 project, and to ensure that the proper test files are generated using Shoulda or Factory_Girl, I’ve installed those gems and configured the application to generate the test files using these gems.
Added to config/application.rb:
# Configure generators values. # http://guides.rubyonrails.org/generators.html config.generators do |g| g.stylesheets false g.test_framework :shoulda g.fallbacks[:shoulda] = :test_unit g.fixture_replacement :factory_girl end
Each time I would try to create a new scaffold, it would use shoulda to generate the test unit file, but would generate a YAML fixture.