New to EC2: Unable to connect to host error


It might be that your corporate firewall is not letting out SSL based traffic. If that is the case you have two options:
1) change the environment variable EC2_URL to http://ec2.amazonaws.com/
2) ask your administrator to allow external access on port 443
If you use the non SSL http://ec2.amazonaws.com/ URL you should be aware that although your requests are authenticated, i.e. no-one else can perform EC2 calls as you,  they will not be confidential, i.e. someone could view your requests.

Advertisements

Rack


Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.

Informally, a Rack application is a thing that responds to #call and takes a hash as argument, returning an array of status, headers and a body. The body needs to respond to #each and then successively return strings that represent the response body and provide more convenience (Rack::Request and Rack::Response) that you are free to use if you wish.

The Difference between Mocks and Stubs


Using stubs – is the classic TDD approach where unit tests are designed to check state. A general core workflow would be calling a method of an object/type with subsequent verification that the state has been updated.

Using mocks – is a TDD variation – BDD – that aims to track behaviour. Typical scenario would be creating a pre-programmed workflow and check if a real-world object follows the predefined behaviour.

Rspec test case for protected controller with devise “before_filter :authenticate_user!”


In rspec_helper.rb we need to add

RSpec.configure do |config|
config.include Devise::TestHelpers, :type => :controller
end

and in spec_controller.rb file

before (:each) do
@user = FactoryGirl.create(:user)
sign_in @user
end

if using FactroyGirl.

OR

we can also add

include Devise::TestHelpers

in each and every controller where controller is protected. followed by sign_in @user

I hope it help.

Why Phusion Passenger?


Installing Phusion Passenger as part of your development environment makes it easy and quick to work on multiple Rails projects simultaneously. Installing Phusion Passenger as part of your production environment speeds up your server response and simplifies server setup.

History of Ruby on Rails Deployment

The initial server used for Rails was WEBrick, which is written entirely with Ruby and bundled with releases of the Ruby interpreter. Because it is available in any environment that can run Rails, WEBrick remains the default server for Rails and is invoked by the Script/Server command from a Rails application, if no other server is available. However, its performance and scalability characteristics are poor, and it’s rarely used in production.

Over time, a server named Mongrel has emerged as the most commonly used alternative to WEBrick for both development and production, due to better performance and greater flexibility. In development mode, typically a single Mongrel instance is run; however, in production, a cluster of multiple instances is run for increased performance. (Until very recently, Rail’s single-threaded nature made multiple servers a practical requirement for any production system.) The resulting Mongrel cluster requires separate load-balancing software to distribute requests among the Mongrel instances. In production, load balancing for Mongrel is often handled by an external web server, such as Apache, which also handles requests for static content not managed by Rails.

Why Phusion Passenger?

Why Phusion Passenger?

Although Mongrel remains popular, Phusion Passenger has gained significant support since the release of version 2.0, including the decision by 37Signals to move its flagship Rails applications to a Phusion Passenger back end. Passenger offers several advantages to a Rails developer—most notably, ease of setup and maintenance. Passenger also has a reputation for being extremely stable, and its performance is consistent with other Rails application servers.

Phusion Passenger achieves ease of use and low maintenance primarily because it automatically spawns and removes Ruby instances as needed, which makes the production configuration of Passenger significantly simpler than Mongrel. One weakness of the Mongrel setup is that the determination of the optimal number of Mongrel instances for each project is something of a trial-and-error process. Phusion Passenger automates that process for you. If you are using Apache as your web server, integrating Passenger is simple and managed completely within Apache configuration files.

In development, Phusion Passenger keeps all configured Rails applications alive at all times. If you work on multiple Rails projects simultaneously, you’re probably used to having to continually start and stop the servers on those projects. With Phusion Passenger, all the applications are always available, so moving back and forth is much simpler. Because Phusion Passenger manages the Ruby instances, applications that are not being used don’t consume system resources.

Stability is difficult to measure objectively. The Phusion Passenger web site claims that in all their load testing they have never crashed Phusion Passenger because of load (although individual Rails application can still crash because of bugs in the Rails application itself). The consensus experience of Phusion Passenger in the Rails community so far seems to bear this out. Performance appears to be in the same realm as Mongrel—give or take a few percent.